rsync Exit-Code 23 bei defekter Festplatte: Welche Dateien wurden wirklich kopiert?
Beim Kopieren einer alten Festplatte mit rsync endete ein größerer Sicherungslauf mit:
rsync error: some files/attrs were not transferred
(code 23)
Gleichzeitig waren aber bereits hunderte Gigabyte erfolgreich am Ziel angekommen.
Die wichtige Frage war deshalb nicht:
Ist
rsyncfehlgeschlagen?
Sondern:
Welche Dateien fehlen tatsächlich?
Ausgangslage
Eine ältere NTFS-Festplatte sollte auf einen neuen Datenträger kopiert werden.
Verwendet wurde sinngemäß:
rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Backup" \
"/mnt/NEUE_PLATTE/"
Der Kopiervorgang lief lange normal.
Dann tauchten Meldungen wie diese auf:
read errors mapping "...": Input/output error (5)
und schließlich:
rsync error: some files/attrs were not transferred
(code 23)
Exit-Code 23 bedeutet nicht: nichts wurde kopiert
Bei einem großen Verzeichnisbaum kann rsync tausende Dateien erfolgreich übertragen und trotzdem am Ende mit Code 23 zurückkehren.
Im konkreten Fall wurden mehrere hundert Gigabyte übertragen.
Nur einzelne Dateien konnten wegen Lesefehlern der Quellfestplatte nicht erfolgreich kopiert werden.
Deshalb wäre es falsch gewesen, den kompletten Kopiervorgang als unbrauchbar anzusehen.
Entscheidend: endgültige Fehlermeldungen
Während des Laufs gab es vereinzelt Lesefehler bei Dateien, die später trotzdem übertragen werden konnten.
Besonders relevant waren dagegen Meldungen wie:
failed verification -- update discarded
Hier hatte rsync die Zieldatei nicht als erfolgreich übertragen akzeptiert.
Diese Dateien mussten später separat behandelt werden.
Warum rsync dafür praktisch ist
Ein großer Vorteil von rsync ist, dass ein Kopiervorgang erneut gestartet werden kann.
Bereits vorhandene Dateien müssen dabei nicht zwangsläufig komplett noch einmal übertragen werden.
Das ist gerade bei einer angeschlagenen Festplatte hilfreich:
Man möchte möglichst vermeiden, bereits erfolgreich gelesene Daten immer wieder unnötig von der problematischen Platte anzufordern.
—partial bei großen Dateien
Verwendet wurde außerdem:
--partial
Dadurch können teilweise übertragene Dateien erhalten bleiben.
Das kann insbesondere bei großen Dateien sinnvoll sein.
Der verwendete Befehl sah beispielsweise so aus:
rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Verzeichnis" \
"/mnt/NEUE_PLATTE/Ziel/"
Nicht sofort das Dateisystem reparieren
Die auftretenden Fehler waren:
Input/output error (5)
Deshalb wurde zunächst nicht versucht, die alte NTFS-Platte zu reparieren.
Stattdessen wurde ihr SMART-Zustand untersucht:
sudo smartctl -a /dev/sdX
Dort zeigten sich zahlreiche:
Reallocated_Sector_Ct
Current_Pending_Sector
Offline_Uncorrectable
Damit war klar:
Die Ursache war nicht nur ein harmloser Kopierfehler, sondern die Platte selbst war physisch problematisch.
Erst alles Lesbare kopieren
Der weitere Ablauf war:
rsync kopiert alles noch Lesbare
↓
Liste der tatsächlich fehlgeschlagenen Dateien
↓
keine erneute Komplettkopie
↓
nur Problemdateien separat retten
Für die problematischen Einzeldateien wurde anschließend GNU ddrescue verwendet.
Beispiel:
ddrescue -n quelle ziel ziel.ddrescue.map
ddrescue -r3 quelle ziel ziel.ddrescue.map
Damit konnten mehrere Dateien gerettet werden, die rsync zuvor nicht mehr erfolgreich übertragen konnte.
Warum das sinnvoller war als ein Komplett-Image
Im konkreten Fall war der weit überwiegende Teil der Platte noch lesbar.
Deshalb wurde zuerst mit rsync kopiert und ddrescue anschließend nur für die wenigen Problemdateien eingesetzt.
Das vermied einen vollständigen zusätzlichen Lesedurchlauf über die bereits angeschlagene Festplatte.
Für einen anderen Schadensfall kann ein vollständiges sektorweises Abbild sinnvoll sein.
Hier war es aber nicht notwendig, weil die relevanten Daten weitgehend noch dateibasiert lesbar waren.
Praktischer Ablauf
Bei einem ähnlichen Fall würde ich anhand dieser Erfahrung so vorgehen:
1. Daten mit rsync kopieren
2. Fehlerausgabe sichern
3. nicht aufgrund von Code 23 alles verwerfen
4. endgültig fehlgeschlagene Dateien identifizieren
5. SMART prüfen
6. bei Hardwarefehlern keine unnötigen Komplettläufe mehr
7. Problemdateien gezielt mit ddrescue bearbeiten
Fazit
rsync Exit-Code 23 bedeutet:
Nicht alles konnte übertragen werden.
Er bedeutet aber nicht:
Die komplette Sicherung ist unbrauchbar.
Gerade bei einer sterbenden Festplatte kann rsync noch einen sehr großen Teil der Daten erfolgreich sichern.
Die sinnvollere Strategie war in diesem Fall:
erst alles noch Lesbare normal kopieren und anschließend nur die tatsächlich fehlgeschlagenen Dateien gezielt retten.