Ich schreibe hier diesen kleinen Beitrag, weil bei mir doch tatsächlich eine SSD kaputt gegangen ist.
Die Lösung zur Rettung der Daten gibts weiter unten, die Vorgeschichte ist für das Verständnis durchaus interessant.
In Foren findet man oft die Aussage, dass das Netzteil defekt ist und man soll es tauschen.
Dass dies mal wieder Banane ist, zeigt dieser Beitrag 🙂
Das Problem:
Ich habe ein Raspberry Pi 3, nicht den 3 B+ sondern nur den 3er.
Dieser hat eine USB-SSD angeschlossen, da er im 24/7 Betrieb läuft und das ein oder andere mal was schreiben muss.
SD-Karten wären hierfür die extrem schlechte Wahl gewesen.
Der Pi an sich läuft auch ohne Probleme.
Keine Meldung über Spannungsschwankungen oder Strom-Probleme.
Keine Meldungen über kaputte Treiber oder sonst ein Hinweis.
Doch je nach Lust und Laune hängt sich das Teil auf.
Nur ein Neustart hilft hier.
Die Ursachen-Forschung:
Mir ist aufgefallen, dass der Pi per Ping immer noch erreichbar war.
Nur per SSH konnte keine Verbindung mehr aufgebaut werden und bereitgestellte Webseiten, welche auf dem Pi laufen, wurden gar nicht mehr geladen oder nur statische Inhalte.
Zuerst hatte ich ein paar Programme in Verdacht.
Also diese mal vorübergehend beendet, aber das hat nichts geholfen.
Okay also mal das übliche geprüft.
Stromversorgung getauscht – hat nichts geholfen.
Die Festplatte mit einem zweiten Linux-System geprüft (fsck) – keine Fehler gefunden.
SMART-Werte ausgelesen – Sieht gut aus.
Oookay kann dann es nur das System sein.
Also das mal neu installiert.
Und siehe da, der Pi läuft 3 Wochen gut durch und daaaaannnn … wieder aufgehängt.
Dann kam mir ein Gedanke wieder hoch.
Per USB angebundene Festplatten haben teilweise Probleme die SMART-Werte korrekt auszulesen, weil der USB-SATA-Adapter nicht alles korrekt weiterleitet.
Wenn die Platte einen Schuss hat, muss ich den Absturz ja manuell auslösen können.
Also setzte ich die dümmste Idee die mir einfallen konnte in die Tat um.
Die SSD zumüllen mit Daten.
Also habe ich einfach aus Spaß diverse Versionen von „Linux Mint“ ISO-Dateien heruntergeladen.
So muss ich ja irgendwann ggf. ein defekten Sektor treffen und das System sollte abschmieren.
Dumme Ideen funktionieren einfach immer.
Tatsächlich konnte ich beim Downloaden das System abschließen.
Und das war reproduzierbar.
Ich habe dabei auch in einer zweiten SSH-Sitzung mal dmesg mit laufen lassen (dmesg -w), um hier eventuelle Fehler direkt zu sehen.
Tatsächlich konnte ich von 10 Versuchen 2 oder 3 mal sehen, dass der USB-Treiber zurückgesetzt wurde.
Danach war die Festplatte in einem Read-Only-Modus.
Bingo!
Doch ein wichtiger Hinweis: Zu diesem Zeitpunkt wusste ich noch nichts von meinem Glück, dass die defekten Sektoren bisher nie beschrieben wurden.
Das bedeutet, dass ich kein Datenverlust habe.
Sind bei dir in den defekten Sektoren mal Daten geladen und der Defekt einer Datei wurde vom System nicht erkannt und repariert, hast du eventuell doch Datenverlust!
Der Gesundheitstest / Rettungsversuch 1:
Ich habe die SSD also mal an mein Notebook – auch eben per USB – angeschlossen und den Versuch gestartet, ein Backup der Platte mit Win32Disk Imager anzulegen.
Der ist bis 98% auch durchgelaufen. War ja klar das er nicht schon bei 20% aufhört und mir 15min Wartezeit erspart hätte.
Nun war also klar, die Platte hat ein Schuss weg.
Das Problem des Rettungsversuchs:
Ein Image der Platte anzulegen war etwas komplizierter als gedacht.
Denn die Tools lesen immer die gesamte Platte aus und schreiben das in der Regel auch weg.
Dadurch stolpern sie über die defekten Sektoren, wodurch der Sicherungsprozess abgebrochen wird.
Also musste ich irgendwas basteln, um nur die Sektoren mit wirklichen Daten auslesen zu können und den Rest zu vernachlässigen.
Dadurch kann die Software (hoffentlich) die defekten Sektoren umgehen.
Der Rettungsversuch (2):
Ab hier beginnt eine mögliche Methode die Daten der Platte zu Retten.
Benötigt wird:
– Die defekte SSD
– Eine Spender-SSD
– Ein temporärer Speicherplatz für die Daten der defekten SSD
– Ein Linux-System (Weil Windoof kein ext4 kann)
– Den Raspberry Pi Imager (oder ein Flash-Tool + ein aktuelles Raspberry OS Image)
– Ein paar Grundkentnisse zu Linux (Festplatte einhängen, nano-Editor, Terminal-Befehle für einfach navigation, …)
1. Installiere das Tool fsarchiver
# apt install fsarchiver
2. Stecke die defekte SSD am Linux-System an
3. Finde heraus, mit welchem Laufwerksnamen die SSD in das Linux-System eingehängt wurde und hänge sie wieder aus
# df
Sollte z.B. /dev/sdc1 + /dev/sdc2 sein.
Also sdc ist die Platte, sdc1 ist die Boot-Partition und sdc2 die ext4-Partition mit den Daten.
Die SSD darf nicht im System eingehängt sein! Ansonsten kann kein Image erzeugt werden.
4. Lese beide Partitionen getrennt nun mit fsarchiver aus und speichere die Daten auf dem Linux-System mit dem temporären Speicherplatz ab
# sudo fsarchiver savefs /pfad/zum/temporären/speicherplatz/imagename-1.fsa /dev/sdc1 # sudo fsarchiver savefs /pfad/zum/temporären/speicherplatz/imagename-2.fsa /dev/sdc2
Passe hierbei den Pfad an, wo die Daten gespeichert werden müssen und den Pfad zur Partition. Mein Beispiel nutzt sdc1 udn sdc2.
Das Ergebnis für eine erfolgreiche Sicherung könnte so aussehen:
Statistics for filesystem 0 * files successfully processed:....regfiles=117910, directories=12377, symlinks=8398, hardlinks=369, specials=11 * files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
Warum beide Partitionen getrennt?
Weil die ganze Platte durch die zwei unterschiedlichen Formatierungen nicht ausgelesen werden kann. (Ich habs immerhin nicht geschafft)
Was macht der Befehl?
Er liest die Partition aus und schreib die Daten in den angegeben Pfad.
Zusätzlich lesen wir nur die Bereiche mit den Daten aus, leere Sektoren werden nicht beachtet.
Das Image ist dann am Ende nur so groß, wie die tatsächliche Auslastung der Plattenkapazität.
Haben wir also 30GB benutzt, ist das Image am Ende auch etwa 30GB groß und nicht z.B. 256GB.
5. Ist der Sicherungsprozess durch, flashe auf deine Spender-SSD das Raspberry Pi OS ganz normal drauf.
Warum?
Dadurch wird die Boot-Partition sauber angelegt.
Ist diese Partition frisch angelegt, kann ein defekt der Boot-Partiton ausgeschlossen werden.
Da keine Nutzdaten vorhanden sind, sondern einfach nur Start-Parameter, müssen wir davon auch nichts retten.
6. Vergrößere nach dem Flash-Vorgang die Partiton „rootfs“ auf der SSD.
Tools wie gparted helfen dabei.
Warum?
Nach dem Flashvorgang über z.B. den „Raspberry Pi Imager“ ist die Partition nur so groß, dass gerade so das Raspberry Pi OS drauf passt.
Unser Image können wir da nicht rein quetschen.
Deswegen müssen wir den gesamten Speicherplatz wieder zur Verfügung stellen.
Das macht der Pi im Normallfall zwar alleine beim ersten Boot, das Prozedere haben wir aber jetzt nicht, weswegen wir es von Hand machen müssen.
7. Ist die Partition groß genug, können wir mit folgendem Befehl unsere Daten wiederherstellen lassen
# sudo fsarchiver restfs /pfad/zum/temporären/speicherplatz/imagename-2.fsa id=0,dest=/dev/sdc2
Die Ausgabe sollte dann in etwa so aussehen:
Statistics for filesystem 0 * files successfully processed:....regfiles=117910, directories=12377, symlinks=8398, hardlinks=369, specials=11 * files with errors:...............regfiles=0, directories=0, symlinks=0, hardlinks=0, specials=0
8. Sind die Daten auf die Platte geschrieben, müssen wir fstab noch anpassen, da unsere neue Spender-SSD eine andere ID hat.
Hänge also die Platte wieder in das System ein.
Suche daher die ID der neuen Platte heraus:
# ls /dev/disk/by-partuuid/
Du solltest die Platte erkennen können. Als Hinweis sollte der sdXX-Name stehen.
Also z.B. „XXXXX → /dev/sdc1“ und „XXXXX → /dev/sdc2“
ls -l /dev/disk/by-partuuid/ insgesamt 0 lrwxrwxrwx 1 root root 10 Jan 4 10:50 24e89975-5251-4343-bde5-7e65b64e5faf -> ../../sda4 lrwxrwxrwx 1 root root 10 Jan 4 10:50 2d377fab-0520-415a-a9ff-59c99437c734 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jan 4 10:50 32f0f1b7-ebe5-4188-a856-5d21af95464d -> ../../sda3 lrwxrwxrwx 1 root root 10 Jan 4 10:50 3b312fa9-bd25-40f8-9bcc-c725c5503099 -> ../../sdb2 lrwxrwxrwx 1 root root 10 Jan 4 10:50 6bf9c3eb-95c1-49b8-b283-95ddea18409a -> ../../sda5 lrwxrwxrwx 1 root root 10 Jan 4 10:50 7f1630f3-bdc8-4a53-83fa-25d3190afc8e -> ../../sda2 lrwxrwxrwx 1 root root 10 Jan 4 10:50 7ff367fd-0f4e-4f76-948d-a4b5dd9d0ccd -> ../../sdb3 lrwxrwxrwx 1 root root 10 Jan 4 11:55 8a438930-01 -> ../../sdc1 lrwxrwxrwx 1 root root 10 Jan 4 11:55 8a438930-02 -> ../../sdc2 lrwxrwxrwx 1 root root 10 Jan 4 10:50 a8586eb5-ce94-40d4-b888-49202f0e3ec1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 Jan 4 10:50 c4be3f2c-6f42-491c-8781-6599871bac2f -> ../../sdb4
9. Ersetze die alte ID mit der neuen in der fstab-Datei
# nano /mnt/USB-SSD/rootfs/etc/fstab
10. Schließe die Festplatte nun wieder am Raspberry Pi an und starte ihn
Der Startvorgang kann ein paar Sekunden dauern, aber er sollte wieder auf die Füße kommen und den Betrieb wieder aufnehmen.
Da wir die gesamte rootfs-Partition wiederhergestellt haben, sollten alle Programme und Dienste wieder starten.
Jayyy Daten gerettet und Wertvolle Zeit für den Neuaufbau erspart 🙂
Hinweis: Der Pi hat jetzt einen neuen SSH-Fingerabdruck! Wenn du also von anderen Systemen per SSH auf den Pi zugreifen solltest, wird dir eine Warnung präsentiert!
Zum Schluss gibts natürlich den Satz des Tages: Kein Backup, kein Mitleid.
Doch ich hatte in Backup der Daten, ich wollte aber die SSD retten. 😉