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:
- Datenträger eindeutig identifizieren
- sicherstellen, dass keine Boot- oder Systempartition gelöscht wird
- lesbare Daten mit
rsync kopieren
- den Gesundheitszustand mit SMART prüfen
- beschädigte Einzeldateien mit GNU
ddrescue retten
- gerettete Dateien überprüfen
- 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:
- Linux lag auf einer NVMe-SSD.
- Die aktive EFI-Partition lag ebenfalls dort.
- Eine zusätzliche NTFS-Partition namens
System-reserviert gehörte zum früheren Windows-System und wurde vom aktuellen Linux nicht verwendet.
- Die zu rettende alte Backupplatte war ein anderer Datenträger.
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
- wiederholten echten I/O-Lesefehlern,
- bereits umverteilten Sektoren,
- sehr vielen noch ausstehenden problematischen Sektoren,
- nicht korrigierbaren Sektoren
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.