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 rsync fehlgeschlagen?

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.