Seit gut drei Wochen haben wir von einem Kunden einen PC in der Werkstatt um die Daten von einer defekten Festplatte zu retten. Der Computer lief bis zu seinem Ausfall mit Linux Mint 17 Qiana, zumindest wurde er vom vorangegangenen IT-Dienstleister damit installiert laut Unterlagen.
Was aktuell darauf läuft oder welchen Stand das System hat, konnte unser Kunde mangels Kenntnis nicht beantworten. Nach Auswertung der S.M.A.R.T.-Daten der Festplatte war klar, das der Computer ab Kauf gut drei Jahre am Stück durchgelaufen ist, dies wurde vom Kunden so auch bestätigt. Nein, es handelt sich nicht um einen Server, es wird lediglich ein wenig Internet und E-Mail gemacht. Es ging vermutlich nur um reine Bequemlichkeit, also nicht warten müssen, bis das System gebootet hat. Nun, die recht ordentliche Hardware läuft trotz klassischer Festplatte recht schnell. Genug der Vorgeschichte.
Round 1: Mit ddrescue die defekte Festplatte klonen
Mit Blick auf die S.M.A.R.T.-Werte war zwar klar, das die Festplatte defekte Sektoren hat, allerdings war die Anzahl gering und nachdem von Boot-CD (PartedMagic) ohne größere Schwierigkeiten die Partitionen gemountet werden konnte, war die Hoffnung zunächst groß, das man durch einfaches Klonen relativ schnell wieder ein lauffähiges System bekommt.
Zum grundsätzlichen Vorgehen siehe dazu Wikipedia – ddrescue.
Die Hälfte der 500GB Festplatte lies sich ohne größere Schwierigkeiten klonen, danach ging es los, die Performance brach ein und die Fehleranzahl stieg. Nach über einer Woche brachen wir den Versuch dann ab, da sich in Sachen Performance fast nichts mehr bewegte. Das bis hierhin geklonte System war trotz Reparaturversuch weder mount- geschweige denn bootbar. Essig.
Round 2: Mit testdisk die Daten von der defekten Festplatte kopieren
Der PC wurde mit einer neuen Festplatte und aktuellem Linux Mint neu installiert. Soweit hatte man dann schonmal ein grundsätzlich lauffähiges System. Als nächstes wurde testdisk (siehe Round 3) installiert, die defekte Festplatte über einen USB-SATA-Adapter verbunden und dann versucht direkt von dieser die Daten zu kopieren.
Leider ging dies ebenfalls schief, während testdisk auf der Suche nach Partitionen war, stieg die Festplatte aus bzw. aufgrund der Timeouts beim Versuch etwas zu lesen, hängte sich testdisk auf. Essig, Teil 2.
Rückblickend kann man vermuten, das es an diesem Punkt möglicherweise wegen des USB-SATA-Adapter gescheitert ist.
Round 3: Mit ddrescue Image erstellen und dann per testdisk aus dem Image die Daten kopieren
Da es beim ersten Versuch mit ddrescue zumindest bis zur Hälfte recht schnell und gut ging wurde kurzerhand die Festplatte wieder per SATA verbunden, ein Image von der defekten Festplatte bis zur Hälfte erstellt bzw. zu den ersten Fehlern erstellt, dann wurde mit Strg+c abgebrochen.
sudo ddrescue /dev/sdX AlteHDD01.img AlteHDD01.log
Oder etwas besser:
sudo ddrescue -d -f -n /dev/sdX AlteHDD01.img AlteHDD01.log
Auf das Image wurde dann testdisk angesetzt:
sudo testdisk AlteHDD01.img
Ab hier dann das übliche Vorgehen bei testdisk (Stickpunkte):
- Log
- Gerät/Image auswählen
- Partitionstyp [Intel] auswählen
- Analyse
- Quick Search
- gefundene Partition auswählen bzw. ggf. Deeper Search
- „P“ für „List files“ drücken
- Auswählen und Kopieren
Siehe auch: TestDisk Step By Step
Leider hat es mit dem Image dann doch nicht geklappt, es wurde nichts darin gefunden, daher eine Rolle rückwärts zu „Round 2“, aber diesmal testdisk etwas anders aufgerufen:
- testdisk starten
- Log erstellen (oder auch nicht, wie belieben)
- Festplatte/Partition/Image auswählen, in diesem Fall war es „/dev/dm-0“
- Partitionstyp „[None] Non partioned media“ auswählen
- „Analyse“ auswählen
- Es wird „P ext4“ angezeigt, „Quick Search“ auswählen
- Bei der gefundenen „ext4“-Partition „P“ für List files“ drücken
In diesem Fall dann warten, wegen der fehlerhaften Sektoren
- „home“ durch drücken von „:“ auswählen
- Alternativ in „home“ wechseln, „h“ für „hide deleted files“ auswählen und erstmal die relevanten Daten auswählen
- „C“ drücken und Ziel-Ordner auswählen
- „C“ drücken, wenn das Ziel richtig ausgewählt wurde
- es wird kopiert, also warten (Geduld ist eine Tugend)
Beim ersten Versuch das gesamte „home“-Verzeichnis zu kopieren, wurde die Ziel-Festplatte zugemüllt. Es tauchten riesige *.swf- oder auch *.sqlite-Dateien auf, die es auf der defekten Festplatte eigentlich nicht gibt. Vermutlich handelt es sich im Kopierfehler aufgrund der Defekte. Gezwungenermaßen wurden dann einzeln die relevanten Ordner kopiert und dabei immer der freie Speicherplatz im Auge behalten. Sobald es Ausreißer gab, wurde geschaut, ob wieder die zuvor genannten „ominösen“ Dateien auftauchten.
Das hat dann soweit geklappt und soweit man es beurteilen kann, sind zumindest einige Nutzdaten vorhanden.
Randnotizen
Damit Linux Mint nicht immer wieder versucht, die Partitionen von der defekten Festplatte automatisch einzuhängen, kann man dies unter „Zubehör – Laufwerke – <Festplatte> – Zusätzliche Partitionierungseinstellungen – Einhängeoptionen bearbeiten“ deaktivieren.
Da der Compuer mit angeschlossener defekter Festplatte (auch wenn er von dieser nicht starten soll) nicht bootete, wurde diese SATA-seitig abgezogen, im BIOS für den betreffenden Port „hot-plug“ aktiviert und erst nachdem das frisch installierte Linux Mint gestartet war verbunden. Erst dann ging es mit „Round 2 jenseits von Round 3“ weiter.
Da testdisk mit sudo bzw. root-Rechten läuft, müssen die Rechte, der Inhaber und die Gruppe der geretteten Dateien korrigiert werden:
sudo chown -R <Benutzername> <Verzeichnis>
sudo chgrp -R <Benutzername> >Verzeichnis>
sudo chmod -R 0755 <Verzeichnis>
