VMware ESXi and vSphere Cluster Management

Dateisysteme unter Linux mit fsck prüfen und reparieren

Linux-Dateisysteme sicher mit fsck prüfen: Geräte identifizieren, Partitionen aushängen, Fehler reparieren und passende Werkzeuge für ext, XFS, Btrfs und FAT verwenden.

Ein beschädigtes oder inkonsistentes Dateisystem kann dazu führen, dass Dateien nicht mehr erreichbar sind, Verzeichnisse fehlerhafte Einträge enthalten oder das System nicht startet. Unter Linux koordiniert fsck die Prüfung von Dateisystemen und ruft dafür das passende, dateisystemspezifische Prüfprogramm auf.

Dieser Artikel zeigt eine sichere Vorgehensweise für manuelle Prüfungen und Reparaturen. Die wichtigste Regel lautet: Eine Partition wird im Normalfall zuerst ausgehängt und erst danach geprüft oder repariert.

Was prüft ein Dateisystemcheck?

Ein Dateisystem ist die Struktur, mit der Linux Dateien und Verzeichnisse auf einem Speicherbereich organisiert. Dazu gehören unter anderem Verzeichniseinträge, Metadaten, Inodes und Datenblöcke.

• Ein Inode ist eine Metadatenstruktur eines Unix-Dateisystems. Sie beschreibt beispielsweise Besitzer, Rechte, Größe und Verweise auf Datenblöcke.
• Datenblöcke enthalten die eigentlichen Dateiinhalte oder Teile davon.
• Verzeichnisse verknüpfen Dateinamen mit Inodes.
• Das Dateisystem verwaltet zusätzlich freie und belegte Bereiche sowie Konsistenzinformationen.

Ein Dateisystem ist konsistent, wenn diese Beziehungen zusammenpassen. Beispielsweise muss ein Verzeichniseintrag auf einen gültigen Inode verweisen, und ein Datenblock darf nicht gleichzeitig mehreren unabhängigen Dateien zugeordnet sein.

Typische Ursachen für Inkonsistenzen

• unerwarteter Stromverlust oder ein hartes Ausschalten,
• System- oder Kernelabsturz während eines Schreibvorgangs,
• defekte Datenträger, Kabel oder Stromversorgungen,
• Übertragungsfehler, etwa bei externen Laufwerken,
• fehlerhafte Treiber oder Software.

Mögliche Folgen sind beschädigte Verzeichniseinträge, fehlende Zuordnungen zwischen Dateien und Datenblöcken, nicht referenzierte Daten, nicht erreichbare Dateien und im schlimmsten Fall Datenverlust.

Prüfung und Reparatur sind nicht dasselbe

Eine Prüfung untersucht die Strukturen und meldet erkannte Unstimmigkeiten. Eine Reparatur verändert Metadaten oder Zuordnungen, um diese Unstimmigkeiten zu beheben. Je nach Fehler kann eine Reparatur Dateien umbenennen, Verzeichniseinträge entfernen oder Daten in ein spezielles Verzeichnis verschieben. Deshalb sollten Sie Reparaturen nicht leichtfertig und nicht ohne Sicherung starten.

Grundlagen von fsck

fsck ist ein allgemeiner Aufrufmechanismus für Dateisystemprüfprogramme. Als Ziel geben Sie ein Blockgerät beziehungsweise eine Partition an, nicht den Verzeichnispfad eines Mountpoints.

Ein Blockgerät ist eine Gerätedatei für einen Datenträger oder eine Partition, beispielsweise /dev/sdb1. Ein Mountpoint ist dagegen ein Verzeichnis, über das ein eingehängtes Dateisystem erreichbar ist, beispielsweise /mnt/daten.

sudo fsck /dev/sdb1

Für den Zugriff auf Gerätedateien und für Reparaturen benötigen Sie normalerweise administrative Rechte über root oder sudo. fsck erkennt den Dateisystemtyp beziehungsweise übernimmt ihn aus der Konfiguration und ruft das passende Prüfprogramm auf. Bei ext2, ext3 und ext4 ist das typischerweise e2fsck.

Vorbereitung: Die richtige Partition bestimmen

Verwechseln Sie nicht den gesamten Datenträger, eine Partition, ein logisches Volume und das darauf liegende Dateisystem. Eine falsche Gerätedatei kann zur Prüfung oder Änderung eines völlig anderen Datenbestands führen.

lsblk -f
findmnt /mnt/daten
mount
cat /etc/fstab

lsblk -f zeigt Geräte, Partitionen, Dateisystemtypen, UUIDs und Mountpoints. Mit findmnt ermitteln Sie, welches Gerät an einem bestimmten Einhängepunkt verwendet wird. mount listet aktuell eingehängte Dateisysteme auf. In /etc/fstab finden Sie dauerhaft definierte Einhängepunkte und gegebenenfalls die Prüfreihenfolge.

Sicherheitsregeln vor fsck

Ein Dateisystemcheck darf im Normalfall nicht auf einem eingehängten und schreibbaren Dateisystem ausgeführt werden. Während der Prüfung müssen die Strukturen stabil bleiben. Parallele Schreibzugriffe können die Analyse verfälschen und zusätzliche Schäden oder Datenverlust verursachen.

1. Identifizieren Sie Gerät, Partition, Dateisystemtyp und Mountpoint.
2. Schließen Sie Anwendungen, die auf das Dateisystem zugreifen.
3. Beenden Sie auch Shells, deren aktuelles Arbeitsverzeichnis auf der Partition liegt.
4. Hängen Sie das Dateisystem aus.
5. Führen Sie erst danach die Prüfung oder Reparatur aus.

sudo umount /dev/sdb1
sudo fsck /dev/sdb1

Das Root-Dateisystem ist eine besondere Ausnahme: Das laufende System benötigt es selbst, daher kann es im Normalbetrieb meist nicht vollständig ausgehängt werden. Starten Sie für eine Root-Prüfung ein Recovery-, Rettungs- oder Live-System und stellen Sie sicher, dass die betreffende Partition dort nicht eingehängt ist.

Manuelle Dateisystemprüfung

Für eine nicht eingehängte Datenpartition ist die Grundform einfach:

sudo fsck /dev/sdb1

fsck kann bei gefundenen Fehlern Rückfragen stellen. Lesen Sie die vorgeschlagenen Änderungen und bestätigen Sie nur, wenn Sie das Ziel und die Konsequenzen verstehen. Für ext-Dateisysteme können Sie das zuständige Programm auch direkt aufrufen:

sudo e2fsck /dev/sdb1

Die genaue Ausgabe hängt vom Dateisystem und vom aufgerufenen Prüfprogramm ab. Häufig verwendete Rückgabecodes von fsck sind:

• 0: keine Fehler gefunden,
• 1: Fehler wurden korrigiert,
• 2: Fehler wurden korrigiert; ein Neustart kann erforderlich sein,
• 4: nicht korrigierte Fehler vorhanden,
• 8: Betriebsfehler, beispielsweise ein Problem beim Ausführen,
• 16: Fehler in Verwendung oder Syntax.

Die genaue Bedeutung kann vom Frontend oder vom konkreten Prüfprogramm abweichen. Bei einem nicht erfolgreichen Ergebnis sollten Sie die Ausgabe sichern, keine beliebigen weiteren Reparaturbefehle ausführen und zunächst Backup- oder Datenrettungsmaßnahmen planen.

Wichtige fsck-Optionen

Die Optionen gehören zum fsck-Frontend. Das konkrete Verhalten kann je nach Distribution, Frontend und dateisystemspezifischem Werkzeug abweichen. Prüfen Sie bei Unsicherheit die lokale Handbuchseite mit man fsck und die Dokumentation des jeweiligen Prüfprogramms.

Automatische Prüfungen beim Systemstart

/etc/fstab beschreibt Dateisysteme, die dauerhaft eingehängt werden können. Ein typischer Eintrag sieht so aus:

UUID=<uuid> /mnt/daten ext4 defaults 0 2

Das letzte Feld enthält die Prüfreihenfolge beziehungsweise aktiviert oder deaktiviert die traditionelle fsck-basierte Prüfung:

• 0 bedeutet üblicherweise: keine Prüfung durch den traditionellen fstab-Mechanismus.
• 1 wird üblicherweise für das Root-Dateisystem verwendet und hat höchste Priorität.
• 2 wird typischerweise für weitere Dateisysteme verwendet, die danach geprüft werden können.

Das Root-Dateisystem wird normalerweise zuerst geprüft, weitere Dateisysteme folgen anschließend. Die konkrete Umsetzung hängt jedoch von Distribution, Init-System und Dateisystemtyp ab. Moderne Systeme können zusätzlich systemd-Units, Dateisystem-spezifische Wartungsintervalle oder andere Mechanismen einsetzen. Eine fstab-basierte Prüfung ist daher nicht gleichbedeutend mit jeder automatischen Dateisystemwartung.

sudo fsck -AN
sudo fsck -AR
sudo fsck -AV

Mit -AN können Sie zunächst nachvollziehen, welche fstab-Dateisysteme ausgewählt würden. Kontrollieren Sie Geräte, Typen und aufgerufene Programme, bevor Sie eine produktive Prüfung starten.

Dateisystemspezifische Werkzeuge und Grenzen

Der Dateisystemtyp muss vor einer Reparatur bekannt sein. Ermitteln Sie ihn beispielsweise mit lsblk -f oder geeigneten Systemwerkzeugen. fsck kann keine mechanischen Defekte, defekte Controller, instabile Stromversorgung oder bereits verlorene Dateiinhalte reparieren. Ein erfolgreicher Strukturcheck beweist außerdem nicht, dass jede Datei inhaltlich unverändert ist.

Praktisches Beispiel: Datenpartition sicher prüfen

lsblk -f
findmnt /mnt/daten
sudo umount /dev/sdb1
sudo fsck /dev/sdb1
sudo mount /dev/sdb1 /mnt/daten
findmnt /mnt/daten

Nach dem Einhängen prüfen Sie, ob wichtige Dateien und Verzeichnisse wieder erreichbar sind. Bei einem ext-Dateisystem sehen Sie zusätzlich in /mnt/daten/lost+found nach, falls die Reparatur nicht zuordenbare Objekte wiedergefunden hat.

Fehlerbehebung

fsck meldet, dass das Dateisystem eingehängt ist

Prüfen Sie zunächst den Einhängepunkt und schließen Sie Programme, Shells und Dienste, die darauf zugreifen.

findmnt /dev/sdb1
findmnt /mnt/daten
sudo umount /dev/sdb1

Wenn das Aushängen wegen aktiver Zugriffe fehlschlägt, ermitteln Sie den verursachenden Prozess mit den auf Ihrem System verfügbaren Werkzeugen. Verwenden Sie keine gewaltsame Lösung, bevor Sie die möglichen Folgen verstanden haben. Bei der Root-Partition wechseln Sie in eine Offline- oder Recovery-Umgebung.

Das System startet nach einem Stromausfall nicht

Starten Sie ein Recovery-, Rettungs- oder Live-System. Identifizieren Sie dort die Linux-Partition mit lsblk -f, bestätigen Sie den Dateisystemtyp und stellen Sie sicher, dass die Partition nicht eingehängt ist. Führen Sie anschließend das passende Prüfprogramm aus.

Dateien liegen nach der Reparatur in lost+found

Das bedeutet meist, dass Dateiobjekte oder Datenfragmente wiedergefunden wurden, aber keine gültige Verzeichniszuordnung mehr besitzen. Untersuchen Sie Größe, Inhalt und Dateityp. Kopieren Sie verwertbare Daten in ein sicheres Ziel und vergleichen Sie sie mit vorhandenen Backups.

Fehler treten wiederholt auf

Wiederkehrende Inkonsistenzen sind oft ein Hinweis auf ein Hardware- oder Verbindungsproblem. Sichern Sie wichtige Daten sofort und prüfen Sie:

• SMART-Informationen des Datenträgers,
• Systemprotokolle auf I/O- oder Controllerfehler,
• Kabel, Steckverbindungen und Stromversorgung,
• bei entsprechenden Hinweisen auch den Arbeitsspeicher.

Wenn ein Datenträger ausfällt, sollten Sie ihn ersetzen und nicht ausschließlich wiederholt fsck ausführen. Schlägt eine Reparatur fehl, priorisieren Sie ein Abbild, Datenrettung und Backups. Wiederholte riskante Reparaturversuche können den Zustand verschlechtern.

fsck ist für XFS oder Btrfs nicht die passende Reparaturmethode

Verifizieren Sie zunächst den Dateisystemtyp und verwenden Sie das dafür vorgesehene Werkzeug. Bei XFS ist typischerweise xfs_repair zuständig. Bei Btrfs wird btrfs check verwendet; insbesondere Reparaturoptionen sollten nur mit vollständigem Verständnis und möglichst nach Erstellung eines Abbilds oder Backups eingesetzt werden.

Prüfung, Reparatur und Nachbereitung: die wichtigsten Regeln

1. Gerätedatei, Partition, logisches Volume und Dateisystemtyp eindeutig bestimmen.
2. Wichtige Daten vor einer Reparatur sichern.
3. Das Ziel aus dem Verzeichnisbaum aushängen.
4. Für die Root-Partition eine Offline-Umgebung verwenden.
5. Das passende Prüfprogramm für den Dateisystemtyp auswählen.
6. Ausgabe und Rückgabecode auswerten, statt nur auf eine scheinbar erfolgreiche Befehlsausführung zu achten.
7. Nach dem Einhängen Dateien, Verzeichnisse und gegebenenfalls lost+found kontrollieren.
8. Bei wiederkehrenden Fehlern Hardware und Protokolle untersuchen.

Weitere Informationen zu diesem Ablauf finden Sie auch unter Dateisystemcheck durchführen.