Hallo SpoG,
dein neuer Zwischenstand ist sehr wichtig, denn jetzt sieht man ziemlich klar: Wiederholtes Starten von ddrescue bringt in exakt derselben Form vermutlich nichts mehr.
Die entscheidende Meldung ist:
ddrescue: /dev/nvme0n1: Unaligned read error. Is sector size correct?
Das ist keine Frage, auf die du im Terminal antworten sollst. ddrescue ist an dieser Stelle bereits beendet. Die Meldung bedeutet sinngemäß:
„Ich habe einen Lesezugriff versucht, der zur verwendeten Sektorgröße bzw. zum direkten Gerätezugriff nicht passt.“
Besonders wichtig:
Die Option -d benutzt direkten Plattenzugriff. Dafür muss die Sektorgröße korrekt sein, sonst kann genau dieser „Unaligned read error“ auftreten.
Daher jetzt bitte nicht einfach immer wieder denselben Befehl starten.
-
Zuerst Sektorgröße der NVMe prüfen
Bitte im Live-Linux ausführen:
sudo blockdev --getss /dev/nvme0n1
sudo blockdev --getpbsz /dev/nvme0n1
cat /sys/block/nvme0n1/queue/logical_block_size
cat /sys/block/nvme0n1/queue/physical_block_size
Wahrscheinlich kommt entweder:
512
4096
oder:
4096
4096
Wenn dort 4096 auftaucht, ist das der erste starke Hinweis, dass ddrescue mit expliziter Sektorgröße gestartet werden sollte.
-
Logdateien sichern
Vor weiteren Versuchen:
cp /media/mint/MyPassport_3TB/rescue.log /media/mint/MyPassport_3TB/rescue.log.sicherung1
cp /media/mint/MyPassport_3TB/rescue.log.bak /media/mint/MyPassport_3TB/rescue.log.bak.sicherung1
Die Logdatei ist extrem wertvoll. Ohne sie beginnt ddrescue wieder blind von vorn.
-
Nächster sinnvoller ddrescue-Versuch
Wenn die Sektorgröße 4096 ist, dann:
sudo ddrescue -f -n -b4096 /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
Wichtig:
Hier lasse ich -d erst einmal bewusst weg.
Warum?
Weil -d direkten Zugriff erzwingt und bei falscher oder problematischer Sektorbehandlung genau solche Alignment-Fehler auslösen kann.
Wenn dieser Befehl weiterläuft:
laufen lassen.
-
Falls es ohne -d weiter abbricht
Dann mit direktem Zugriff, aber expliziter Sektorgröße:
sudo ddrescue -d -f -n -b4096 /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
Das ist im Moment vermutlich der wichtigste Test.
-
Falls ddrescue wieder exakt dort stoppt
Dann gezielt über den defekten Bereich springen.
Deine Logdatei zeigt problematische Bereiche um:
0xE4A000000
0xE4A9E0000
Das sind nur kleine Bereiche. Der große Rest der SSD ist noch „non-tried“, also noch gar nicht versucht worden.
Darum wäre der nächste sinnvolle Schritt:
sudo ddrescue -f -n -b4096 -i 62G /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
Falls das läuft, war der Hänger tatsächlich nur in diesem Bereich.
Danach kann man später die Lücke separat bearbeiten.
-
Noch besser: von hinten lesen
Wenn vorne ein Bereich Probleme macht, kann ddrescue auch rückwärts lesen:
sudo ddrescue -f -n -b4096 -R /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
Das ist bei solchen Fällen oft sehr sinnvoll, weil die SSD vielleicht nur an einer bestimmten Stelle stolpert, aber der Rest noch lesbar ist.
-
Erst danach kleine Fehlerbereiche angehen
Wenn möglichst viel kopiert ist, dann erst:
sudo ddrescue -f -b4096 -r3 /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
-r3 bedeutet:
problematische Bereiche maximal dreimal erneut versuchen.
Nicht gleich mit hohen Retry-Zahlen arbeiten. Das stresst die SSD unnötig.
-
Bewertung deiner aktuellen Logdatei
Die Logdatei ist gar nicht hoffnungslos.
Sie zeigt:
0x00000000 0xE4A000000 +
Das bedeutet:
Der Anfang bis ungefähr 61 GB wurde erfolgreich gelesen.
Dann:
0xE4A000000 0x00010000 *
Das ist ein problematischer Bereich von nur 64 KB.
Dann:
0xE4A010000 0x009D0000 ?
Das ist noch nicht endgültig verloren, sondern nur noch nicht sauber bearbeitet.
Und danach ist fast der komplette Rest weiterhin:
?
Also:
nicht kaputt, sondern noch nicht gelesen.
Das ist wichtig.
Die 61 GB sind nicht „alles, was rettbar ist“. Es ist nur der Bereich, bis zu dem ddrescue bisher gekommen ist.
-
Mein konkreter Vorschlag in Reihenfolge
Ich würde jetzt genau so vorgehen:
-
Sektorgrößen prüfen
sudo blockdev --getss /dev/nvme0n1
sudo blockdev --getpbsz /dev/nvme0n1
-
Logdateien sichern
cp /media/mint/MyPassport_3TB/rescue.log /media/mint/MyPassport_3TB/rescue.log.sicherung1
-
Ohne direkten Zugriff, aber mit 4096 versuchen
sudo ddrescue -f -n -b4096 /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
-
Falls Abbruch: rückwärts versuchen
sudo ddrescue -f -n -b4096 -R /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
-
Falls nötig: hinter der Problemstelle starten
sudo ddrescue -f -n -b4096 -i 62G /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
-
Erst ganz zum Schluss Retry-Läufe:
sudo ddrescue -f -b4096 -r3 /dev/nvme0n1 /media/mint/MyPassport_3TB/rescue.img /media/mint/MyPassport_3TB/rescue.log
-
Wichtig zur externen HDD
Diesmal ist es gut, dass dort jetzt steht:
rescue.img
rescue.log
rescue.log.bak
Das ist der richtige Zustand.
Nicht mehr direkt nach /dev/sdb schreiben.
Also NICHT:
/dev/sdb
sondern immer:
/media/mint/MyPassport_3TB/rescue.img
Das ist jetzt deutlich sicherer.
-
Noch nicht mit TestDisk anfangen
Auch wenn es verlockend ist:
Noch nicht TestDisk, ntfsfix oder chkdsk verwenden.
Erst muss möglichst viel Rohmaterial ins Image.
Mit nur 61 GB von ca. 1 TB ist das Image noch zu unvollständig.
-
Meine Einschätzung
Nein, stumpfes Wiederholen desselben ddrescue-Befehls ergibt im Moment keinen Sinn.
Aber:
Der Fall ist keineswegs verloren.
Im Gegenteil:
Die Logdatei zeigt eher, dass ddrescue an einem kleinen Bereich hängen bleibt und danach noch riesige Bereiche gar nicht versucht wurden.
Der richtige nächste Schritt ist daher:
-
Sektorgröße prüfen
-
ddrescue mit -b4096 versuchen
-
gegebenenfalls rückwärts lesen
-
gegebenenfalls hinter der Problemstelle fortsetzen
Das Ziel ist jetzt nicht, diese eine defekte Stelle sofort zu knacken.
Das Ziel ist:
erst einmal die restlichen rund 900 GB zu retten.
Die kleine Problemstelle kann man später immer noch bearbeiten.
