Dateisystem-Check und Reparatur mit fsck: Beschädigte ext4- und XFS-Systeme sicher reparieren

1. Wofür fsck da ist und wann ein Check nötig wird

fsck (File System Check) ist das zentrale Linux-Werkzeug zur Prüfung und Reparatur von Dateisystem-Metadaten. Es vergleicht die interne Buchführung eines Dateisystems, welche Blöcke belegt sind, welche Inodes zu welchen Dateien gehören, welche Verzeichniseinträge existieren, mit dem tatsächlichen Zustand auf der Platte und korrigiert Abweichungen. Solche Abweichungen entstehen fast immer durch einen unsauberen Shutdown, einen Stromausfall mitten im Schreibvorgang oder einen Kernel-Absturz, bei dem Schreiboperationen nicht vollständig abgeschlossen wurden.

Moderne Dateisysteme wie ext4 und XFS nutzen Journaling, um genau solche Situationen abzufedern, das Journal protokolliert Metadaten-Änderungen, bevor sie tatsächlich geschrieben werden, und kann nach einem Absturz automatisch wiederhergestellt werden. Ein vollständiger fsck-Lauf bleibt trotzdem notwendig, wenn das Journal selbst beschädigt ist, wenn ein Hardware-Fehler defekte Sektoren hinterlassen hat, oder wenn ein Dateisystem nach vielen Mount-Zyklen ohnehin planmäßig geprüft werden soll. Wer den Unterschied zwischen automatischer Journal-Wiederherstellung und einem vollständigen fsck-Check versteht, weiß auch, wann ein manueller Eingriff wirklich nötig ist.

2. Warum das Dateisystem vorher ausgehängt sein muss

Die wichtigste Regel im Umgang mit fsck lautet: niemals ein Dateisystem prüfen oder reparieren, während es gemountet und aktiv beschrieben wird. Läuft fsck parallel zu Schreibzugriffen der Anwendung, sieht es einen sich ständig verändernden Zustand und trifft Reparaturentscheidungen auf Basis von Daten, die im nächsten Moment schon wieder anders aussehen, das kann bestehende Beschädigungen verschlimmern statt sie zu beheben.

# Never run fsck on a mounted, actively written filesystem
sudo umount /dev/sdb1

# For the root filesystem, boot from a rescue medium or single-user mode instead
# systemctl rescue   (schedules a check-only run on next reboot, see below)

Für Datenpartitionen ist das Aushängen unproblematisch, sofern keine Prozesse mehr darauf zugreifen (lsof +D /mount/point zeigt offene Handles). Für das Root-Dateisystem selbst ist ein Aushängen im laufenden Betrieb naturgemäß nicht möglich, hier bleibt nur der Weg über ein Rescue-System, ein Live-Medium oder einen für den nächsten Neustart eingeplanten Check, wie im übernächsten Abschnitt beschrieben.

3. fsck ausführen: read-only, interaktiv, automatisch

Nach dem Aushängen stehen drei sinnvolle Betriebsmodi zur Verfügung. Der Read-only-Modus mit -n meldet gefundene Probleme, ändert aber nichts, das ist der sichere erste Schritt, um überhaupt einzuschätzen, wie stark ein Dateisystem betroffen ist. Der interaktive Modus fragt bei jeder Reparaturentscheidung nach, der vollautomatische Modus mit -y übernimmt alle vorgeschlagenen Korrekturen ohne Rückfrage.

# Read-only check, reports problems without changing anything
sudo fsck -n /dev/sdb1

# Automatic check-and-repair for routine cases (interactive prompts allowed)
sudo fsck -f /dev/sdb1

# Fully automatic repair, accepts all suggested fixes without asking
sudo fsck -y /dev/sdb1

# ext4-specific: force a full check even if the filesystem looks clean
sudo e2fsck -f /dev/sdb1

In der Praxis lohnt sich fast immer der Dreischritt: erst -n zur Diagnose, das Ergebnis genau lesen, und erst danach -y für die eigentliche Reparatur, idealerweise nachdem ein aktuelles Backup existiert oder zumindest ein Image der Platte per dd gezogen wurde. fsck bei ext4 ruft intern immer e2fsck auf, der direkte Aufruf von e2fsck liefert dieselben Optionen und teils detailliertere Fehlermeldungen.

4. Einen Check für den nächsten Neustart einplanen

Für das Root-Dateisystem, das im laufenden Betrieb nicht ausgehängt werden kann, bietet sich ein für den nächsten Neustart eingeplanter Check an. Klassisch geschieht das über eine leere Datei namens /forcefsck im Root-Verzeichnis, die der Init-Prozess beim nächsten Boot erkennt und dann automatisch einen fsck-Lauf auf allen relevanten Dateisystemen auslöst, bevor sie regulär gemountet werden.

# Schedule a filesystem check on the next reboot (systemd systems)
sudo touch /forcefsck
sudo reboot

# Alternative on systemd: request a check without a stray marker file
sudo systemctl reboot --force-fsck

# ext4: check how many mounts remain until the automatic periodic check
sudo tune2fs -l /dev/sdb1 | grep -i "mount count"

Unter systemd existiert mit systemctl reboot --force-fsck ein sauberer, expliziter Weg, ohne eine Marker-Datei manuell anzulegen. Zusätzlich prüfen ext4-Dateisysteme standardmäßig ohnehin nach einer bestimmten Anzahl von Mounts oder nach Ablauf eines Zeitintervalls automatisch, sichtbar über tune2fs -l, dieses Verhalten lässt sich mit tune2fs -c und -i anpassen oder bei Bedarf auch deaktivieren.

5. Besonderheiten bei XFS: xfs_repair statt fsck

Ein häufiges Missverständnis: fsck.xfs existiert zwar als Programm, führt aber lediglich einen trivialen Vor-Mount-Check aus und meldet, dass für echte Reparaturen ein anderes Werkzeug zuständig ist. Die eigentliche Prüfung und Reparatur von XFS-Dateisystemen übernimmt xfs_repair, ein eigenständiges Tool mit anderer Funktionsweise als fsck bei ext4.

# XFS uses a dedicated repair tool instead of fsck.xfs for actual repairs
# fsck.xfs itself only performs a trivial pre-mount sanity check

# Unmount first, then run a full structural check and repair
sudo umount /dev/sdc1
sudo xfs_repair /dev/sdc1

# Dry run: report problems without writing any changes
sudo xfs_repair -n /dev/sdc1

xfs_repair arbeitet grundsätzlich in zwei Phasen: zunächst wird versucht, das Dateisystem anhand des Journals in einen konsistenten Zustand zu bringen (Log-Replay), erst wenn das nicht ausreicht, folgt eine vollständige strukturelle Prüfung. Anders als bei ext4 gibt es bei XFS keinen interaktiven Modus mit Einzelbestätigung, xfs_repair trifft Reparaturentscheidungen automatisch, was den Ablauf vereinfacht, aber auch bedeutet, dass ein aktuelles Backup vor dem Lauf besonders wichtig ist.

6. lost+found verstehen und Fragmente zuordnen

Findet fsck oder xfs_repair Dateifragmente, die keinem Verzeichniseintrag mehr zugeordnet werden können, etwa weil der Verzeichniseintrag selbst beschädigt war, verschiebt das Tool diese Fragmente in das Verzeichnis lost+found im Wurzelverzeichnis des jeweiligen Dateisystems. Die Dateien tragen dort nur noch ihre Inode-Nummer als Namen, der ursprüngliche Dateiname ist verloren, der Inhalt in aller Regel aber noch vollständig vorhanden.

# Inspect recovered fragments after a repair moved them to lost+found
ls -la /mount/point/lost+found

# Identify file types of recovered, unnamed inodes
file /mount/point/lost+found/*

# Cross-check against a recent backup to restore correct filenames
diff -rq /mount/point/lost+found /backup/latest/

Um wiederhergestellte Fragmente sinnvoll zuzuordnen, hilft file zur groben Typbestimmung (Textdatei, Bild, Archiv), bei bekannten Formaten oft auch ein Blick in den Dateiinhalt selbst. Existiert ein aktuelles Backup, lässt sich per diff -rq häufig recht schnell feststellen, welche Datei aus dem Backup dem jeweiligen Fragment in lost+found entspricht, und der ursprüngliche Name lässt sich wiederherstellen.

7. Superblock-Probleme und Backup-Superblocks nutzen

Der Superblock ist die wichtigste Metadatenstruktur eines Dateisystems, er enthält unter anderem Größe, Blockgröße und den Zeiger auf die Inode-Tabelle. Ist der primäre Superblock beschädigt, meldet der Kernel beim Mount-Versuch typischerweise einen unbekannten Dateisystemtyp, obwohl das Dateisystem eigentlich intakt ist, ext4 legt aus genau diesem Grund mehrere redundante Backup-Superblocks an verschiedenen, vorhersehbaren Positionen an.

Mit mke2fs -n /dev/sdb1 lässt sich, ohne tatsächlich etwas zu formatieren, die Liste aller Backup-Superblock-Positionen eines Dateisystems anzeigen. Der Befehl fsck -b 32768 /dev/sdb1 weist fsck an, statt des defekten primären Superblocks einen der intakten Backup-Superblocks zu verwenden, in den meisten Fällen lässt sich das Dateisystem damit wieder vollständig reparieren, selbst wenn der Mount-Versuch zuvor komplett fehlgeschlagen ist.

8. Fehlern vorbeugen: Journaling, USV, sauberes Herunterfahren

Die beste Reparatur ist die, die nie nötig wird. Journaling bei ext4 und XFS reduziert die Häufigkeit ernsthafter Dateisystemfehler bereits erheblich, ersetzt aber keine unterbrechungsfreie Stromversorgung (USV) auf physischen Servern, die einen kontrollierten Shutdown bei Stromausfall ermöglicht, statt das System hart abstürzen zu lassen.

Auf virtuellen Servern und in Cloud-Umgebungen ist das Risiko eines unsauberen Shutdowns durch Host-seitige Wartung oder Migration real, hier hilft ein sauber konfigurierter systemctl poweroff beziehungsweise reboot statt eines harten Reset, wo immer das möglich ist. Zusätzlich lohnt sich smartctl -a als regelmäßige Prüfung, ob die zugrunde liegende Hardware bereits Anzeichen eines bevorstehenden Ausfalls zeigt, bevor daraus ein Dateisystemfehler wird.

9. fsck-Werkzeuge im direkten Vergleich

Je nach Dateisystem und Situation kommt ein anderes Werkzeug zum Einsatz. Die folgende Übersicht ordnet die wichtigsten Optionen ein.

In der Praxis ist der größte Fehler, fsck oder xfs_repair unvorbereitet auf ein gemountetes oder gerade beschriebenes Dateisystem loszulassen. Erst aushängen, dann read-only prüfen, erst danach reparieren, das ist die Reihenfolge, die aus einem reparierbaren Problem keine vollständige Datenkatastrophe macht.

10. Zusammenfassung

fsck und sein XFS-Pendant xfs_repair sind die zentralen Werkzeuge, um beschädigte Linux-Dateisysteme zu erkennen und zu reparieren. Entscheidend ist die richtige Reihenfolge: erst das Dateisystem aushängen, dann read-only prüfen, und erst danach mit voller Reparatur fortfahren, idealerweise mit einem aktuellen Backup als Sicherheitsnetz.

Superblock-Probleme lassen sich fast immer über einen der redundanten Backup-Superblocks lösen, wiederhergestellte Fragmente landen in lost+found und können mit file und einem Abgleich gegen ein Backup meist wieder korrekt benannt werden. Prävention durch Journaling, USV und sauberes Herunterfahren bleibt trotzdem die beste Strategie.

11. FAQ: Dateisystem-Check und Reparatur mit fsck