Datenrettung in letzter Not

Selbst wer vor ein paar Jahren aus Überzeugung SCSI-Festplatten in seinen Rechnern verbaute, greift heute zu IDE-Datenspeichern: Nicht nur, dass sie sehr viel billiger zu großen Mengen Speicherplatz verhelfen – sie sind auch bedeutend leiser als ihre Krachbrüder aus dem SCSI-Lager. Deren Hersteller gehen offensichtlich davon aus, dass SCSI heutzutage nur noch in Rechner eingebaut wird, die ohnehin in abgeschotteten Server-Räumen stehen.

So bekommt mancher kleine Server eben doch IDE-Platten eingebaut. Doch die sind oft nicht mehr für die Ewigkeit gebaut. Selbst IDE-Festplatten gut beleumundeter Hersteller machen schonmal nach einem reichlichen Jahr durchgängigem Betrieb schlapp.

Der Verfall geht oft schleichend vonstatten: Hier ein kaputter Sektor, da ein weiterer … Wer seine Daten nicht sichert, merkt höchstens durch Zufall, dass plötzlich Dateien "verschwinden". Läuft hingegen ein Backup-Cron-Job, so wird man hoffentlich rechtzeitig gewarnt – sofern man die Bericht-Mails von Cron liest.

Nutzt man rsync [3] für das Backup, sehen solch böse Nachrichten zum Beispiel so aus:

building file list … /home/pjung/artikel/LU0803
: Input/output error
done
IO error encountered - skipping file deletion

Ein Input/Output-Fehler bei den Daten eines Verzeichnisses wie im Beispiel hat weitreichende Konsequenzen: Egal, ob man sich den Verzeichnisinhalt mit ls -al o. ä. anzeigen lassen oder den Ordner selbst mit mv verschieben will, egal, ob man sich mit stat Informationen zum Verzeichnis holen oder ein verzweifeltes rm -rf diesem nach dem Motto "Und bist du nicht willig, so brauch' ich Gewalt" den Garaus machen soll – man bekommt immer wieder denselben Ein-Ausgabefehler.

Löschen und aus dem Backup zurückkopieren geht also nicht. Auch auf die einstmals im Verzeichnis abgelegten Dateien kann man nicht mehr zugreifen, denn ein Verzeichnis ist nichts anderes als eine Datei, die die im Ordner enthaltenen Dateinamen samt zugehörigen Inodes enthält. Fehlen diese Informationen, weil die Festplatte dort kaputt ist, wo das Verzeichnis physikalisch "liegt", weiß das Betriebssystem nicht mehr, wie es an die Dateien herankommt – auch wenn sie noch unversehrt auf dem Datenträger lagern.

Der Patient ist also das Filesystem. Wenn alles gut geht, helfen die "Selbstheilungskräfte" einer Dateisystemüberprüfung zumindest vorübergehend weiter. (Den schleichenden Verfall der Festplatte können sie natürlich nicht stoppen.)

Der Rettungsmodus

Wer seinen Rechner vor sich stehen hat, wird jetzt in den Single-User-Modus booten, indem er oder sie dem hochzufahrenden Kernel am Boot-Prompt die Option single mitgibt. Am Prompt

Give root password to login:

ist das Superuser-Passwort gefragt (Achtung, manche Systeme haben in diesem Zustand eine amerikanische Tastenbelegung). So sich die Administratorin nicht erinnert, findet sie mit cat /etc/fstab heraus, auf welcher Festplattenpartition sich das kaputte Verzeichnis befindet. Diese gibt sie dem von den Filesystemchecks beim Booten bekannten Kommando fsck als Argument mit auf den Weg. Nach der Reparatur darf das System wieder neu und normal gestartet werden.

Doch wenn es sich bei dem betroffenen Rechner um einen Root-Server handelt, der im Server-Raum eines Providers steht, kann man nicht einfach in den Single-User-Modus booten – man sitzt ja nicht direkt vor dem Rechner und hat nur remote per ssh Zugriff. So lange es sich nicht um die unter / und /usr eingehängten Partitionen mit den für den Betrieb lebenswichtigen Programmen handelt, ist jedoch noch nichts verloren (im übrigen ein Argument mehr für ein überlegtes Partitionsschema).

Ohne Konsolenzugriff

Als root per ssh eingeloggt, listet der Befehl mount ohne weitere Argumente auf, welche Festplattenpartition an welcher Stelle des Dateisystems eingehängt ist. So liegen die Daten der im Beispiel betroffenen /home-Partition auf /dev/hda6:

/dev/hda6 on /home type ext3 (rw)

Wenn root jetzt allerdings fsck auf diese Partition anwendet, gibt es eine ernsthafte Warnung: Reparaturen an gemounteten Dateisystemen sind äußerst gefährlich (Listing 1). Da zieht man sich besser mit einem [n][Enter] wieder zurück.

linux:/home/pjung # fsck /dev/hda6
fsck 1.28 (31-Aug-2002)
e2fsck 1.28 (31-Aug-2002)
/dev/hda6 is mounted.
WARNING!!!  Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.
Do you really want to continue (y/n)?  no
check aborted.

Doch einfach aushängen geht auch nicht; schließlich greifen alle noch eingeloggten, nichtprivilegierten User derweil auf ihr Home-Verzeichnis zu. Arbeiten tatsächlich weitere Benutzer auf dem Rechner, schickt ihnen root mit dem Befehl wall eine Nachricht auf den Bildschirm (Abbildung 1):

echo -e "Bitte alle sofort ausloggen! \nWir haben Probleme mit dem Dateisystem" | wall

Abbildung 1: Für die wall-Meldung öffnet KDE ein eigenes Fenster

Wer diesem freundlichen Hinweis nicht Folge leistet, wird rabiat rausgeschmissen: Gibt die Administratorin von ihrem sicheren Platz im eigenen Home-Verzeichnis unter /root den Befehl

fuser -mk /dev/hda6

ein, sorgt die Option -k (kill) dafür, dass alle Prozesse sterben, die auf Dateien der derzeit noch gemounteten (-m) Partition /dev/hda6 zugreifen. (Wichtig hierbei: Sollte sich root über den su-Befehl von einem nichtprivilegierten Konto aus Admin-Rechte erworben haben, kickt sie sich damit natürlich selbst raus, denn der Elternprozess von su greift auf das Home-Verzeichnis des nichtprivilegierten Users zu.)

Anschließend heißt es, die betroffene Partition mit umount /dev/hda6 aus dem Dateibaum auszuhängen, und beim fsck /dev/hda6 das Beste zu hoffen. Ergeben nickt die gemeine Sysadmine dabei alle Korrekturvorschläge des Programms mit [y] ab – sie hat ohnehin keine Wahl. Ist das Dateisystem wieder heil, hängt sie es mit mount /home wieder ein und begutachtet den Ort der Verwüstung. Wer Glück hat, findet, dass fsck das kaputte Verzeichnis wiederherstellen konnte. Ansonsten bleibt nur, dessen Backup-Version an Ort und Stelle zu spielen.