ZIP-Datei wird als beschädigt erkannt: Wie prüfe ich ein Archiv und rette die Inhalte?

Wie ZIP intern funktioniert: lokale Header, zentrales Verzeichnis, CRCs und optionale Recovery-Strukturen

Ob ein ZIP-Archiv „beschädigt“ wirkt, entscheidet sich selten an einer einzigen Stelle. ZIP ist kein monolithischer Container, sondern eine Abfolge von Strukturen: Pro Datei gibt es lokale Header und die eigentlichen komprimierten Daten, am Ende steht ein zentrales Verzeichnis (Central Directory) als Inhaltsverzeichnis. Viele Entpacker orientieren sich primär am zentralen Verzeichnis; andere können bei Bedarf aus den lokalen Headern noch einzelne Daten retten. Daraus folgt: Je nachdem, welcher Teil beschädigt ist, variieren Fehlermeldung, Reparierbarkeit und Rettungschancen deutlich.

Grundaufbau: lokale Datei-Einträge und „End of Central Directory“

Ein klassisches ZIP (ohne Sonderfälle) enthält für jede Datei einen lokalen Dateikopf (Local File Header), direkt gefolgt von den (komprimierten oder „stored“) Dateidaten. Optional schließt sich ein Data Descriptor an, falls bestimmte Werte (insbesondere CRC und Größen) beim Schreiben noch nicht bekannt waren. Erst danach können weitere Datei-Einträge folgen. Am Ende der Datei steht das zentrale Verzeichnis, das für jeden Eintrag einen Central-Directory-Record enthält: Metadaten, Dateiname, Attribute sowie vor allem den Offset, an dem der zugehörige lokale Header beginnt. Ganz am Schluss steht der End-of-Central-Directory-Record (EOCD), der die Position und Größe des zentralen Verzeichnisses sowie Zähler (Anzahl Einträge) enthält.

Typische Konsequenz: Fehlt das Ende (z. B. durch einen abgebrochenen Download), kann das EOCD nicht gefunden werden. Viele Tools melden dann „End of central directory record not found“ oder „Archiv ungültig“. Sind dagegen nur einzelne lokale Daten beschädigt, kann das zentrale Verzeichnis weiterhin intakt sein – und das Archiv lässt sich grundsätzlich öffnen, aber einzelne Dateien scheitern beim Entpacken.

Kompressionsmethoden, Flags und warum Parser „aus dem Takt“ geraten

ZIP ist ein Containerformat, das mehrere Kompressionsmethoden zulässt. In der Praxis dominieren „Deflate“ und „Store“ (keine Kompression). Der jeweilige Eintrag enthält eine Methode-ID und Bit-Flags (General Purpose Bit Flag), die steuern, wie Daten zu interpretieren sind. Besonders wichtig ist das Flag, das signalisiert, dass CRC und Größen nicht im lokalen Header stehen, sondern erst im Data Descriptor folgen. Ein Entpacker muss dann beim Lesen die Daten bis zum Ende des komprimierten Streams konsumieren, bevor er CRC und Größen prüfen kann.

Wenn an dieser Stelle Bytefolgen fehlen (Trunkierung) oder zusätzliche Bytes eingefügt wurden (Übertragungs-/Speicherfehler), verliert der Parser die korrekte Grenze zwischen Dateidaten und nachfolgenden Strukturen. Das äußert sich nicht nur als „CRC-Fehler“, sondern häufig als Kaskade: Nach dem ersten defekten Eintrag erscheinen plötzlich viele weitere Einträge „beschädigt“, obwohl nur der Datenstrom an einer Stelle die Strukturverschiebung verursacht.

• Methode/ID-Mismatch: Ein Eintrag deklariert z. B. Deflate, die Daten sind aber nicht (vollständig) ein gültiger Deflate-Stream; Entpacker brechen mit Dekompressionsfehlern ab.
• Data-Descriptor-Pfad: Ist das entsprechende Flag gesetzt, müssen CRC und Größen am Ende des Streams gelesen werden; bei Trunkierung fehlt der Descriptor, wodurch Größenprüfungen scheitern oder Folge-Header falsch interpretiert werden.
• Offset-Kettenreaktion: Ein beschädigter Bereich kann dafür sorgen, dass der nächste erwartete Header nicht an der erwarteten Position liegt; Tools melden dann oft „Header error“ oder „unexpected end of file“ statt eines einzelnen CRC-Problems.

CRCs in ZIP: Integritätsprüfung, aber keine „Reparatur“

ZIP verwendet für jeden Datei-Eintrag typischerweise eine CRC-32 (zyklische Redundanzprüfung), die im Central Directory und – je nach Flags – auch im lokalen Header oder Data Descriptor steht. Beim Entpacken berechnet das Tool die CRC über die dekomprimierten Daten und vergleicht sie mit dem gespeicherten Wert. Eine CRC dient der Erkennung zufälliger Fehler (Bitfehler, beschädigte Sektoren, Übertragungsfehler), nicht der Korrektur. Eine „CRC-Fehlermeldung“ bedeutet daher: Die extrahierten Daten entsprechen nicht exakt dem ursprünglichen Inhalt; das kann von einem einzelnen falschen Byte bis zu umfangreichen Defekten reichen.

Wichtig ist die Einordnung: Eine CRC-Abweichung sagt nichts darüber aus, welcher Teil beschädigt ist. Ursache kann die komprimierte Datenstrecke sein, aber auch ein inkonsistenter Größenwert, der dazu führt, dass zu viel/zu wenig gelesen wurde. Umgekehrt kann ein Archiv strukturell kaputt sein (z. B. zerstörtes zentrales Verzeichnis), ohne dass CRCs überhaupt noch geprüft werden können, weil die Einträge nicht mehr zuverlässig gefunden werden.

Dateinamen, Zeichensätze und das UTF-8-Flag

ZIP speichert Dateinamen und Kommentare als Bytefolgen. Moderne ZIP-Dateien markieren in den Bit-Flags häufig explizit UTF-8 für Dateinamen. Fehlt diese Markierung, hängt die Interpretation historisch vom jeweiligen Tool und der lokalen Codepage ab. Das führt nicht zwingend zu „beschädigt“, aber zu Symptomen, die oft dafür gehalten werden: scheinbar „unlesbare“ Namen, nicht extrahierbare Pfade oder Konflikte durch unterschiedliche Normalisierung/Zeichenersetzung.

Technisch relevant ist dabei: Der Inhalt kann intakt sein, während nur die Metadaten uneinheitlich interpretiert werden. Entpacker unterscheiden deshalb häufig zwischen Strukturfehlern (Header/Offsets/EOCD), Datenfehlern (Dekompression/CRC) und Namens-/Pfadproblemen (Zeichensatz, ungültige Zeichen für das Ziel-Dateisystem).

ZIP64 und große Archive: zusätzliche Enddatensätze

Für sehr große Archive (viele Einträge, große Dateien, Offsets jenseits klassischer 32-Bit-Grenzen) ergänzt ZIP64 das Format um zusätzliche Felder und eigene Enddatensätze (ZIP64 End of Central Directory Record und Locator). Tools, die ZIP64 nicht unterstützen oder die ZIP64-Strukturen nicht finden können (z. B. weil das Ende abgeschnitten ist), melden Archive dann oft als ungültig, obwohl der vordere Teil plausibel wirkt. Umgekehrt kann ein ZIP64-Archiv auch „teilweise“ nutzbar sein, wenn lokale Header lesbar sind, das zentrale Verzeichnis aber nicht mehr erreichbar ist.

Optionale Recovery-Strukturen: was es gibt – und was nicht

Das ZIP-Format selbst definiert keine universelle, herstellerübergreifende „Recovery“-Schicht, die vergleichbar mit Paritätsdateien eine echte Fehlerkorrektur leisten würde. In der Praxis existieren jedoch optionale, tool-spezifische Zusätze. Bekannt ist der „Recovery Record“ in bestimmten RAR-Workflows; bei ZIP ist dies keine allgemeine Standardfunktion, sondern hängt vom Erstellungswerkzeug ab und ist nicht von jedem Entpacker auswertbar.

Daneben sind „Extrafelder“ (Extra Fields) verbreitet: Sie können zusätzliche Metadaten enthalten (z. B. ZIP64-Informationen, Zeitstempel-Erweiterungen). Solche Felder verbessern Kompatibilität und Funktionsumfang, erhöhen aber auch die Anzahl der Stellen, an denen Inkonsistenzen auftreten können. Für die Rettungspraxis ist entscheidend: Je standardnäher und redundanter die Kerndaten (lokale Header plus zentrale Einträge) vorliegen, desto eher lassen sich zumindest Teile des Archivs rekonstruieren.

Typische Ursachen für „beschädigt“-Meldungen: Downloadabbrüche, Split-Archive, Medienfehler, Zeichensatzprobleme und abgebrochene Archivierung

Die Meldung „ZIP ist beschädigt“ ist selten eindeutig: Sie bedeutet in der Praxis, dass ein Entpacker beim Prüfen der ZIP-Strukturen (Header, zentrale Verzeichnisdaten, Größen-/CRC-Angaben oder Ende-des-Archivs-Markierungen) Widersprüche feststellt oder erwartete Daten fehlen. Häufig ist nicht „die Datei“ als Ganzes defekt, sondern einzelne Teile wurden abgeschnitten, verfälscht oder falsch interpretiert. Für eine zielgerichtete Rettung ist daher entscheidend, die Fehlerquelle einzugrenzen: Ist das Archiv unvollständig, inkonsistent zusammengesetzt, physisch fehlerhaft gespeichert oder werden Metadaten (z. B. Dateinamen) falsch gelesen?

Unvollständige Downloads und „abgeschnittene“ Archive

Ein sehr häufiger Grund sind abgebrochene oder unvollständig gespeicherte Downloads. Das Archiv wirkt dann „formal“ wie eine ZIP-Datei (die ersten Bytes passen), aber das Ende fehlt: Die zentrale Verzeichnisstruktur liegt typischerweise am Dateiende. Fehlt dieser Bereich, melden viele Werkzeuge „Unexpected end of archive“, „End-of-central-directory signature not found“ oder pauschal „ungültiges Archiv“.

Typische Auslöser sind instabile WLAN-Verbindungen, Timeouts bei großen Dateien, Proxy-/Gateway-Probleme, zu aggressive Virenscanner-Filter im Downloadpfad oder fehlerhafte Browser-/Download-Manager-Resumes. Kritisch ist außerdem, wenn Webserver Content-Length falsch ausliefern oder eine Zwischenschicht (Reverse Proxy/CDN) Teilinhalte cacht und beim Fortsetzen des Downloads Bytebereiche mischt. Ergebnis sind Archive, deren Dateigröße plausibel wirkt, deren Inhalt jedoch inkonsistent ist.

Ein praktisches Indiz: Die ZIP-Dateigröße unterscheidet sich von der erwarteten Angabe im Downloadportal, oder mehrere erneute Downloads führen zu unterschiedlichen Dateigrößen/Prüfsummen. Auch „sehr schnelle“ Downloads großer Archive können ein Warnsignal sein, wenn tatsächlich nur ein Teil aus Cache geliefert wurde.

Übertragungsfehler und stille Datenkorruption

Nicht jeder Fehler endet in einem Abbruch. Bei Übertragungen über instabile Netze, bei schlecht implementierten Resumes oder bei fehlerhaften Speicherschichten können einzelne Bits kippen, ohne dass der Downloadprozess dies bemerkt. ZIP-Dateien sind dafür empfindlich, weil bereits kleine Abweichungen Kompressionsdaten zerstören: Ein defektes Byte in einem deflate-Stream kann dazu führen, dass ab einer bestimmten Stelle keine Datei mehr korrekt dekomprimiert.

Wenn ein Entpacker „CRC failed“ meldet, ist das oft ein Hinweis auf veränderte Nutzdaten bei grundsätzlich noch intakter ZIP-Struktur: Das zentrale Verzeichnis ist vorhanden, aber die entpackten Daten stimmen nicht zur gespeicherten Prüfsumme. Treten CRC-Fehler selektiv nur bei einzelnen Dateien im Archiv auf, spricht das eher für punktuelle Korruption (Übertragung, RAM/Storage, defekter Sektor) als für ein grundsätzlich „falsches Format“.

Split-Archive und inkonsistente Mehrteiler

Mehrteilige Archive sind eine eigene Fehlerklasse. Sie entstehen als klassische Split-ZIPs (mehrere Teile, zusammen ein ZIP) oder als „gesplittete“ Container aus Archivprogrammen. Problematisch wird es, wenn Teile fehlen, falsch benannt sind, in falscher Reihenfolge zusammengeführt werden oder aus unterschiedlichen Versionen stammen (z. B. Teil 1 aus Download A, Teil 2 aus Download B).

Auch die Verwechslungsgefahr zwischen verschiedenen Mehrteiler-Konzepten ist hoch: Einige Werkzeuge erzeugen Segmente mit Endungen wie .z01, .z02 plus .zip; andere arbeiten mit fortlaufenden Dateinamen wie .zip.001. Ein Entpacker kann dann „beschädigt“ melden, obwohl lediglich das falsche Teil geöffnet wurde oder die Segmente nicht vollständig vorliegen. Zusätzlich scheitert das Entpacken, wenn beim Kopieren auf FAT32/ältere Systeme Teile still gekürzt wurden (z. B. durch Dateigrößenlimits) oder wenn ein Synchronisationsdienst einzelne Segmente als „Konfliktkopien“ dupliziert und so unbemerkt Inkonsistenzen erzeugt.

Medienfehler: SSD/HDD, USB-Sticks, Speicherkarten und Dateisystemprobleme

ZIP-Dateien werden oft als „defekt“ wahrgenommen, obwohl die eigentliche Ursache unterhalb der Dateiebene liegt. Typisch sind Lesefehler auf HDDs (bad sectors), instabile USB-SATA-Bridges, ausfallende USB-Sticks oder Speicherkarten mit verschlissenen Flash-Zellen. Auch ein unsauber getrenntes Laufwerk kann Dateisysteminkonsistenzen erzeugen: Verzeichnis- und Dateimetadaten sind dann nicht mehr stimmig, obwohl die Anwendungsdatei „noch da“ zu sein scheint.

Besonders tückisch: Flash-Medien können Daten „erfolgreich“ schreiben, aber später beim Lesen korrupte Blöcke liefern (oder umgekehrt). Das führt zu ZIP-Fehlern, die je nach betroffener Stelle stark variieren: Ist der zentrale Verzeichnisbereich betroffen, scheitert oft schon die Dateiliste; ist ein komprimierter Datenstrom beschädigt, bricht das Entpacken an einer bestimmten Datei ab.

Zeichensatzprobleme bei Dateinamen: nicht immer „Beschädigung“, aber oft ein Abbruchgrund

ZIP speichert Dateinamen als Bytefolgen; je nach Tool werden sie als UTF-8 markiert oder in einer „lokalen“ Codepage abgelegt. Wird ein Archiv mit einer anderen Annahme geöffnet, erscheinen Umlaute und Sonderzeichen falsch. Das allein ist keine Datenbeschädigung, kann aber Entpacken verhindern: Manche Systeme oder Entpacker verweigern das Anlegen von Pfaden, wenn ungültige Unicode-Sequenzen entstehen, wenn Namen reservierte Zeichen enthalten (z. B. :, * unter Windows) oder wenn Normalisierungsunterschiede aufeinandertreffen (macOS-Dateisysteme können hier besonders auffällig sein).

Auch sehr lange Pfade sind ein Klassiker: Ein Entpacker meldet dann „cannot create file“ oder bricht ab, was in grafischen Oberflächen gelegentlich als „Archiv beschädigt“ missverständlich zusammengefasst wird, obwohl die ZIP-Struktur korrekt ist.

Abgebrochene Archivierung und inkonsistente Metadaten

Wenn die ZIP-Erstellung unterbrochen wurde (Stromausfall, Prozessabsturz, vollgelaufenes Zielmedium, Quota-Limit, verlorenes Netzlaufwerk), ist das Ergebnis häufig ein formal beginnendes ZIP ohne sauber geschriebenes zentrales Verzeichnis. Manche Programme schreiben das zentrale Verzeichnis erst ganz am Ende; ein Abbruch hinterlässt dann zwar lokale Dateieinträge, aber keinen konsistenten Index. Andere Tools aktualisieren das zentrale Verzeichnis inkrementell, sodass eine Teilnutzbarkeit möglich ist, jedoch mit widersprüchlichen Größenangaben oder fehlenden Datenbereichen.

In Unternehmensumgebungen kommt als Sonderfall hinzu: Archivierung auf Netzlaufwerken mit opportunistischem Caching oder auf Cloud-Sync-Ordnern. Wird die lokale Datei als „fertig“ angezeigt, obwohl der Upload noch läuft, und wird sie in dieser Phase weitergegeben, entstehen unvollständige oder gemischte Stände, die anschließend als beschädigt erkannt werden.

• Downloadabbruch/Teilinhalt: Auffällig sind fehlende Endstrukturen und Meldungen wie „End-of-central-directory … not found“; häufig passen Dateigröße oder SHA-256-Hash nicht zur Quelle.
• Stille Korruption: Häufige Indikatoren sind „CRC failed“ oder Abbrüche beim Entpacken ab einer bestimmten Datei, während die Dateiliste noch angezeigt wird.
• Split-Archive-Probleme: Ein Teil fehlt oder ist falsch benannt (z. B. .z01 ohne passendes .zip, oder Segmente .zip.001, .zip.002 nicht vollständig); das Öffnen des falschen Segments führt oft zu „ungültig“.
• Medien-/Dateisystemfehler: Fehler treten nach Kopieren auf externe Medien auf, variieren zwischen Versuchen oder betreffen viele unterschiedliche Archive; verdächtig sind Verbindungsabbrüche über USB und Laufwerke mit Lesefehlern.
• Zeichensatz/Dateiname/Pfad: „Beschädigt“ ist dann meist nur die Oberflächenmeldung; tatsächlich scheitert das Schreiben an ungültigen Zeichen, reservierten Namen oder Pfadlängen (z. B. bei tief verschachtelten Ordnern).

Prüfen und retten in der Praxis: Checksummenvergleich, erneuter Transfer, alternative Entpacker, Extraktion trotz Fehlern, Rekonstruktion und forensisches Vorgehen

In der Praxis entscheidet weniger die Fehlermeldung („ungültiges Archiv“, „CRC-Fehler“, „End-of-central-directory not found“) als eine saubere Reihenfolge der Maßnahmen. Ziel ist, zuerst Integrität und Herkunft zu klären, dann risikoarm zu retten und erst danach zu reparieren oder zu rekonstruieren. Damit sinkt die Wahrscheinlichkeit, dass sich ein bereits beschädigtes Archiv durch wiederholte, ungezielte Versuche weiter verschlechtert (insbesondere bei defekten Datenträgern).

1) Integrität objektiv prüfen: Checksummen, Dateigröße, Vergleichskopie

Wenn eine Quelle für einen erneuten Transfer existiert (Download, Netzlaufwerk, E-Mail-Anhang aus dem Postfach), ist der schnellste Beweis für „wirklich identisch“ ein Checksummenvergleich. Eine übereinstimmende Hashsumme (z. B. SHA-256) zeigt, dass zwei Dateien bitgenau gleich sind; abweichende Hashes weisen auf Übertragungs- oder Speicherschäden hin. Ohne bereitgestellte Prüfsumme hilft zumindest der Vergleich zweier unabhängiger Transfers derselben ZIP-Datei.

Zusätzlich sollten offensichtliche Plausibilitäten geprüft werden: passt die Dateigröße zur Angabe auf der Downloadseite, wurden Proxy/Antivirus-„Downloadsicherungen“ aktiv, liegt ein Quota- oder Timeout-Abbruch vor? Bei sehr großen Archiven sind auch Dateisystemgrenzen und freie Kapazität beim Zielmedium relevant.

• Windows (Hash bilden und vergleichen): Get-FileHash -Algorithm SHA256 "C:\Pfad\Archiv.zip"
certutil -hashfile "C:\Pfad\Archiv.zip" SHA256
• macOS / Linux (Hash bilden und vergleichen): shasum -a 256 "/Pfad/Archiv.zip"
sha256sum "/Pfad/Archiv.zip"
• Dateigröße gegen Quelle prüfen: dir "C:\Pfad\Archiv.zip"
ls -l "/Pfad/Archiv.zip"

2) Erneuter Transfer ohne Zusatzfehler: stabilisieren, verifizieren, unverändert speichern

Bei wiederholbaren Downloads lohnt ein „sauberer“ erneuter Transfer: möglichst kabelgebundenes Netzwerk, ausreichend freier Speicher, keine Synchronisations- oder Backup-Tools, die Dateien während des Transfers umbenennen oder „optimieren“. Wichtig ist außerdem, dass die Datei unverändert gespeichert wird: Einige Systeme hängen an bekannte Endungen zusätzliche Marker an oder entpacken automatisch, was die spätere Prüfung erschwert.

Bei HTTP/HTTPS-Downloads ist ein Tool sinnvoll, das harte Fehler sichtbar macht und bei Bedarf fortsetzen kann. Bei Transfers zwischen Systemen sollte ein Protokoll mit Integritätsprüfung bevorzugt werden. In Unternehmen sind Proxy- und DLP-Komponenten bekannte Ursachen für still veränderte Binärdateien; ein Hashvergleich vor und nach dem Proxy ist dann der schnellste Nachweis.

• Download mit Fehlerausgabe (Linux/macOS, sofern verfügbar): curl -fL -o "Archiv.zip" "https://example.tld/datei.zip"
• Download mit Resume-Funktion (Linux/macOS, sofern verfügbar): curl -C - -fL -o "Archiv.zip" "https://example.tld/datei.zip"
• Nach Transfer sofort verifizieren: sha256sum "Archiv.zip" (bzw. Get-FileHash unter Windows) und mit Quelle/Referenz vergleichen

3) Alternative Entpacker und Archivtest: tolerant entpacken, statt sofort „reparieren“

Verschiedene Entpacker reagieren unterschiedlich streng auf Inkonsistenzen zwischen lokalen Headern, Datenstrom und Zentralverzeichnis. Ein „beschädigt“-Hinweis bedeutet daher nicht automatisch, dass keine Daten mehr extrahierbar sind. Für die Praxis ist entscheidend: erst testen, dann möglichst viel extrahieren, und erst danach destruktivere Reparaturversuche starten.

7-Zip ist häufig toleranter als integrierte Betriebssystemfunktionen und kann Inhalte trotz Fehlern teilweise ausgeben. Unter macOS/Linux liefern unzip oder bsdtar teils bessere Ergebnisse bei Sonderfällen (z. B. bei ungewöhnlichen Dateinamenkodierungen), während 7-Zip wiederum bei defekten Zentralverzeichnissen oft weiterkommt.

• 7-Zip Archivtest (Windows/Linux/macOS, CLI): 7z t "Archiv.zip"
• 7-Zip extrahieren (Ordner festlegen): 7z x "Archiv.zip" -o"Zielordner"
• Info/Listing zur Diagnose: 7z l -slt "Archiv.zip"
• unzip Testlauf (häufig vorhanden auf macOS/Linux): unzip -t "Archiv.zip"
• bsdtar als Alternative (macOS/Linux): bsdtar -tf "Archiv.zip"
bsdtar -xf "Archiv.zip" -C "Zielordner"

4) Extraktion trotz Fehlern: priorisieren, selektiv retten, Ausgabe kontrollieren

Wenn ein Teil des Archivs beschädigt ist, ist selektives Vorgehen oft effektiver als ein Voll-Entpacken, das beim ersten CRC-Fehler abbricht. In der Praxis bewährt sich: zuerst nur listen, dann kleine/ wichtige Dateien gezielt entpacken, dann in Blöcken weitermachen. Jede gerettete Datei sollte anschließend verifiziert werden (z. B. Dateigröße, Öffnen im Zielprogramm, bei bekannten Formaten zusätzliche interne Prüfungen).

Wichtig ist außerdem die Wahl eines frischen Zielordners auf einem zuverlässigen Medium. So bleibt klar nachvollziehbar, was in welchem Durchlauf erfolgreich extrahiert wurde, und es entstehen keine Mischzustände durch teilweise überschriebenen Inhalt.

• Einzelne Datei extrahieren (7-Zip): 7z x "Archiv.zip" "Pfad/Im/Archiv/wichtig.pdf" -o"Zielordner"
• Nur Liste exportieren (7-Zip, zur Priorisierung): 7z l "Archiv.zip" > "inhalt.txt"
• Unzip bei Fehlern fortsetzen (sofern verfügbar): unzip -o "Archiv.zip" -d "Zielordner" (bricht je nach Fehlerbild trotzdem ab; für „so viel wie möglich“ ist oft unzip -FF bzw. -F einen Versuch wert)

5) Rekonstruktion: Repair-Funktionen, Recovery Records, Split-Archive korrekt zusammensetzen

Reparatur bedeutet nicht „magisch wiederherstellen“, sondern meist: ein konsistentes Zentralverzeichnis neu aufbauen oder zumindest so weit zu rekonstruieren, dass Dateien mit intakten Datenbereichen extrahiert werden können. Das klappt am ehesten, wenn die lokalen Header noch lesbar sind und die Defekte eher am Ende des Archivs liegen (typisch bei abgebrochenen Kopiervorgängen).

Falls das Archiv aus Mehrteil-Dateien besteht, scheitert das Entpacken häufig schlicht an einem fehlenden oder falsch benannten Teil. Bei klassischen ZIP-Splits werden Teile oft als .z01, .z02 … und abschließend als .zip geliefert; alle Teile müssen im selben Ordner liegen. Bei ZIP64/Split-Varianten oder von Tools erzeugten Volumes können Namensschemata abweichen. Entscheidend ist: immer den „Startpunkt“ öffnen, den das jeweilige Tool erwartet (häufig die .zip), nicht einzelne Teilstücke.

• 7-Zip „Repair“-Kopie erzeugen (Ergebnis prüfen, kein Garant): 7-Zip hat keine allgemeine „Repair“-Funktion für ZIP wie bei manchen anderen Formaten; sinnvoll ist stattdessen 7z t "Archiv.zip" (Fehlerbild dokumentieren) und anschließend Extraktion aus einer Arbeitskopie versuchen, nicht aus dem Original
• Mehrteiler: Vollständigkeit prüfen: dir *.z?? (Windows) bzw. ls -1 *.z?? (macOS/Linux) und sicherstellen, dass die Enddatei *.zip vorhanden ist
• Mehrteiler mit 7-Zip starten: 7z x "Archiv.zip" -o"Zielordner" (alle Teile im selben Verzeichnis; 7-Zip liest die .z01/.z02 automatisch mit)
• Recovery Records (falls vorhanden): Bei ZIP gibt es keinen herstellerübergreifenden Recovery-Record-Standard. Reparatur ist nur möglich, wenn der Ersteller beim Packen eine Wiederherstellungsinformation eingebettet hat oder zusätzlich Paritätsdaten bereitstellt (z. B. PAR2-Dateien); dann sollte das gleiche Tool oder ein kompatibles Verfahren genutzt werden (z. B. „Repair archive“ im Erstellerprogramm) und stets auf einer Kopie arbeiten

6) Forensisches Vorgehen bei verdächtigem Datenträger: zuerst sektorweise sichern, dann retten

Wenn die ZIP-Datei von einem Datenträger stammt, der bereits Auffälligkeiten zeigt (I/O-Fehler, ungewöhnliche Geräusche, wiederholte Lesefehler, langsame Hänger, SMART-Warnungen), sollte nicht direkt am Original weitergearbeitet werden. Jeder weitere Leseversuch kann Ausfälle beschleunigen oder dazu führen, dass der Controller instabile Sektoren endgültig auslistet. In solchen Fällen ist eine sektorweise Kopie auf ein gesundes Medium die richtige Grundlage; alle weiteren Prüf- und Entpackversuche erfolgen ausschließlich auf dem Abbild bzw. einer Kopie davon.

Bei HDD/SSD ist außerdem relevant, dass „Reparaturtools“ oder Dateisystemprüfungen das Problem verschlimmern können, weil sie Schreibzugriffe auslösen. Für die ZIP-Rettung ist Schreiben auf dem Quellmedium grundsätzlich zu vermeiden. Wenn keine Erfahrung mit Imaging besteht oder der Datenträger bereits deutlich degradiert ist, ist professionelle Datenrettung häufig die risikoärmere Option.

• Linux: sektorweises Imaging mit Protokoll (Beispiel): ddrescue -f -n /dev/sdX "/mnt/backup/datentraeger.img" "/mnt/backup/ddrescue.log"
ddrescue -f -r3 /dev/sdX "/mnt/backup/datentraeger.img" "/mnt/backup/ddrescue.log"
• Arbeitskopie für Rettungsversuche anlegen: cp --reflink=auto "datentraeger.img" "datentraeger_work.img" (sofern Dateisystem/Plattform Copy-on-Write unterstützt) bzw. konventionell kopieren
• ZIP erst nach Imaging anfassen: ZIP aus dem Abbild extrahieren/kopieren und dann 7z t sowie selektive Extraktion durchführen; Originaldatenträger bis zum Abschluss unverändert lassen