The Net Wizard HauptseiteISP SetupNetzwerkeVelotourenSoftwareKryptografieVaria

Retten, was zu retten ist

Wir hatten kürzlich die Situation, dass bei einem Raid 5 gerade zwei Platten ausgefallen sind. Damit ist die Integrität der Daten leider nicht mehr gewährt. Trotzdem wollte ich noch retten, was halt noch zu retten war.
Fsck
Als erstes habe ich dabei den Eintrag für die Partition aus /etc/fstab entfernt und den betroffenen Server neu in den single user mode gestartet. So war schon mal sicher gestellt, dass keine Prozesse mehr auf die beschädigte Partition schreiben. Danach habe ich einen fsck versucht. Da der erste Superblock nicht mehr lesbar war, musste ich mit -b einen alternativen Superblock angeben. Wo dieser zu finden war, habe ich mit mkfs.ext3 -n /dev/sd[a-z][1-9] herausgefunden.
fsck reich nicht
Das Filesystem war leider dermassen zerschossen, dass der fsck hängen blieb. In der Situation kann man nur noch retten, was zu retten ist. Und hier kommt debugfs ins Spiel. Als erstes ruft man debugfs -b <BLOGSIZE> -s <SUPERBLOCK> auf. Dabei erhält man die BLOCKSIZE und den alternativen SUPERBLOCK aus mkfs.ext3[a-z][1-9] (natürlich nur, wenn beim erstellen des Filesystems die defaults verwendet wurden).
debugfs
Debugfs öffnet eine Shell, die einige Befehle zur Verfügung stellt. Unter anderem gibt es ls. Damit erfährt man, was im untersten Verzeichnis der Partition noch lesbar ist. Nun kann man versuchen, die einzelnen Verzeichnisse dort wieder herzustellen. Das geht mit rdump <directory> <destination>. <directory> ist dabei das Verzeichnis, das man retten möchte, <destination>ist der Ort, wohin man es speichern will.
Resultat
Mit debugfs konnte ich ca. 50% der Daten wieder herstellen.

Powered by w3.css