Ext2/3-Dateisysteme im laufenden Betrieb reparieren

Wenn sich eine Datei plötzlich gar nicht mehr ansprechen lässt, ist guter Rat teuer, speziell auf nur per Fernzugriff erreichbaren Root-Servern. Doch auch dieses Abenteuer kann glimpflich ausgehen.

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.

Listing 1

Reparaturen an eingehängten Partitionen sind gefährlich

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.

Leichenfledderei

Fehlt diese oder war das Backup nicht mehr ganz frisch, bewaffnet sich root mit einem Texteditor, um im Verzeichnis /home/lost+found Leichenschau zu betreiben: Dateien oder Teile davon, die fsck nicht zuordnen konnte, finden sich hier wieder – allerdings nicht unter ihren vormaligen Namen. (Findet fsck diese heraus, kopiert es sie in der Regel wieder an den richtigen Ort.) Erinnert man sich an die passenden Dateinamen, lassen sich die “verlorenen und wiedergefundenen” Files händisch umbenennen und an ihren alten Platz zurück schieben.

Manchmal hat man Glück, und lost+found enthält Dateien, die fsck doch reparieren und korrekt platzieren konnte. Daten, die auf kaputten Festplattenstücken lagerten, zaubert aber auch kein Filesystemcheck wieder her.

In jedem Fall heißt es jetzt, wachsam zu sein, Backups anzulegen und zu testen und öfters mal einen Dateisystemcheck außer der Reihe einzulegen. Auf nicht ganz unwichtigen Systemen wird man besser früher als später die Platte tauschen. Denn wenn diese einmal “einen Schuss” hat, lehrt die Erfahrung, dass die Probleme eher zunehmen als ab.

Glossar

Cron-Job: Der Cron-Daemon [1,2] schaut jede Minute in speziell für ihn geschriebenen Auftragstabellen, den Crontabs, nach, ob er im Auftrag eines Users Programme und Skripte zur bestimmten Zeit ausführen soll. Diese Aufträge nennt man Cron-Jobs. So nicht anders verordnet, schickt der Cron-Daemon nach ihrer Ausführung einen “Bericht” per Mail an den auftraggebenden User.
rm -rf: Einer der gefährlichsten Befehle auf einem Unix-System: Er löscht das als Argument angegebene Verzeichnis samt allen Unterverzeichnissen, solange dem aufrufenden User die Dateien gehören oder er entsprechende Schreibberechtigungen hat. Da root alle Dateien löschen darf, kann dieser Befehl bei Unachtsamkeit das ganze System zerstören.
Inodes: Für jede im Linux-Dateisystem abgelegte Datei gibt es eine spezielle Datenstruktur, einen “Informationsknoten”, der zum Beispiel Informationen zum Eigentümer, zur Gruppe und den Zugriffsrechten der Datei enthält, vor allem aber Zeiger auf die Stellen auf der Festplatte, auf denen die Daten der Datei liegen. Mit ihrer Hilfe verwaltet das Betriebssystem den Dateibaum. Auch Inodes müssen gespeichert werden, und zwar auf der Festplatte. Ist die genau dort kaputt, wo ein Inode liegt, kann das Betriebssystem nicht mehr auf die passende Datei zugreifen.
Single-User-Modus: Der in Runlevel 1 definierte Rettungsmodus, in dem es weder grafische Oberfläche, noch Netzwerk, noch die Möglichkeit gibt, sich als unprivilegierter User einzuloggen. root benutzt ihn, um das System direkt von der Konsole aus zu reparieren.