NVME-Festplatte kaputt?

Das Ereignis

Mitte April 2024:

Nach einem Systemupdate fährt mein Laptop plötzlich nicht mehr hoch. Der Bootloader grub-core meldet, er habe Probleme beim Schreiben von Sektoren.

error: ../grub-core/efi/efidisk.c:638: failure writing sector 0xXXXXXXXX

Beim Reboot bleibt mir der Bildschirm nach Anzeige des Firmenlogos mit blinkendem Cursor schwarz. Wenn ich hinter die Maske schaue, dann schlägt das Laden diverser Services fehl:

Boot errors due to read-only nvme

Erste Analyse

Ich vermutete ein Problem beim Update des Rechners und führte aus dem UEFI von Lenovo heraus einen Festplattentest durch. Ergebnis:

The media check is complete, the result is: FAIL

Eher kein Problem mit dem Betriebssystem sondern eines mit der Platte. Mist. Muss ich um meine Daten bangen? Ich habe zwar Backups herumliegen, das letzte ist aber drei Wochen alt und somit sind einige Stunden Arbeit auf der Kippe. Zudem kostet mich ein Wiederaufsetzen einiges an Zeit. Daher probiere ich erst einmal, ob sich noch etwas retten lässt.

Selbsttest

Ich lasse also die SMART Tests für die Platte mit smartctl -x /dev/nvm0 durchlaufen und weiß nun, dass sie etwa 7600 Betriebsstunden hinter sich und 240GB nutzbare Kapazität hat. Die unter dem Namen nvme0n1 eingesetzte Disk meint, sie sei nun “read-only”. Und zwar sämtliche Partitionen inklusive Kernel. Na klasse. Das Ergebnis meiner Online-Suche war in etwa:

Die Platte ist irreparabel beschädigt. Es muss eine Neue her.

Reparaturversuch

Man muss ja nicht alles glauben, was im Netz steht. Also nehme ich das Lenovo-eigene Reparaturwerkzeug für Festplatten zur Hand. Es lässt sich aus dem UEFI heraus aufrufen und firmiert unter dem Namen Bad Block Recovery Tool. Das Programm scannt die Platte auf defekte Sektoren und versucht, betroffene Blöcke wiederherzustellen. Der Durchlauf benötigt für die letzten 10% fast eine halbe Stunde.

Ergebnis: Wiederherstellung fehlgeschlagen. Ich führe das Werkzeug erneut aus. Und noch ein drittes Mal im langsamen pedantic-Modus. Immer wieder ohne Erfolg. Ständig bekomme ich critical medium error angezeigt.

Ob dies alles nicht klappt, weil sich die Platte in den Read-only mode gesetzt hat?

Da ich nicht mehr booten kann und keine Konsole zur Verfügung habe, sind meine Möglichkeiten mit Bordmitteln nun erschöpft.

Einwurf: Der Read-only mode bei SSDs

Laut Internet (DiskTuna) ist der read only mode zur Schadensbegrenzung vorhanden. Stellt der Controller des Speichergerätes einen schwerwiegenden Fehler fest, versetzt er die Platte in Nur-Lesezugriff. Somit wird das Risiko minimiert, dass weitere Blöcke korrumpiert oder mit in den Tod gerissen werden.

Im Forum Superuser beschreibt jemand einen identischen Fehler zu meinem, und tatsächlich ist da wohl nichts mehr zu machen.

Datenrettung per Boot-Stick

Weiter geht’s mit einem USB-Stick, den ich von einem anderen Rechner aus zum Linux-Boot-Stick mache. Ich stopfe ihn an meinen Laptop und kann ihn endlich wieder hochfahren. Als Medium zur Datenrettung schließe ich eine externe Festplatte an.

Übersicht verschaffen mit fdisk

Zuerst schaue ich, ob alle Platten und Partitionen auftauchen. Dafür tippe ich das Kommando sudo fdisk -l in die Konsole.

Glück gehabt, alles ist noch da! Vielleicht kann ich die Dateien ja einfach von der defekten Festplatte herunter kopieren?

Kopieren mit cp

Probieren wir’s aus.

sudo cp -r -v /mnt/nvme0n1p3/Documents/my/important/files /mnt/externalHdd/save

Ein paar Sekunden denke ich, dass alles glatt geht. Doch dann bricht cp mit Fehlermeldung ab, das Volume sei nicht verfügbar. Tatsächlich ist die Platte nicht mehr gemountet. Ich kann sie allerdings direkt wieder finden und mounten. Ein paar Versuche später habe ich meine wirklich wichtigen Daten gesichert, der Kopiervorgang bricht aber stets nach ein paar Sekunden ab. Für die ganze Platte würde mir dieses Vorgehen viel zu lange dauern.

Genau dieses Verhalten - mounten, ein paar Sekunden kopieren, Platte verschwindet - habe ich online in ein paar Foreneinträgen bestätigt bekommen.

Also muss eine andere Lösung her.

Daten retten mit ddrescue

Nach kurzer Online-Suche installiere ich das Programm ddrescue.

In der zugehörigen Dokumentation stehen einige Dinge sehr klar drin. Dass man z.B. verstanden haben sollte was es genau tut, bevor man es verwendet. Oder das Folgende:

“Never try to repair a file system on a drive with I/O errors; you will probably lose even more data. “ - ddrescue Manual

Jetzt stellt sich für mich die Frage, ob ich oben mit dem Block-Reparaturversuch genau so einen Fehler begangen habe. Oder bin ich mit der Bad Block Recovery auf der sicheren Seite, da hier von Datenblöcken auf der Platte und nicht vom “darüber liegenden” Dateisystem die Rede ist? Hier steht auch, dass die sogenannte Mapfile eine Kernfunktion des Programmes ist. Nach Abbruch, Neustart, für die Zusammenführung von Backups und zum Verkürzen der Datenrettung bietet sie einen großen Zeitvorteil. Daher sei es keine schlechte Idee, sich die Mapfile schon bei Erstellung einer Offlinhe-Sicherheitskopie zu erzeugen und gut wegzulegen. Insgesamt fand ich das Tool extrem hilfreich, effektiv und leicht zu bedienen und kann es an dieser Stelle nur weiterempfehlen.

Zurück zur Sache: Ich finde einen ganz einfachen Befehl, die komplette Datenpartition meines beschädigten NVME-Speichers auf eine externe Festplatte zu kopieren:

ddrescue --sparse /dev/nvme0n1p3 /run/media/liveuser/myExternalHDD/datapartition

Die --sparse-Option überspringt mit Nullen belegte Bereiche der Quellplatte und kann so eine Menge Platz auf dem Zieldatenträger einsparen. Das Programm benötigt eine Viertelstunde für den kompletten Durchlauf. Es kann wie oben im Bild zu erkennen tatsächlich 99.6% der Daten retten und auch mehrere Monate später habe ich die restlichen 0.4% noch nicht vermisst. Glück gehabt.

Überprüfung: Output von ddrescue ansehen

Jedenfalls legt das Programm am Ende eine einzige Datei auf meiner externen Platte ab: datapartition.img Dieses Image kann ich mit fdisk -l anschauen:

datapartition.img: 236.89 GiB, 254356226048 bytes, 496789504 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Alles da, das ist ja schon einmal gut. Ob denn nun auch alles drin ist?

Dafür mounte ich die Partition mal und schaue mich per cd und ls -l darin um:

sudo mkdir /mnt/olddisk  # Mount point of the rescued data image
sudo mount /run/media/liveuser/myExternalHDD/datapartition.img /mnt/olddisk

Zum Glück war alles drin, was drin sein sollte. Nun konnte ich das Image unmounten, den Rechner herunterfahren und eine neue Festplatte einbauen lassen.

Die neue Festplatte

Auch hier habe ich noch einmal Glück gehabt: Auf meinem Gebrauchtlaptop war noch Garantie und so bekam ich ihn binnen einer Woche mit einer neuen (und doppelt so großen) Festplatte zurück gesendet. Da ich so große Angst vor Datenklau bekam, hatte ich meine alte Platte vor dem Versenden ausgebaut. Dabei kam ich mir ganz schön paranoid vor.

Diese Arbeit hätte ich mir aber vielleicht sparen können, denn ddrescue hat auch für paranoide Leute wie mich eine Software-Lösung parat: Die Option --fill-mode. Hiermit können nach erfolgter Rettung die “noch guten” Blöcke und Sektoren gelöscht werden. Nur die ohnehin defekten Sektoren bleiben erhalten. Aus der Online-Dokumentation:

ddrescue --fill-mode=+ --force /dev/zero bad_drive mapfile

Ob dies allerdings auch einer Platte wie meiner funktioniert hätte, die der On-Board-Controller auf “read-only” gesetzt hat, ist mir nicht klar. Egal.

Ich kann jetzt jedenfalls mit einem voll funktionsfähigen Laptop weiter Blog-Einträge verfassen ☺️.