ZIP-Backups prüfen: Schäden trotz gleicher Dateianzahl erkennen

Ein ZIP liegt im Sicherungsordner und wurde entpackt. Ist sein Inhalt deshalb identisch mit dem Original? Vergleichen Sie relativen Pfad, Bytezahl und SHA256 mit einer Aufzeichnung des Originals. SHA256 ist ein langer, aus dem Inhalt berechneter Fingerabdruck. Auch bei unverändertem Namen und gleicher Größe kann der Vergleich eine Inhaltsänderung erkennen.

Ziel ist ein kleiner Wiederherstellungstest ohne Überschreiben des Originals und das Unterscheiden von fehlenden und veränderten Dateien in der Ergebnistabelle. Die MillionsCode-Redaktion erzeugte dafür 8 künstliche Dateien, komprimierte und entpackte sie tatsächlich und baute anschließend zwei Fehler gezielt ein. Kundendaten und persönliche Sicherungen wurden nicht verwendet.

Messung und Prüfmethode mit 8 Dateien

Der Versuch lief am 28. September 2026 unter Windows mit PowerShell 7.6.0-rc.1 und Microsoft.PowerShell.Archive 1.2.5. Er vergleicht nicht die Kompatibilität verschiedener stabiler Versionen. Enthalten waren eine leere Datei, ein koreanischer Dateiname mit Leerzeichen, zwei inhaltlich verschiedene Dateien mit jeweils 4 Byte, gleichnamige Dateien in verschiedenen Unterordnern, eine Binärdatei mit 256 Byte und eine Notiz. Insgesamt: 8 Dateien, 372 Byte.

Zuerst entstand das Originalverzeichnis mit relativem Pfad wie nested/level2/sample.txt, Größe und SHA256. Der Ordner wurde in ein ZIP gepackt und in einen neuen Ordner entpackt. Dateien wurden anhand desselben relativen Pfads nach Größe und Fingerabdruck verglichen. Nur nach Namen zu vergleichen könnte zwei sample.txt in verschiedenen Ordnern verwechseln.

Der erste Versuch ist der Normalfall. Die beiden anderen sind Kontrollen, ob absichtlich eingebaute Fehler als Fehler erkannt werden. Sie zeigen nicht, dass das ZIP-Werkzeug Daten verloren oder beschädigt hat. Die Redaktion ließ die Datei beim Kopieren aus und änderte den Inhalt nach dem Entpacken in einer separaten Kopie.

Im dritten Versuch blieben Anzahl 8 und Größe 4 Byte unverändert. Eine Prüfung nur nach Ordnergröße oder Anzahl könnte ihn bestehen lassen. Der Fingerabdruckvergleich fand die eine veränderte Datei. Anzahl und Größe sind schnelle Kontrollen; Inhaltsgleichheit ist eine weitere Prüfung.

Die CSV-Ergebnisse lesen

restore-summary.csv fasst die drei Versuche zusammen. restore-comparison.csv enthält 24 Dateizeilen. Case bezeichnet den Versuch und RelativePath den Pfad im Ordner. ExpectedBytes und ActualBytes sind Original- und Vergleichsgröße; die SHA256-Spalten enthalten die Fingerabdrücke.

• MATCH: Größe und Fingerabdruck stimmen an diesem Pfad überein.
• MISSING: Ein Pfad des Originals fehlt. Das leere Größenfeld bedeutet fehlende Datei, nicht 0 Byte.
• HASH_MISMATCH: Gleiche Größe, anderer Fingerabdruck; erneut wiederherstellen und prüfen.
• Das Skript kennt auch SIZE_MISMATCH bei anderer Größe und UNEXPECTED für zusätzliche Dateien. Diese beiden Zweige wurden in den drei Versuchen nicht durch eigene Fehlerfälle getestet.

Bei same_size_change hat same-a.txt beidseitig 4 Byte. Der Originalhash beginnt mit 63C1DD95…, der geänderte mit 96741164…. Verglichen wurden alle 64 Zeichen, nicht nur diese Präfixe. empty.txt war dagegen schon ursprünglich leer und hatte nach normaler Wiederherstellung denselben Hash. „0 Byte bedeutet beschädigt“ würde absichtlich leere Dateien falsch beurteilen.

Sicher nachmachen, bevor eigene Daten geprüft werden

Lesen Sie zuerst den Skripttext und speichern Sie ihn in einem Übungsordner als restore-lab.ps1. Prüfen Sie, dass die Endung nicht .ps1.txt bleibt. Das Skript nimmt keine Benutzerdateipfade entgegen. Es erzeugt bei jedem Lauf einen neuen Ordner neben sich und komprimiert, entpackt und verändert ausschließlich seine künstlichen Dateien. Es enthält weder Löschbefehle für Originaldateien noch eine Option zum erzwungenen Überschreiben vorhandener Wiederherstellungen. Legen Sie es zunächst in einen leeren Übungsordner, lesen Sie es und führen Sie es dort in PowerShell aus. Blockiert eine Unternehmensrichtlinie Skripte, ändern Sie sie nicht eigenmächtig; nutzen Sie den manuellen Ablauf unten zum Verständnis.

Führen Sie im Ordner der gespeicherten Datei aus:

& '.\restore-lab.ps1'

zip_restore soll PASS anzeigen, die beiden absichtlichen Fehlerfälle FAIL. Ist ControlBehavedAsExpected in allen drei Zeilen True, verhielten sich diese Normal- und Fehlerbedingungen wie erwartet. Verwechseln Sie das beabsichtigte FAIL nicht mit einer fehlgeschlagenen echten Sicherung. Öffnen Sie im ausgegebenen neuen Ordner CSV und results.json für Zeitpunkt, Versionen und vollständige Hashes.

Bei einer echten Sicherung benötigen Sie die Originalliste vom Zeitpunkt der ZIP-Erstellung. Ein Vergleich mit inzwischen geänderten aktuellen Dateien kann auch ein korrektes älteres Backup als abweichend markieren. Üben Sie mit Kopien wichtiger Dateien und wählen Sie einen neuen, leeren Wiederherstellungsordner. Entpacken Sie nicht auf die Originalposition.

Die folgenden Pfade sind Beispiele für Ihren Übungsordner. Der erste Befehl komprimiert das Übungsoriginal, der zweite entpackt an einen neuen Ort, die letzten beiden zeigen die Hashes entsprechender Dateien. Die zusätzliche Ebene source entsteht, weil der Ordner selbst komprimiert wurde.

Compress-Archive -LiteralPath '.\source' -DestinationPath '.\trial.zip'
Expand-Archive -LiteralPath '.\trial.zip' -DestinationPath '.\restore-new'
Get-FileHash -LiteralPath '.\source\notes.txt' -Algorithm SHA256
Get-FileHash -LiteralPath '.\restore-new\source\notes.txt' -Algorithm SHA256

Microsoft beschreibt Inhaltsvergleich und SHA256 als Standard in Get-FileHash. Expand-Archive unterscheidet Zielordner und Überschreiboption. Dieses Beispiel verwendet kein -Force zum Überschreiben.

Was trotz bestandenem Test offenbleibt

Q. Ist nach PASS das ganze Backup sicher?

PASS bedeutet hier nur, dass Position, Größe und Inhalt der 8 künstlichen Dateien übereinstimmten. SSD-Geschwindigkeit, Lebensdauer, Cloud-Synchronisationsquote oder Zuverlässigkeit großer Backups wurden nicht gemessen. Der Versuch lief in einer Umgebung; Rechte, Eigentümer, Schlüssel, App-Einstellungen und geöffnete Datenbanken wurden nicht geprüft. Öffnen Sie Tabellen oder Fotos zusätzlich in ihren Apps und prüfen Sie bei Arbeitsprogrammen auch benötigte verknüpfte Daten.

Q. Gilt dasselbe für versteckte und große Dateien?

Compress-Archive dokumentiert ausgelassene versteckte Dateien/Ordner und eine Dateigrößenbegrenzung. Übertragen Sie dieses kleine Beispiel nicht auf eine vollständige Betriebssystem- oder Konfigurationssicherung. Der Versuch enthielt keine versteckten Dateien und keine Dateien ab 2 GB.

Q. Ist mit gleichem Fingerabdruck alles geprüft?

Ist die Vergleichsliste falsch oder ebenfalls manipuliert, beweist Gleichheit nicht das echte Original. Prüfen Sie eine getrennt aufbewahrte Liste samt Erstellungszeit. Bei fehlenden oder abweichenden Dateien stellen Sie den Pfad erneut her, bevor Sie Originale löschen. Erst Listen- und Hashvergleich zusammen mit dem Öffnen benötigter Dokumente liefern konkretere Wiederherstellungsschritte als die bloße Existenz eines ZIP.