HardlinkBackup

Logo HardlinkBackupHardlinkBackup ist ein einfaches, schnelles Backup-Programm für inkrementelle Backups, das Hardlinks benutzt, Backups planen, E-Mail-Benachrichtigungen versenden und automatisch alte Backups löschen kann. HardlinkBackup liest die Quellverzeichnisse ein und vergleicht die Dateien mit früheren Backups. Nur die geänderten Dateien werden anschließend kopiert, die unveränderten Dateien werden mit Hard-Links mit den Dateien der bereits bestehenden Backups verlinkt (Voraussetzung ist, dass das Ziellaufwerk Hardlinks unterstützt, also z.B. mit NTFS formatiert wurde). Auf diese Art und Weise befindet sich auf dem Backup-Laufwerk immer eine komplette Kopie der Quellverzeichnisse vom jeweiligen Datum. Jedoch wird nur der Platz einer Kopie plus der veränderten Dateien benötigt. Wird eine alte Backup-Kopie nicht mehr benötigt kann sie ohne Probleme entsorgt werden, indem einfach das entsprechende Backup-Verzeichnis gelöscht wird. Von der Idee her entspricht HardlinkBackup dem rsyncbackup.vbs der Zeitschrift c’t, erweitert um eine grafische Benutzeroberfläche und viele weitere Features.

HardlinkBackup
Aktuelle Version: Version 2.2.17 vom 06.08.2017
Download:
(32-bit version) oder (64-bit version) Größe: ca. 8,69 MB
Readme/Changes: ReadMe.txt Bitte beachten Sie die Lizenzvereinbarung.
Handbuch/Hilfe: Download (PDF, deutsch)
Unterstützte Betriebssysteme: Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows Server 2008 R2, Windows 7, Windows 8/8.1, Windows Server 2012, Windows 10
Lizenzen: Community Lizenz Professional Lizenz Enterprise Lizenz
Preis: kostenlos 39 € 69 €
Einsatzgebiet: Nicht-Kommerziell Nicht-Kommerziell Kommerziell
Sprachunterstützung: Englisch, Deutsch, Französisch, Spanisch
Features:
Schnelle, inkrementelle Sicherung beliebig großer Verzeichnisse Ja Ja Ja
Verschiedene Backup-Modi (Hardlink, Linkskript, Move, Mirror) Ja Ja Ja
Verwendung von Hardlinks (platzsparende Sicherung) Ja Ja Ja
Wiederherstellung mit Windows-Bordmitteln (Kein Programm notwendig) Ja Ja Ja
Sicherung auf lokalen, USB & Netzlaufwerken sowie Unterstützung vieler NAS Ja Ja Ja
Unterstützung langer Pfad- und Dateinamen Ja Ja Ja
Intuitive Benutzeroberfläche Ja Ja Ja
Management von mehreren Backups Ja Ja Ja
Sicherung von Linkstrukturen (Ermöglicht Backup von Backups) Ja Ja Ja
Überprüfen und Wiederherstellen von Backups Ja Ja Ja
Sichern von geöffneten Dateien   Ja Ja
Planung automatisierter Backups   Ja Ja
Emailbenachrichtigung   Ja Ja
Automatisches, regelbasiertes Aufräumen von Backups   Ja Ja
Batchmodus (Ausführen mehrerer Backups nacheinander)   Ja Ja
Erkennung verschobener und umbenannter Dateien   Ja Ja
Differentielle Sicherung großer Dateien   Ja Ja
Unterstützung für Notebook-Backup (Überwachung von Ziellaufwerk und Netzwerkverbindung)   Ja Ja
Durchführung von Skripten vor und nach dem Backup   Ja Ja
Verwendung zweier Backupziele gleichzeitig     Ja
Kommerzielle Nutzung     Ja
Erwerb über Partner: HardlinkBackup, Download bei heise
  Alternativ kann HardlinkBackup auch direkt beim Autor erworben werden (Achtung: längere Bearbeitungszeiten). Einfach E-Mail an software@lupinho.net.

Screenshots:

  1. avatar
    Bodo
    9. November 2016, 06:40 | #1

    @lupinho
    Hallo…
    Im Autostart steht auch nix drin…. Dienste sind auch sauber,,,
    Kann ich dir die Große logdatei sonst mal schicken ??

  2. avatar
    Bodo
    9. November 2016, 07:08 | #2

    Bodo :
    @lupinho
    Hallo…
    Im Autostart steht auch nix drin…. Dienste sind auch sauber,,,
    Kann ich dir die Große logdatei sonst mal schicken ??

    Hat geklappt… Habe alle Schlüssel gelöscht die in diesem Abschnitt der Logdatei waren…die waren zwar leer aber jetzt gats geklappt

    MSI (s) (40:50) [06:42:19:554]: Calling SRSetRestorePoint API. dwRestorePtType: 0, dwEventType: 102, llSequenceNumber: 0, szDescription: „HardlinkBackup (64 bit) wird installiert“.
    MSI (s) (40:50) [06:42:19:554]: The System Restore service is disabled. Returned status: 1058. GetLastError() returned: 1058
    MSI (s) (40:50) [06:42:19:554]: Server not locked: locking for product {0D8ABB8D-DB07-4DAE-85D3-CBAEED106B8E}
    Aktion beendet um 06:42:19: InstallInitialize. Rückgabewert 1.
    MSI (s) (40:50) [06:42:19:647]: Doing action: RemoveExistingProducts
    Aktion gestartet um 06:42:19: RemoveExistingProducts.
    MSI (s) (40:50) [06:42:19:647]: Transforming table Error.

    MSI (s) (40:50) [06:42:19:647]: Transforming table Error.

    MSI (s) (40:00) [06:42:19:647]: Resetting cached policy values
    MSI (s) (40:00) [06:42:19:647]: Machine policy value ‚Debug‘ is 0
    MSI (s) (40:00) [06:42:19:647]: ******* RunEngine:
    ******* Product: {57D9BC5D-8AA1-434C-A7CB-FE398BB4CFC6}
    ******* Action:
    ******* CommandLine: **********
    MSI (s) (40:00) [06:42:19:647]: Nicht erwarteter oder fehlender Wert (Name: „PackageName“, Wert: „“) für Schlüssel „HKLM\Software\Classes\Installer\Products\D5CB9D751AA8C4347ABCEF93B84BFC6C\SourceList“.

    CustomAction returned actual error code 1610 (note this may not be 100% accurate if translation happened inside sandbox)
    MSI (s) (40:50) [06:42:19:647]: Note: 1: 1714 2: HardlinkBackup (64 bit) 3: 1610
    MSI (s) (40:50) [06:42:19:647]: Transforming table Error.

    MSI (s) (40:50) [06:42:23:932]: Transforming table Error.

  3. 9. November 2016, 09:41 | #3

    Was hat geklappt? Kannst Du jetzt die aktuelle Version sauber installieren? Weißt Du, was den Fehler verursacht hat (Produkt „D5CB9D751AA8C4347ABCEF93B84BFC6C“)?

  4. avatar
    upsi
    11. November 2016, 12:35 | #4

    Ich spiele gerade mit der Community-Lizenz herum und habe ein paar Backups gemacht (Hardlink). Wenn ich nun im Explorer (W7) mit der rechten Maustaste -> Eigenschaften, die Ordnergrößen vergleiche, sind alle Backups gleich groß (auch ohne Änderung an der Quelle). Gaukelt mir das Windows vor oder habe ich etwas übersehen?

    • 11. November 2016, 13:00 | #5

      Windows zählt in der Ordnergröße einfach die Dateigrößen zusammen. Dabei werden Hardlinks nicht berücksichtigt; d.h. sie werden genau wie die Datei gezählt. Das ist konsistent zur Darstellung – denn auch im Explorer kann man Hardlinks nicht erkennen. Ich finde das noch nicht mal schlecht; allerdings verwundert es halt bei der Nutzung eines Tools wie HardlinkBackup, was von der Möglichkeit, Hardlinks zu benutzen (die durch Windows API’s gegeben ist), massiv nutzt.
      Letztendlich siehst Du den Effekt am ehesten beim freien Speicher: Wenn Dein Rechner nichts anderes macht, wirst Du sehen, dass ein neues Backup derselben Dateien keinen weiteren Speicherplatz belegt, obwohl Windows behauptet, der neue Backupsatz würde nochmal x GB belegen…

  5. avatar
    upsi
    11. November 2016, 13:28 | #6

    @lupinho
    Vielen Dank für die superschnelle Antwort! Ich habe das getestet: ein backup braucht natürlich schon ein wenig Platz (ca. 1K), aber tatsächlich nicht die im Explorer angegebenen GB. Gekauft! DANKE!

  6. avatar
    Lucien
    13. November 2016, 22:09 | #7

    @lupinho
    Mit „wahnsinnig lange“ meine ich über eine Woche und NULL Aktivität! Da ich die Daten über Explorer nicht läschen kann, kann ich natürlich auch die Dauer nicht bestimmen. Löschen funktionierte einwandfrei „vorher“ (Upgrade Windows 10? Upgrade HardLinkBackup?)

    Ich werde mal versuchen eine Logdatei zu erstellen. Viellecht bekomme ich ja gleiches Problem bei einem „übersichtlichen“ Dataset.

  7. avatar
    Bodo
    16. November 2016, 09:10 | #8

    lupinho :
    Was hat geklappt? Kannst Du jetzt die aktuelle Version sauber installieren? Weißt Du, was den Fehler verursacht hat (Produkt „D5CB9D751AA8C4347ABCEF93B84BFC6C“)?

    Hallo…
    In diesem Schlüssel stand ja nichts drin… darum weiß ich nicht welches Produkt dort gemeint war..
    Auf jeden fall ging danach die Installation sauber bis zum Ende..

  8. avatar
    klausi
    30. November 2016, 13:24 | #9

    Ich habe HLB testweise auf meine PC unter Win10 installiert und etwas auf mein Synology NAS DS214+ gesichert. Wie kann ich feststellen, ob tatsächlich Hardlinks erzeugt wurden?

  9. avatar
    klausi
    30. November 2016, 16:32 | #10

    HLB erzeugt auf meinen NAS definitiv keine Hardlinks; denn bei jedem Backup nimmt die Gesamtgröße aller Backups auf dem NAS um die Größe aller Dateien zu. Mit einer USB-Platte mit NTFS klapt es aber.

    Ich frage mich aber, was HLB tatsächlich nützt, im Vergleich zu einer Synchronisation/Mirroring zwischen dem Quellverzeichnis und dem Backupverzeichnis oder einem versionieenden Backup.
    Bei der Synchronisation werden gelöschte und veränderte Dateien aus dem Backup gelöscht, nur die aktuellen bleiben erhalten und benötigen Speicherplatz.
    Mit HLB sind alle aktuellen Dateien im aktuellen Backupverzeichnis und die Gelöschten und die vorherige Version der geänderten im vorigen Backupverzeichnis; ich kann aber nicht gezielt alte Versionen finden, nur wenn ich zusätzliche Informationen habe (z.B. die Datei name.end sollte im Backup von Vorgestern sein).
    Ein versionierendes Backup zeigt mir aber alle Versionen einer Datei.
    Es wäre daher sinnvoll, wenn HLB im aktuellen Verzeichnis Links auf die alten Versionen in früheren Verzeichnissen erzeugen würde bzw. im vorherigen Backup schon vorhandene Links übernimmt, falls die zugehörigen Dateien noch vorhanden sind.

  10. 1. Dezember 2016, 01:08 | #11

    @klausi
    Die Frage kam schon öfter: Nur weil jeder Backupsatz gleich groß ist, heisst das nicht, dass keine Hardlinks erzeugt wurden. Bitte gucke stattdessen mal auf den noch freien Speicherplatz! Man kann auf einer 2TB Platte locker 10 Backups machen, wobei jedes Backup 1TB groß ist, und trotzdem sind noch 950GB frei!

  11. avatar
    klausi
    1. Dezember 2016, 12:03 | #12

    Unter Win NTFS hat der Rootodner von 3 Backups von 1 GB auch rund 1 GB, aber jedes einzelne Backup, d.h. jeder Unterordner 1 GB.
    Im NAS hat jedes Backup 1GB und der Rootordner 3GB; und zwar sowl im WinExplorer als auch im Fileexplorer des NAS.

  12. avatar
    PeterP
    1. Dezember 2016, 15:19 | #13

    Ich würde trotzdem nochmal Lupinhos Vorschlag folgen, den freien Speicher im Vergleich nach einem weiteren Backup zu checken.

    Also:
    – Freien Speicher auf dem NAS notieren.
    – Ein weiteres Backup machen.
    – Freien Speicher des NAS mit dem Notierten vergleichen.
    Wenn nun tatsächlich 1GB weniger freier Platz auf dem NAS ist, werden keine Hardlinks angelegt, ansonsten werden Hardlinks angelegt.

  13. avatar
    Markus Weber
    17. Dezember 2016, 12:06 | #14

    Habe gerade HardlinkBackup heruntergeladen und werde es testen. Als das Programm gestartet wurde, ist mir aufgefallen, dass unter Info unten rechts ein Button angezeigt wird, auf welchem SCHLIEBEN steht. Es gibt wohl nichts Hässlicheres als Programme in deutscher Sprache, vor allem wenn auch in der Grossschreibung am DEUTSCHEN ß festgehalten wird, obwohl es dieses hässliche „Beta-Zeichen“ gar nicht als Grossbuchstaben gibt. In der Schweiz schreiben wir einfach SCHLIESSEN statt dem deutschen SCHLIEßEN, was sich als SCHLIEBEN liest. Zum Glück kann man in den Einstellungen des Programmes auf Englisch umstellen, sonst wäre mein Test wegen hässlichem DEUTSCHEM UI bereits beendet.

    • 17. Dezember 2016, 14:10 | #15

      Ok. Ist mir noch gar nicht aufgefallen. Das betrifft primär auch nur den Info-Dialog; muss mal gucken, wo sonst noch. Das kann ich leicht beheben und beim nächsten Update rausbauen.

  14. avatar
    salcin
    25. Dezember 2016, 12:59 | #16

    Ich habe die Community Version jetzt testweise im Einsatz und hatte schon mehrere Abbrüche wegen Dateien, auf die nicht zugegriffen werden konnte. Warum wird ~100 nicht zugreifbaren Dateien einfach abgebrochen und diese nicht übersprungen und später noch einmal der Zugriff getestet? Wenn ich es richtig sehe, werden abgebrochene Backups nicht als Grundlage von Hardlinks verwendet. So ist es gerade bei größeren Backups ärgerlich, dass alle Dateien noch einmal kopiert werden. Außerdem können abgebrochene Backups nicht auf einen Blick erkannt werden – eine Tilde (~) wie bei dem c’t Hardlink Backup fände ich hier angebracht, um per Sichtprüfung im Explorer die Vollständigkeit prüfen zu können und um ggf. nicht vollständige Ordner löschen zu können.

  15. avatar
    Ricard
    31. Dezember 2016, 08:43 | #17

    @Uwe
    Hallo Uwe, hast Du eine Lösung für Dein Problem gefunden. Seit dem Umstieg auf WIN10 auf einem neuen Rechner erhalte ich die gleiche Fehlermeldung. Habe den Alten nochmals reaktiviert > Planungen können ohne Fehlermeldung abgespeichert werden. (Lizenz: Enterprise). Keine Ahnung wo der Fehler liegt.
    Richard

  16. avatar
    Andreas
    16. Januar 2017, 13:22 | #18

    Hallo,

    die Download Buttons sind ohne Funktion.

    Andreas

    • 16. Januar 2017, 13:46 | #19

      Hoppala! Danke für den Hinweis! Ich habe die Seite jetzt wieder repariert.

  17. avatar
    immoHAL
    17. Januar 2017, 16:53 | #20

    Hallo,
    ich habe eine Enterprise-Lizenz die im Moment auf einem alten Server (windows2003) läuft. Nun möchte ich das Programm auf einen neuen Server (Windows2012) inkl. der Lizenz „umziehen“ lassen. Wie ist hier das beste Vorgehen insbesondere hinsichtlich der Übertragung der Enterprise-Lizenz ?
    Vielen Dank, Frank

    • 17. Januar 2017, 18:52 | #21

      Programm installieren, Lizenzschlüssel eintragen. HBD-Dateien ggf. kopieren, Einstellungen anpassen. Evtl. Backupsätze umziehen (z.B. mit dem Mirror-Modus). Wenn alles geht, alte Installation deinstallieren.

  18. avatar
    Klaus
    5. Februar 2017, 10:45 | #22

    Hallo,
    ich habe eine Enterprise-Lizenz die auf einem SBS2011 verwendet wird (Windows 2008 R2).
    Seit Anfang Februar funktioniert der automatische Start über die Aufgabenplanung nicht mehr.
    (Wenn ich das Backup manuell starte, läuft es hingegen durch)

    Der Task startet, bleibt dann aber endlos im Modus „Aufgabe wird ausgeführt“.
    Die letzte Meldung im Verlauf lautet: „ID 129 Prozess für die erstellte Aufgabe“.
    Es gibt keine auffälligen Einträge in der Ereignisanzeige.
    Am Backup-Ort wird kein Verzeichnis erstellt.
    Es gibt keine Einträge im Verzeichnis C:\ProgramData\Lupinho.Net\HardlinkBackup\CachedBackupSets.
    Der Dienst „HardlinkBackup Service“ läuft.

    Das ganze passiert sowohl mit der Version (64 bit) vom Dezember, wie mit der aktuellen.

    Können Sie mir einen Tipp geben?
    (Ich hatte mal Aufgaben im Aufgabenplaner manuell gelöscht- das sollte aber doch keinen Einfluss haben oder?)

    Viele Grüße und schon mal Danke im voraus
    Klaus

  19. avatar
    Jochen
    5. Februar 2017, 18:13 | #23

    Hallo Lupinho,
    ich bin ein begeisterter Nutzer des Programms. Was jedoch etwas umständlich ist es folgenden Verzeichnis-Filter zu realisieren:

    Quelle: c:/user/jochen
    Filter : -AppData +AppData/*/garmin

    Bei dieser Konstellation wird AppData überhaupt nicht gesichert. Nach vielen vergeblichen Versuchen blieb nur die mühselige Lösung

    Filter : -AppData/*/a* -AppData/*/b* -AppData/*/c* …….. -AppData/*/z*

    übrig.

    Gruß Jochen

  20. avatar
    Klaus Müller
    14. Februar 2017, 08:10 | #24

    Guten Tag ,
    ich konnte mein Propbelm zwischenzeitlich lösen
    Viele Grüße
    Klaus

  21. 15. Februar 2017, 15:34 | #25

    @Jochen
    Korrekt: Zunächst berücksichtigt HardlinkBackup Einschlüsse, dann werden dort Verzeichnisse ausgeschlossen.
    Daher musst Du es momentan so machen. Ich kenne das Thema auch und werde dafür in zukünftigen Versionen eine elegantere Lösung anbieten – dauert leider nur etwas ;).
    Gruß,
    Lupinho.

  22. avatar
    Jan
    15. März 2017, 20:35 | #26

    @Heiko

    Ich hatte auch das Problem, dass im Log folgende Meldung stand:

    WRN: The file system does not support setting of creation times of files. File creation times cannot be saved to backed up files.

    Zusätzlich wurde in der Log-Zeile davor gemeldet, dass SupportsAlternativeDataStreams nicht unterstützt würde:

    Support (+/-/?): +PreserveCaseNames,+SupportUnicodeNames,+PersistentAcls,+SupportCompression,+SupportsSparseFiles,+SupportsReparsePoints,+SupportsEncryption,+SupportsHardLinks,+SupportsHardLinkRead,+SupportsSymLinks,-SupportsAlternativeDataStreams,-ReadOnly,+WriteAccess,+WritePermissions

    Es handelt sich aber um eine NTFS-Partition. Sie befindet sich zwar auf einer externen Festplatte, die per USB angeschlossen ist. Das sollte aber keine Auswirkung auf das SupportsAlternativeDataStreams-Feature haben.

    Dann habe ich testweise HardLinkBackup mit Administratorrechten ausgeführt. Und siehe da: SupportsAlternativeDataStreams wird als unterstützt gemeldet, und die Warnung bzgl. der „creation times of files“ ist auch weg:

    INF: Support (+/-/?): +PreserveCaseNames,+SupportUnicodeNames,+PersistentAcls,+SupportCompression,+SupportsSparseFiles,+SupportsReparsePoints,+SupportsEncryption,+SupportsHardLinks,+SupportsHardLinkRead,+SupportsSymLinks,+SupportsAlternativeDataStreams,-ReadOnly,+WriteAccess,+WritePermissions

    @Lupinho: Könntest du das vielleicht bei Gelegenheit untersuchen? Es wäre schön, wenn diese Warnungen out-of-the-box (also ohne explizit „Als Administrator ausführen“ _nicht_ kämen. Meine Beobachtungen habe ich unter Windows 7 Home Premium gemacht; mit Version 2.2.15 von HardLinkBackup.

  23. avatar
    Andreas
    5. April 2017, 08:33 | #27

    Ich sichere mein Fotoarchiv mit HardlinkBackup und habe die aktuelle Version 2.2.15 installiert. Beim Einsatz einer neuen leeren 4TB Wechselfestplatte – das Archiv sind 1,5TB – wird nun als Durchschnittsgeschwindigkeit gerade mal 25MB/s ausgewiesen und das Backup würde 18 Stunden dauern? Natürlich an USB 3.0 Port, wo ich eigentlich min. 60-80 MB/s erwarte.

    – Welche Durchschnittsgeschwindigkeiten sind denn normal?
    – Kann man das Kopieren und Verlinken beschleunigen?

    Gruß
    Andreas

  24. avatar
    Andreas Weibel
    14. April 2017, 00:20 | #28

    Guten Tag,

    Wir haben unser Backup eingerichtet und grundsätzlich funktioniert alles super – mit einer Ausnahme: Immer wenn .psd-Dateien (Photoshop) gebackupt werden sollen, kriegen wir diese Fehlermeldung:

    Error: An error occurred while copying „\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy86\pfad\datei.psd“ to „\\UCHTENHAGEN\Zeus-Drive-E\pfad\datei.psd“: Access to the path is denied.

    Wir finden nicht heraus, was das Problem sein könnte – die Berechtigungen auf den psd-Dateien sind dieselben wie bei den Dateien, die im selben Verzeichnis liegen.

    Ist das ein Problem, das bereits früher mal jemand hatte?

    Viele Grüsse,
    Andi

    • 15. April 2017, 22:44 | #29

      Kommt der Fehler auch wenn „Kopieren von Dateien in Benutzung“ (Schattenkopien) aus ist? Falls nein, kann es auch an der Konfiguration der Schattenkopien liegen.

  25. avatar
    Wilfried Bauer
    14. April 2017, 23:15 | #30

    Ich muss wissen, wie viel Speicherplatz meine Backups auf dem NTFS-Server tatsächlich benötigen (die Aufsummierung im Explorer ist ja falsch, da sie Hardlinks mit dem Platzbedarf der kompletten Dateien berechnet). Hier wird immer empfohlen den freien Speicher im Auge zu behalten. Das würde bedeuten, dass ich, um den tatsächlichen Platzbedarf zu kennen, alle Dateien aus dem Backup löschen müsste … Das entspricht nicht wirklich dem Gedanken eines Backups.

    Wie kann ich den tatsächlich benötigten Speicherbedarf non-destruktiv ermitteln?

  26. avatar
    Andreas Weibel
    16. April 2017, 10:50 | #31

    @Lupinho: Besten Dank für die Rückmeldung!
    Ich habe die Einstellung über das Kopieren von Dateien in Benutzung nun geändert. Der Fehler tritt jedoch genauso auf wie vorher… Gäbe es noch eine Option, die eventuell etwas mit dem Fehler zu tun haben könnte?

  27. avatar
    WHS Master
    29. April 2017, 14:57 | #32

    Hallo,
    ich teste gerade das Feature, das ein Backup startet, wenn man eine externe Platte ankoppelt. Funktioniert alles, aber:
    – Es wird nur der erste Backup Job gestartet.
    – Alle weiteren aber ignoriert
    => Da ich mehrere mit unterschiedlichen Policies/Konfigs habe, wäre es prima, wenn diese nacheinander ablaufen würden.
    Im Handbuch habe ich zu diesen Details nichts gefunden.
    Kann man das „fix“ „heilen“? Wäre toll.
    Vielen Dank & Grüße

  28. avatar
    Lars
    30. April 2017, 12:54 | #33

    Hallo Lupino,
    ich mach mit der Professional Version eine DAtebasierte Sicherung meines WHS 2011. Dabei habe ich nun das Feature der Laufwerkserkennung mit automatsichem Start des Backup genutzt. Klappt alles prima, aber:
    – Ich möchte/muss 2 Jobs mit unterschiedlicher Config hintereinander ablaufen lassen.
    – Es startet jedoch immer nur der erste Job
    Habe ich etwas übersehen, oder ist das ein Bug?
    Wäre toll, wenn das Feature „autoerkennung“ alle Jobs hintereinabder abarbeitete, bzw. man das pro Job einstellen könnte.
    Viele Grüße
    Lars

  29. 1. Mai 2017, 18:16 | #34

    @Lars
    Hi Lars,
    es wird nur der erste Job gestartet. Eine Änderung des Verhaltens ist nicht unproblematisch für andere Fälle. Ich denke mal über eine Lösung nach. Was ich mit am ehesten vorstellen könnte, ist eine Ausführung nacheinander, wenn die HBD’s im selben Verzeichnis liegen…

  30. avatar
    Wilfried Bauer
    3. Mai 2017, 22:34 | #35

    @Wilfried Bauer
    Die Frage ist immer noch offen. Auch auf eine gleich lautende Email bekomme ich keine Antwort. Ist das die neue Art von Support für Kunden, die die Software bezahlt haben? Und Sie glauben wirklich, dass ich sowas weiter empfehlen werde?

  31. 3. Mai 2017, 23:04 | #36

    @Wilfried Bauer
    Hallo Herr Bauer,
    die Mail ist tatsächlich hinten runter gefallen – mea culpa! Normalerweise beantworte ich alle Anfragen innerhalb möglichst kurzer Zeit; das gelingt mir abhängig von der Arbeitslast gut. In Ihrem Fall nicht. Wenn Sie meinen, deswegen die Sofware nicht weiterzuempfehlen, werde ich das nicht ändern können, auch wenn ich’s schade fände ;). Eine Erinnerung ist aber immer eine gute Idee!
    Inhaltlich: Die Frage war, wie man den tatsächlichen Platzbedarf des Backups nondestruktiv berechnen kann. Die hatte sich aber schon in mein Hirn festgesetzt und ich überlege schon, wie man das integrieren könnte. Eine einfache Lösung die über die Beobachtung des freien Festplattenspeichers hinausgeht, kenne ich momentan nicht. Aber wie gesagt, denke ich über die Frage nach. Vermutlich habe ich deshalb nicht sofort auf die Mail geantwortet.

  32. 4. Mai 2017, 01:16 | #37

    @Wilfried Bauer
    So, das Thema hat mir keine Ruhe gelassen und den Schlaf geraubt. Ich habe ein rudimentäres Kommandozeilen-Tool geschrieben, das – zusammen mit HardlinkBackup 2.2.16 – den Speicherbedarf korrekt berechnet.
    Download: http://www.lupinho.net/software/DirInfo/DirInfo.zip.
    Die Berechnung bezieht die inneren Hardlinks mit ein – d.h. Hardlinks, die ihr Ziel innerhalb des zu berechnenden Verzeichnisses haben. Ist eine Datei ein Hardlink zu einer außerhalb des Verzeichnisses befindlichen Datei, dann zählt sie „normal“ mit. Die Berechnung müsste so eigentlich korrekt sein. Feedback wäre erwünscht!
    Installation: Zip-Datei downloaden. Exe in das Installationsverzeichnis von HardlinkBackup kopieren. Den Pfad zur HardlinkBackup-Installation in die Windows PATH-Variable mit aufnehmen (System->Erweiterte Systemeinstellungen -> Umgebungsvariablen; ansonsten müsste das Kommando mit dem kompletten Pfad aufgerufen werden).
    Viel Spaß damit!

    Beispiel-Aufruf:
    >DirInfo.exe C:\Test\Target\FotosTest2Mir
    DirInfo, Version 2.2.16 (Build 33)
    Aquiring information for directory "C:\Test\Target\FotosTest2Mir"...
    Directory "C:\Test\Target\FotosTest2Mir":
    Total number of directories: 19
    Total number of files: 519
    Total number of symlinks: 0
    Total number of hardlinks: 499
    Total number of inner hardlinks: 418
    Total Size: 8,12 GB (8.719.867.564 Byte)
    Size respecting inner hardlinks: 1,13 GB (1.208.455.417 Byte)

  33. avatar
    Wilfried Bauer
    4. Mai 2017, 12:52 | #38

    @lupinho
    Besten Dank erst mal. Habs installiert und gestartet. Es steht jetzt seit >3 Stunden auf „Aquiring information for directory …“. Ich kann nicht kontrollieren, ob es noch arbeitet. Irgendeine Art von Fortschrittsanzeige wäre hilfreich, z.B. eine Liste bereits abgearbeiteter Pfade.
    Ich lass es jetzt mal laufen in der Hoffnung, dass da noch was kommt.

    PS: Ja, das Backupverzeichnis ist etwas größer… Deshalb ja auch die Frage, WIE groß es in Wahrheit ist.

  34. avatar
    Wilfried Bauer
    4. Mai 2017, 12:59 | #39

    @Wilfried Bauer
    Konkreter:
    Das Backupverzeichnis umfasst ca. 60 Tage je ca. 41.000 Dateien (lt. Win Explorer Eigenschaften).
    Das Backup liegt auf einem Windows basierten Server (NTFS), Zugriff über GBit LAN.

    • 4. Mai 2017, 16:13 | #40

      Oh,
      dann können Sie den Vorgang gleich mal abbrechen. Für Netzwerklaufwerke wird die Funktion nicht tun. Ich hatte aber in meinem engen Zeitfenster gestern Nacht noch keine Zeit, Fehlermeldungen oder Warnungen einzubinden. Hintergrund: Obwohl es problemlos möglich ist, auf Netzwerk-Shares Hardlinks anzulegen, können sie jedoch nicht ausgelesen werden. Ich kann Ihnen nicht sagen, warum das so ist; es handelt sich ja um eine Betriebssystem/Dateisystem-Funktion. Daher kann ich das Verhalten des Servers auch nicht beeinflussen (und theoretisch könnte es auch funktionieren, wenn der Server die Funktion unterstützt). Bei einem Backup ermittelt HardlinkBackup die Fähigkeiten von Quell- und Ziel-Dateisystem; im Log findet sich ein entsprechender Eintrag. Für das Tool muss noch eine entsprechende Prüfung und Meldung rein; gestern ging es mir erstmal um die Funktionalität an sich.
      Wenn Sie HardlinkBackup und das Tool aber auf den Server installieren, können Sie den tatsächlich belegeten Speicher schon damit ermittln. Als Nebeneffekt ist die Berechnung auch deutlich schneller fertig als bei der Abfrage über das Netzwerk.

  35. avatar
    Wilfried Bauer
    5. Mai 2017, 13:37 | #41

    @lupinho
    Ich habe das Tool jetzt mal auf ein anderes Backup angesetzt, das innerhalb des Rechners auf einer anderen Festplatte liegt. Auch das läuft jetzt schon seit mehreren Stunden… wobei ich anmerken muss, dass dieses Backup noch um einiges größer ist. Da reden wir von mindestens 10M Dir-Einträgen. Die Fortschrittsanzeige einzubauen ist also in jedem Fall ratsam. (Mit einem klitzekleinen Testbackup lief es in Sekundenbruchteilen durch; prinzipiell ist die Funktion also gegeben)
    Ich lass das jetzt mal für ’nen Tag oder zwei laufen, oder bis es zum Ende kommt. Vielleicht haben Sie ja mal Zeit für die Fortschrittsanzeige.

  36. avatar
    Wilfried Bauer
    8. Mai 2017, 14:23 | #42

    @Wilfried Bauer
    Das Tool arbeitet nun seit Freitag an dem o.g. Backup und ist immer noch nicht fertig. Es sind 15M Dir.Einträge. Ich kann nicht glauben, dass das so noch in Ordnung ist. Die Fortschrittsanzeige würde helfen 🙂 …

    • 8. Mai 2017, 22:17 | #43

      Das kann in der Größenordnung schon dauern. Das Auslesen der Hardlinks braucht Zeit; vor allem, wenn es so viele sind. Ich würde es erstmal zuende laufen lassen.
      Ich habe mittlerweile weiter am Tool gebastelt, etwas an der Performance geschraubt und eine Art Fortschrittsanzeige eingebaut. Download wie gehabt unter: http://www.lupinho.net/software/DirInfo/DirInfo.zip

  37. avatar
    Wilfried Bauer
    9. Mai 2017, 14:42 | #44

    @lupinho
    Die neue Version läuft. Die Fortschrittsanzeige (danke!!!) sagt mir, dass es voraussichtlich ca. 130 Stunden, also 5 1/2 Tage dauern wird, bis das Ergebnis da ist. Damit muss ich leben.

  38. avatar
    Alexander Becker
    9. Mai 2017, 20:00 | #46

    Nur mal so als Idee: Könnte man nicht alle Index XML als Datenbasis für die Linksuche verwenden?
    Da steht doch wahrscheinlich drin welche Verlinkungen vorgenommen wurden, oder?

    • 9. Mai 2017, 20:42 | #47

      Nein, das geht leider nicht. In der Index-Datei werden nicht alle Hardlinks vermerkt; zum einen würde die Datei riesig werden und zum anderen kann man nicht in allen Index-Dateien Links nachtragen, womit es viele Möglichkeiten (durch Löschen von Backupsätzen) gibt, dass nicht alle Links gefunden werden. Außerdem ist das Tool so unabhängig davon, ob HardlinkBackup oder ein anderes Tool die Links angelegt hat.

  39. avatar
    Wilfried Bauer
    12. Mai 2017, 12:39 | #48

    @Wilfried Bauer
    DirInfo läuft noch immer; ist inzwischen bei 7 von 15 Millionen Files angelangt. Soweit alles ok.
    Aber es zeigt sich jetzt ein anderes Problem: Der Taskmanager meldet mir, dass DirInfo.exe inzwischen 4,6GB Speicher belegt. Gegen Ende der Analyse dürfte das also auf 10GB auflaufen. Muss das so sein? Mein Rechner hat zwar 16GB RAM, aber die sind eigentlich zum arbeiten da 🙂 …

  40. 17. Mai 2017, 00:27 | #49

    @Wilfried Bauer
    Wie sieht’s aus, ist es durch gelaufen? Den Hauptspeicherbedarf kann ich mir momentan noch nicht erklären; das checke ich nochmal.

  41. avatar
    Anna Schneider
    17. Mai 2017, 11:01 | #50

    Hallo,
    ich habe gestern das neuste Update gemacht und jetzt wird die Festplatte auf die ich die Backups gemacht habe leider nicht mehr angezeigt.
    Tritt das Problem noch irgendwo auf? Kennt jmd die Lösung für das Problem?
    Vielen Dank!

    • 17. Mai 2017, 11:35 | #51

      Das kann eigentlich nichts mit HardlinkBackup zu tun haben, wenn Du die Festplatte in Windows nicht mehr siehst!

  42. avatar
    Stephanie
    17. Mai 2017, 11:34 | #52

    Mir gelingt das Backup nicht. Ich bekomme die Fehlermeldung „Prozess kann auf die Datei nicht zugreifen, da sie von einem anderen Prozess verwendet wird“. ich nutze Windows 10. Wie kann ich herausfinden, was genau das Backup aufhält?

    • 17. Mai 2017, 11:40 | #53

      Das liegt an der Restriktion der Community-Lizenz. Die kann keine Dateien sichern, die in Benutzung sind. Um das zu ändern müsstest Du die Professional Lizenz kaufen, dann geht das problemlos. Alternativ kannst Du händisch mit vssadmin eine Schattenkopie anlegen, mounten und dann davon sichern.

  43. avatar
    Stephanie
    17. Mai 2017, 13:18 | #54

    Wir haben einen zweiten Rechner im Haushalt, der auch auf Windows 10 läuft und auch nur die Community Lizenz hat. Da geht das Backup ohne Probleme.

    • 17. Mai 2017, 18:49 | #55

      Das mag ja sein. Der Fehler tritt auf wenn Dateien, die gesichert werden sollen, gerade von einem Programm geöffnet sind. Vielleicht tritt die Situation bei dem anderen Rechner nicht auf.

  44. avatar
    Wilfried Bauer
    17. Mai 2017, 17:36 | #56

    @Wilfried Bauer
    Wie sieht’s aus, ist es durch gelaufen? Den Hauptspeicherbedarf kann ich mir momentan noch nicht erklären; das checke ich nochmal.

    Nein, läuft immernoch; ist inzwischen sehr träge geworden. Gestern Nachmittag war es bei 11.000.000 Files, nun bei 11.768.000. Der Speicherbedarf bleibt bei 4,6GB hängen und steigt nur noch marginal an (2. Stelle hinter dem Komma). Aber auch 4,6GB klingt für diese Aufgabe sehr sehr hoch.
    Ich wäre auch froh, wenn er mal durch wäre und ich könnte wieder speicherintensive Dinge bearbeiten, oder wenigstens mal rebooten. Aber dann muss DirInfo ja wieder von vorne anfangen. Also lass ich ihn fertig laufen.

  45. avatar
    Stephanie
    19. Mai 2017, 11:20 | #57

    Ich habe die Professional Lizenz gekauft. Leider kann ich das Backup trotzdem nicht ausführen. Die Fehlermeldung ist immer noch die gleiche: „Prozess kann auf die Datei nicht zugreifen, da sie von einem anderen Prozess verwendet wird. Ist jemand schon einmal auf das gleiche Problem gestoßen?

  46. 19. Mai 2017, 12:07 | #58

    @Stephanie
    Bitte aktiviere unter „Modus“ die Option „Kopiere Dateien, die in Benutzung sind“!

  47. avatar
    Stephanie
    19. Mai 2017, 22:30 | #59

    Vielen Dank. Jetzt hat es funktioniert.

  48. avatar
    Wilfried Bauer
    23. Mai 2017, 09:58 | #60

    @Wilfried Bauer
    Ein weiteres Update:
    DirInfo läuft immernoch und ist jetzt bei 12.333.021 Files. Innerhalb von 6 Tagen (vom 17.5. bis heute 23.5.) hat er also grade mal 600.000 Files geschafft. Der Prozess ist also noch viel träger geworden. Ich muss mir langsam überlegen, ob ich ihn nicht abbrechen muss, da von meinen 16GB Speicher inzwischen nur noch 14MB frei sind. DirInfo belegt inzwischen 4,65GB RAM.

  49. avatar
    Wilfried Bauer
    23. Mai 2017, 14:04 | #61

    @Wilfried Bauer
    Ich musste den Prozess abschießen. Mit dem Rechner ließ sich nicht mehr arbeiten. Es ist für mich nicht nachvollziehbar, warum die Abarbeitung mit zunehmender Zahl bearbeiteter Files immer länger dauert. Das scheint ja exponentiell hochzugehen. Seit meiner Email heute morgen (vor 4 Stunden) wurde kein einziges File bearbeitet, d.h. Stand nach wie vor bei 12.333.021. Außerdem klingt der immense Speicherbedarf verdächtig nach Memory Leak. Korrigiere mich bitte, wenn ich da falsch liege.

    • 23. Mai 2017, 14:28 | #62

      Wundert mich. Eigentlich sollte der Speicher nur mit der Verzeichnistiefe wachsen, nicht mit der Gesamtzahl. Ein Bug in Richtung MemoryLeak kann man nie so ganz ausschließen, es würde mich hier aber auch wundern. Ich gucke mir das aber nochmal genauer an!

Kommentar Seiten
1 14 15 16 17 292
  1. 1. Dezember 2016, 14:56 | #1