Windows Backup Teil 4a/4: Backup mit Historie (Manuell erzeugen)

Wie bereits im Blogbeitrag Linux Backup Teil 3: Eleganteres Sichern mit eigenem Skript beschrieben, wollte ich auch unter Windows eine solche Lösung realisieren. Da unter NTFS Hardlinks möglich sind (siehe Hard-/Softlinks – Teil 3 (Windows): Junctions und symbolische Links gibt es auch noch.) sollte dies doch möglich sein – aber welche Hürden ich hier zu nehmen hatte, das wurde mir erst bei der Ausführung bewusst.

Drei Hinweise vorweg:
Hinweis 1:
Es gibt so eine Lösung bei Heise zum Download (rsyncBackup.vbs) , aber ich wollte das Ganze selber lösen. Ich finde einfach, wenn man sich eine Lösung selbst erarbeitet, lernt man die Mechanismen besser verstehen und lernt somit auch die Möglichkeiten und Funktionen von „Fremdsoftware“ einzuschätzen.
Hinweis 2:
Mein Anspruch an die Lösung:
Nutzen der Windows-Konsole
Nur Systembefehle verwenden (keine zusätzlichen Installationen)
Hinweis 3:
Es gab dann auch gleich ein riesen FAIL, weshalb es hier 2 Blogeinträge werden.

Pack ma´s oa (bayrisch).

Zuerst wurde das Ziellaufwerk präpariert.
Im Ziel-Laufwerk wurden 2 weitere Verzeichnisse angelegt: „orig“ und „archiv“. Wie bereits beim Linux-Backup realisiert, sollen die Dateien vom Quell-Laufwerk auf das Ziel-Laufwerk -> „orig“ synchronisiert, und diese Dateien dann per Hardlinks auf Ziel-Laufwerk -> „archiv“ -> „Datum“ verlinkt werden.
winback4-01

Schritt 1: Synchronisation
Somit war erstmal das Ausführen der Synchronisation nötig

winback4-02

Schritt 2: Präparieren des „Archiv-Ziels“
Da nur Dateien einen Hardlink besitzen können, muss im „Hardlink-Ziel“ die Verzeichnis-Struktur abgebildet werden.
Auch dazu nutzte ich robocopy

winback4-03

Schritt 3: Erzeugen der Hardlinks
Jetzt erzeuge ich die Hardlinks mit Hilfe einer For-Schleife
(Der Einfachheit halber habe ich das in einer Batchdatei mit dem Namen HL.bat realisiert.)

winback4-04
Bis hierher war es (relativ) einfach.

Aber ab jetzt ging es mit der Erfolgswelle erstmal steil bergab.

Ich habe im Quell-Laufwerk die Datei „Datei 2.TXT“ bearbeitet und dann eine weitere Synchronisation vom Quell-Laufwerk zum Ziel-Laufwerk „orig“ ausgeführt.
Da die Datei nun nicht mehr die gleiche Datei ist, bin ich – wie von Linux gewohnt – davon ausgegangen, dass diese Datei ersetz wird. Aber dem war nicht so.
winback4-05

Ergebnis des Lerneffektes (der nach einer kleinen Verwunderungsstarre einsetzte):
Windows ersetzt geänderte Dateien nicht im Ziel-Laufwerk, sondern updatet diese.
Klingt wenig spektakulär, macht aber einen riesigen Unterschied.
Während unter Linux eine Synchronisation mit rsync unterschiedliche Dateien im Ziel-Laufwerk als neue Datei (mit neuer, unabhängiger Inode) anlegt, wird unter Windows (egal ob mit robocopy, copy oder xcopy) die Datei mit der ursprünglichen FileID erneuert.
Das bedeutet, dass unter Linux die Verbindung von vorhandenen Hardlinks aufgelöst wird, unter Windows bleiben diese aber erhalten.

Wie es nach diesem „Fail“ weiter geht und ich das Problem gelöst habe, kommt im nächsten Blogeintrag (Teil4b).