Dateisysteme prüfen und reparieren: fsck, xfs_repair und btrfs check auf einem ausgehängten Dateisystem

Ziel

Ein Linux-Dateisystem auf Beschädigungen prüfen und nur dann reparieren, wenn Werkzeug und Modus zum Zustand des jeweiligen Dateisystems passen.

Voraussetzungen

Das Ziel-Dateisystem ist ausgehängt (beim Root-Dateisystem zuvor in den Rescue- bzw. Emergency-Modus booten oder ein Live-/Rescue-System verwenden); Root-Zugriff; aktuelle Backups, falls die Reparatur voraussichtlich destruktiv ist.

Schritte

1. Vor der Prüfung sicherstellen, dass das Dateisystem ausgehängt ist. Laut Handbuch von e2fsck darf das Programm nicht auf eingehängten Dateisystemen laufen; selbst wenn -n dies technisch unbedenklich macht, sind die Ergebnisse, die bei eingehängtem Dateisystem ausgegeben werden, nicht gültig. Das generische fsck ruft als Frontend den dateisystemspezifischen Checker auf (fsck.ext4 usw.).
2. Für ext2/3/4: zuerst e2fsck -fn /dev/<device> ausführen (erzwungene vollständige Prüfung, keine Änderungen). Danach e2fsck -f /dev/<device> für eine interaktive Reparatur oder -y, um alle Rückfragen nicht interaktiv mit „yes“ zu beantworten – dies akzeptiert auch destruktive Korrekturen.
3. Für XFS: Das generische fsck ruft fsck.xfs auf, das normalerweise lediglich mit 0 endet; stattdessen xfs_repair verwenden, das ein eingehängtes Dateisystem ablehnt. Zuerst xfs_repair -n /dev/<device> ausführen – der „No-Modify-Modus“: Er meldet, was repariert würde, ohne etwas zu ändern, und liefert 1, wenn Beschädigungen erkannt wurden, sonst 0. Ohne -n liefert das Programm 0, wenn es vollständig durchläuft, 1 bei einem Laufzeitfehler (erneut ausführen) und 2, wenn es wegen eines unsauberen (dirty) Logs nicht fortfahren kann. Bei einem unsauberen Log das Dateisystem einmal ein- und wieder aushängen (auf einer Maschine mit derselben CPU-Architektur), damit der Kernel das Log wieder einspielt, und danach erneut ausführen. xfs_repair -L setzt das Log stattdessen auf null: Alle Metadaten-Änderungen, die beim Absturz im Gang waren, gehen verloren, was laut Handbuch erhebliche Schäden verursachen kann – nur als letzter Ausweg und nach einem Image-Backup.
4. Für Btrfs: btrfs check verändert das Gerät standardmässig nicht (--readonly bekräftigt das nur); btrfsck ist ein veralteter Alias. Das Handbuch rät von --repair ab, „unless you are advised to do so by a developer or an experienced user“ (ausser ein Entwickler oder erfahrener Anwender rät dazu), und weist darauf hin, dass kein Checker jede Art von Beschädigung beheben kann. Wo ein Snapshot oder Backup existiert, ist die Wiederherstellung daraus --repair vorzuziehen; auf einem eingehängten Dateisystem prüft btrfs scrub start <mountpoint> die Prüfsummen online, was keine Strukturprüfung ist.
5. Um die Prüfung des Root-Dateisystems für einen einzelnen Boot zu erzwingen, im Boot-Menü fsck.mode=force ergänzen (wird es dauerhaft in der Konfiguration belassen, erzwingt es bei jedem Boot eine Prüfung; auto ist die Voreinstellung, skip deaktiviert Prüfungen). fsck.repair= (preen, yes, no) steuert, wie offensiv systemd-fsck Reparaturrückfragen bei dieser automatischen Prüfung beantwortet.
6. Den Exit-Status des generischen fsck als bitweise Summe lesen: 0 keine Fehler, 1 Fehler behoben, 2 System sollte neu gestartet werden, 4 Fehler nicht behoben, höhere Bits für Betriebsfehler. Die Codes mehrerer in einem Lauf geprüfter Dateisysteme werden per OR verknüpft; braucht ein Skript ein genaues Ergebnis, daher pro Aufruf nur ein Dateisystem prüfen.

Erwartetes Ergebnis

Ein sauberer Durchlauf meldet keine Beschädigung (Exit-Code 0, bzw. xfs_repair -n mit Exit-Code 0); nach einem Reparaturlauf ist das Dateisystem einhängbar, und die Zusammenfassung des Werkzeugs nennt, was behoben wurde.

Grenzen und Prüfbasis

XFS und Btrfs definieren eigene Exit-Codes und Optionen – nicht davon ausgehen, dass sie denen von fsck entsprechen. btrfs check --repair funktioniert noch nicht zusammen mit --mode=lowmem. Vor jeder Reparatur, die kein Probelauf ist, ein Backup (oder einen Snapshot) anlegen; ein Checker kann ein beschädigtes Dateisystem verschlimmern.