Daten von einer sterbenden NTFS-Festplatte unter Linux retten: rsync, SMART und ddrescue

Nach einem Wechsel von Windows zu Linux bleiben oft alte NTFS-Festplatten im Rechner: ehemalige Backupplatten, Windows-Systempartitionen oder Datenträger, die irgendwann einmal als Archiv dienten.

In meinem Fall sollte eine solche alte NTFS-Platte zunächst einfach leergeräumt und anschließend für Linux neu formatiert werden. Beim Kopieren größerer Datenbestände traten jedoch wiederholt Input/output error (5) auf. Damit wurde aus einer simplen Aufräumaktion eine Datenrettung.

Dieser Artikel beschreibt den tatsächlich verwendeten Ablauf unter Linux Mint:

  1. Datenträger eindeutig identifizieren
  2. sicherstellen, dass keine Boot- oder Systempartition gelöscht wird
  3. lesbare Daten mit rsync kopieren
  4. den Gesundheitszustand mit SMART prüfen
  5. beschädigte Einzeldateien mit GNU ddrescue retten
  6. gerettete Dateien überprüfen
  7. die defekte Platte anschließend ausmustern

Problem

Die alte Platte war noch als NTFS formatiert und enthielt mehrere hundert Gigabyte an Backups, Bildern, Videos und sehr vielen kleinen Webdateien.

Ein Kopierversuch mit rsync lief zunächst normal, meldete dann aber Fehler wie:

rsync: [sender] read errors mapping "...": Input/output error (5)

ERROR: ... failed verification -- update discarded.

rsync error: some files/attrs were not transferred
(code 23)

Wichtig dabei: rsync konnte den weit überwiegenden Teil der Daten weiterhin kopieren. Betroffen waren einzelne Dateien.

Bevor man in so einer Situation die Platte repariert, neu formatiert oder weitere große Kopieraktionen startet, sollte geklärt werden, ob ein Dateisystemproblem oder ein physischer Plattenschaden vorliegt.

1. Festplatten eindeutig identifizieren

Bevor irgendein destruktiver Befehl ausgeführt wird, sollte klar sein, welches Gerät welches ist.

Eine gute Übersicht liefert:

lsblk -e7 -o NAME,PATH,SIZE,MODEL,FSTYPE,LABEL,PARTLABEL,UUID,MOUNTPOINTS

Zusätzlich:

sudo fdisk -l

Für das aktuell laufende Linux-System ist wichtig:

findmnt -no SOURCE,FSTYPE,TARGET /
findmnt /boot/efi

Damit lässt sich feststellen, auf welcher Partition / liegt und von welcher EFI-Partition das System bootet.

Auch /etc/fstab sollte kontrolliert werden:

grep -Ev '^\s*#|^\s*$' /etc/fstab

Und bei einem UEFI-System:

sudo efibootmgr -v

Im konkreten Fall konnte so eindeutig festgestellt werden:

Diese Prüfung war entscheidend. Ein wipefs oder mkfs auf der falschen Platte wäre nicht reparabel gewesen.

2. Viele Dateien besser mit rsync als per Dateimanager kopieren

Bei Verzeichnissen mit sehr vielen kleinen Dateien kann ein grafischer Dateimanager schnell unübersichtlich oder langsam werden.

Für einzelne Verzeichnisse eignet sich rsync:

rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Quellordner" \
"/mnt/NEUE_PLATTE/Zielordner/"

Die verwendeten Optionen:

-r                  Verzeichnisse rekursiv kopieren
-l                  symbolische Links erhalten
-t                  Zeitstempel erhalten
--partial           angefangene Dateien bei Abbruch behalten
--info=progress2    Gesamtfortschritt anzeigen

Mehrere Ordner lassen sich in einem Lauf angeben:

rsync -rlt --partial --info=progress2 \
"/media/user/ALTE_PLATTE/Ordner1" \
"/media/user/ALTE_PLATTE/Ordner2" \
"/media/user/ALTE_PLATTE/Ordner3" \
"/mnt/NEUE_PLATTE/Sicherung/"

Ein Vorteil von rsync: Der gleiche Befehl kann später erneut gestartet werden. Bereits erfolgreich kopierte Dateien müssen dann nicht komplett erneut übertragen werden.

Nicht jede Lesewarnung bedeutet automatisch Datenverlust

Bei der defekten Platte tauchten manche Dateien während des Kopierens zunächst mit einem Lesefehler auf, konnten bei einem späteren Versuch aber doch übertragen werden.

Entscheidend waren deshalb vor allem Meldungen wie:

failed verification -- update discarded

Diese Dateien waren tatsächlich nicht erfolgreich kopiert worden.

3. SMART prüfen – und nicht nur auf „PASSED“ schauen

Nach den ersten I/O-Fehlern wurde die Platte mit smartctl untersucht:

sudo smartctl -a /dev/sdX

Falls das Programm fehlt:

sudo apt install smartmontools

Interessant waren insbesondere diese Werte:

Reallocated_Sector_Ct
Current_Pending_Sector
Offline_Uncorrectable
Power_On_Hours

Bei der untersuchten Platte wurden unter anderem gemeldet:

Reallocated_Sector_Ct   151
Current_Pending_Sector  1114
Offline_Uncorrectable   561
Power_On_Hours          69315

Gleichzeitig stand weiter oben:

SMART overall-health self-assessment test result: PASSED

Das ist ein gutes Beispiel dafür, warum man sich nicht allein auf PASSED verlassen sollte.

Die Kombination aus

war hier ein klarer Grund, die Platte nicht mehr weiterzuverwenden.

Die Konsequenz war deshalb:

Nicht reparieren und anschließend neu formatieren, sondern zuerst möglichst viele Daten retten und die Platte danach ausmustern.

4. Zuerst die noch lesbaren Daten retten

Bei einer sichtbar ausfallenden Festplatte ist es sinnvoll, nicht sofort stundenlange Tests oder Reparaturläufe zu starten.

Im konkreten Fall wurden zunächst die noch lesbaren Verzeichnisse mit rsync auf andere Datenträger kopiert.

Erst danach wurden die wenigen Dateien bearbeitet, die rsync nicht lesen konnte.

Damit musste die alte Platte nicht mehrfach vollständig durchgelesen werden.

5. Beschädigte Einzeldateien mit GNU ddrescue retten

Für die verbleibenden Dateien kam GNU ddrescue zum Einsatz.

Installation:

sudo apt install gddrescue

Anschließend wurde eine kleine Shell-Funktion verwendet:

BASE="/media/user/ALTE_PLATTE"
OUT="/mnt/NEUE_PLATTE/Rettung"

recover() {
    rel="$1"
    src="$BASE/$rel"
    dst="$OUT/$rel"

    mkdir -p "$(dirname "$dst")"

    echo
    echo "=== RETTE: $rel ==="

    ddrescue -n "$src" "$dst" "$dst.ddrescue.map"
    ddrescue -r3 "$src" "$dst" "$dst.ddrescue.map"
}

Eine Datei konnte damit einfach so bearbeitet werden:

recover "Backup/Bilder/beispiel.jpg"

Zuerst versucht

ddrescue -n

möglichst viel ohne aggressive Wiederholungsversuche zu lesen.

Danach versucht

ddrescue -r3

problematische Bereiche bis zu drei weitere Male zu lesen.

Die Map-Datei merkt sich, welche Bereiche bereits erfolgreich gerettet wurden.

6. Was ddrescue noch retten konnte

Die Ergebnisse waren sehr unterschiedlich.

Einige Dateien, die rsync überhaupt nicht mehr kopieren konnte, ließen sich mit ddrescue anschließend zu

100.00%

wiederherstellen.

Bei anderen blieben wenige Kilobyte defekt.

Beispielsweise konnten große MP4-Videos bis auf ungefähr 8 KB gerettet werden. Andere Dateien blieben zu 94, 97 oder über 99 Prozent lesbar.

Es gab aber auch Dateien, bei denen

rescued: 0 B
pct rescued: 0.00%

stehen blieb.

Und bei zwei Dateien konnte ddrescue nicht einmal die Quelldatei öffnen:

Can't open input file: Input/output error

Das zeigt eine Grenze der Rettung auf Dateiebene:

Wenn bereits die für das Öffnen einer Datei benötigten Dateisysteminformationen nicht mehr gelesen werden können, kann ein dateibasierter ddrescue-Aufruf nicht helfen.

Für wichtige Daten wäre dann eine sektorweise Rettung des gesamten Datenträgers ein anderer Ansatz gewesen. Für die betreffenden unwichtigen Altdateien wurde darauf verzichtet.

7. Gerettete Dateien prüfen

Ein Wert von 99 Prozent sagt noch nicht, ob eine Datei praktisch verwendbar ist.

Deshalb wurden unterschiedliche Dateitypen anschließend geprüft.

Dateityp erkennen

file /pfad/zur/datei

Bei erfolgreich geretteten Dateien ergaben sich beispielsweise wieder plausible Typen wie:

JPEG image data
PDF document
Microsoft Word 2007+
Composite Document File V2 Document

Das ist allerdings nur ein erster Test.

8. DOCX-Dateien überprüfen

DOCX-Dateien sind intern ZIP-Archive.

Deshalb kann man ihre Struktur testen:

unzip -t dokument.docx

Eine vollständig gerettete Datei lieferte:

No errors detected in compressed data

Bei beschädigten Dateien zeigte unzip dagegen beispielsweise:

invalid compressed data to inflate
bad zipfile offset

Reparaturversuch mit zip -FF

Eine Kopie des beschädigten Dokuments kann als ZIP behandelt werden:

cp dokument.docx dokument_beschaedigt.zip

Dann:

zip -FF dokument_beschaedigt.zip --out dokument_repariert.zip

Anschließend:

unzip -t dokument_repariert.zip

Das kann Teile eines DOCX retten.

Allerdings gibt es einen wichtigen Fallstrick:

Ein anschließend fehlerfreies ZIP bedeutet nicht automatisch ein repariertes Word-Dokument.

Bei einem Test fehlten nach der Reparatur ausgerechnet:

[Content_Types].xml
_rels/.rels
word/_rels/document.xml.rels
word/document.xml

word/document.xml enthält den eigentlichen Dokumenttext.

Der ZIP-Container war danach zwar fehlerfrei, der Dokumentinhalt aber trotzdem verloren.

Eingebettete Bilder konnten dagegen noch extrahiert werden:

mkdir -p gerettete_medien

unzip -j dokument_repariert.zip \
'word/media/*' \
-d gerettete_medien

9. PDFs prüfen

Für PDFs wurde pdfinfo verwendet:

pdfinfo dokument.pdf

Bei teilweise beschädigten Rettungen konnten trotzdem korrekte Metadaten und Seitenzahlen gelesen werden.

Beispielsweise wurden Dateien trotz weniger fehlender Kilobyte noch sauber als fünf- beziehungsweise mehrseitige PDFs erkannt.

Das war ein gutes Indiz dafür, dass zumindest die grundlegende PDF-Struktur erhalten geblieben war.

10. Bilder wirklich decodieren

file kann eine beschädigte Datei weiterhin als JPEG erkennen.

Deshalb reicht

file bild.jpg

nicht immer aus.

Mit ffmpeg lässt sich versuchen, das Bild vollständig zu decodieren:

ffmpeg -v error -i bild.jpg -f null -

Im Test gab es drei unterschiedliche Ergebnisse:

Keine Ausgabe

Das Bild ließ sich vollständig decodieren.

Kleine Warnung

overread 8

Das Bild war sichtbar beschädigt, ließ sich aber noch anzeigen.

Vollständiger Decoderfehler

No JPEG data found in image
Invalid data found when processing input

Diese Datei war praktisch nicht mehr nutzbar.

11. Videos prüfen: ffprobe reicht nicht immer

Die geretteten MP4-Dateien wurden zuerst mit ffprobe geprüft:

ffprobe -v error video.mp4

Bei allen drei Testdateien blieb die Ausgabe leer.

Das bedeutet: Der Container konnte gelesen werden.

Für einen vollständigen Test wurde anschließend das gesamte Video decodiert:

ffmpeg -v error -i video.mp4 -f null -

Bei einem vollständig geretteten Video blieb die Ausgabe wiederum leer.

Bei zwei anderen Videos erschienen einzelne Meldungen wie:

cabac decode of qscale diff failed
error while decoding MB ...

Die Videos ließen sich trotzdem abspielen. Durch die wenigen nicht lesbaren Kilobyte waren lediglich einzelne Bildbereiche beziehungsweise Frames beschädigt.

Damit waren sie für den konkreten Zweck ausreichend gerettet.

12. Gerettete Dateien erst separat behalten

Die ddrescue-Ergebnisse wurden zunächst bewusst in einem eigenen Rettungsordner gespeichert.

Beispiel:

/mnt/NEUE_PLATTE/Rettung/

Erst nach Prüfung wurden brauchbare Dateien an ihre endgültigen Positionen kopiert.

Das verhindert, dass eine möglicherweise schlechtere Rettungsfassung versehentlich eine bereits vorhandene Datei überschreibt.

Auch bei Videos wurden zunächst beide Fassungen behalten:

video.mp4
video_rsync-alt.mp4

Erst nach dem Abspielen und Testen wurde die schlechtere Version gelöscht.

13. Rettungsreste aufräumen

Nach Abschluss der Rettung können die Map-Dateien entfernt werden, sofern definitiv keine weiteren Rettungsversuche geplant sind:

find /mnt/NEUE_PLATTE/Rettung \
-type f -name '*.ddrescue.map' -delete

Temporäre Reparaturarchive können ebenfalls gelöscht werden:

rm dokument_beschaedigt.zip
rm dokument_repariert.zip

Die tatsächlich geretteten Dateien sollten vorher natürlich an ihre endgültigen Speicherorte kopiert worden sein.

14. Defekte Platte aushängen

Wenn alles Wichtige kopiert wurde:

sudo umount /media/user/ALTE_PLATTE

Danach kontrollieren:

lsblk -o NAME,SIZE,MODEL,FSTYPE,LABEL,MOUNTPOINTS /dev/sdX

Wenn bei der Partition kein Mountpoint mehr angezeigt wird, ist sie sauber ausgehängt.

Im beschriebenen Fall wurde die Platte danach nicht neu formatiert, sondern aus dem Rechner ausgebaut.

Die SMART-Werte und die reproduzierbaren I/O-Fehler waren zu eindeutig, um sie noch als Datenträger weiterzuverwenden.

Was ich aus dem Fall mitnehme

Der ursprüngliche Plan war simpel:

Daten herunterkopieren, NTFS löschen, ext4 formatieren.

Die Kopierfehler haben den Ablauf jedoch sinnvoll verändert.

Der entscheidende Workflow war am Ende:

Datenträger eindeutig identifizieren
        ↓
wichtige Daten mit rsync kopieren
        ↓
I/O-Fehler feststellen
        ↓
SMART-Werte prüfen
        ↓
keine Reparatur oder Formatierung mehr
        ↓
problematische Einzeldateien mit ddrescue retten
        ↓
Dateien je nach Format prüfen
        ↓
brauchbare Rettungen einsortieren
        ↓
defekte HDD ausmustern

Besonders hilfreich war die Kombination aus Werkzeugen:

lsblk / findmnt / efibootmgr
        → richtige Platte identifizieren

rsync
        → möglichst viel normal kopieren

smartctl
        → Hardwarezustand einschätzen

ddrescue
        → problematische Einzeldateien gezielt retten

file / unzip / pdfinfo / ffprobe / ffmpeg
        → prüfen, ob die Rettung tatsächlich brauchbar ist

Der vielleicht wichtigste Punkt: Ein SMART-Status PASSED bedeutet nicht automatisch, dass eine Festplatte gesund ist. Wenn gleichzeitig hunderte oder tausende problematische Sektoren und reale I/O-Fehler auftreten, sollte man die einzelnen SMART-Werte und das tatsächliche Verhalten der Platte ernst nehmen.

Und ebenso wichtig: Eine Datei ist nicht automatisch intakt, nur weil sie zu 99 Prozent gerettet wurde oder file noch den richtigen Dateityp erkennt. Erst ein formatgerechter Test zeigt, wie viel wirklich noch verwendbar ist.