Autor Thema: Systemrettung, wenn die Platte streikt  (Gelesen 1076 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline Bitpicker

  • /dev/gamemaster
  • Famous Hero
  • ******
  • Beiträge: 3.506
  • Geschlecht: Männlich
  • Username: bitpicker
    • Nyboria - the dark side of role-playing
Systemrettung, wenn die Platte streikt
« am: 30.03.2008 | 01:49 »
Datenverlust ist etwas, das man möglichst vermeiden will. Aber für die meisten kommt irgendwann die Situation, dass das System endgültig streikt. Für diesen Ernstfall kann man nur sehr schlecht proben; und weil es mir heute passiert ist, schreibe ich hier eine kurze Zusammenfassung, was ich wie getan habe, um mein System wieder zum Laufen zu bringen. Vielleicht hilft das ja mal jemandem.

Situation Samstag Morgen: der Rechner fuhr nicht mehr hoch, die Root-Partition /dev/hdb3 war nicht mehr zu mounten. Der Rechner ging in eine Endlosschleife.

Von einer Live CD (Insert Security) konnte gebootet werden, aber die Partition war nicht einzuhängen. Der Einhängevorgang ging einfach nicht weiter.

Die Partition war mit Reiserfs formatiert.
reiserfsck --check /dev hdb3

brachte nichts, da auch dies in eine Endlosschleife ging. Die Befehle dmesg und tail -f /var/log/messages brachten schließlich folgendes an den Tag:

ReiserFS: hdb3: Removing [9641227 9641615 0x0 SD]..hdb: dma_intr: status=0x51 { DriveReady SeekComplete Error }
hdb: dma_intr: error=0x40 { UncorrectableError }, LBAsect=39292892, sector=39292888
ide: failed opcode was: unknown
end_request: I/O error, dev hdb, sector 39292888
ReiserFS: hdb3: warning: vs-5657: reiserfs_do_truncate: i/o failure occurred trying to truncate [9641227 9641615 0xfffffffffffffff DIRECT]
done

Ich habe nach Stichworten wie reiserfs_do_truncate gegooglet und so herausgefunden, dass an einem Neuaufbau des Dateisystems wohl kein Weg vorbeiführte, also:

reiserfsck --rebuild-tree /dev/hdb3

Leider führte auch das nicht zum Ziel, sondern lediglich zu der Meldung, dass die Festplatte physikalisch defekt sei. Also musste ich erst mal eine neue Platte kaufen. Ich hatte zwar ein Backup von Donnerstag, aber das war ja nun schon ein bisschen veraltet; lieber wollte ich den aktuellen Stand haben. Also habe ich die neue Platte erst mal partitioniert. Von der alten habe ich /dev/hdb1 (/boot) und /dev/hdb3 per partimage auf eine externe USB-Platte sichern wollen; das klappte perfekt mit /boot, aber gar nicht mit der kaputten / - Partition.

Die Kopie von /boot wurde mit partimage auf die erste Partition der neuen Platte zurückgesichert. Die Daten der / - Partition wurden bitweise in die zweite Partition der neuen Platte kopiert:

dd_rescue /dev/hdb3 /dev/hda2

In diesem Setup war die alte Platte Slave, die neue Master. Nach dem Kopieren der Daten wurden die Platten wieder vertauscht, so dass die zwischenzeitlich ausgebaute Master-Platte wieder am Start war und die neue Platte als Slave nun die Partitionen /dev/hdb1 und /dev/hdb2 hatte.

Jetzt musste noch die grub.conf darauf angepasst werden, dass die Root-Partition nun /dev/hdb2 war, gleiches galt für die fstab, in der hdb2 und hdb3 vertauscht werden mussten (hdb2 war vorher Swap, jetzt hdb3).

Anschließend konnte das System wieder booten und läuft soweit fehlerfrei. Allerdings hat dd_rescue beim Kopieren einige unlesbare Sektoren gemeldet, Fragmente von vier Dateien sind in /lost+found gelandet. Zwei davon gehören zu Mozilla (also Firefox oder Thunderbird, genaueres weiß ich noch nicht), eine ist 0 Byte lang, eine ist mit Nullen gefüllt. Näheres muss ich noch ergründen. Auf mein Backup musste ich aber bisher nicht zurückgreifen...

Robin
Wie heißt das Zauberwort? -- sudo

(Avatar von brunocb, http://tux.crystalxp.net/)