Linux Deutsch

Linux-Dateisysteme mit fsck prüfen und reparieren

Lernen Sie, Linux-Dateisysteme mit fsck sicher zu identifizieren, auszuhängen, zu prüfen und dateisystemspezifisch zu reparieren.

fsck ist ein übergreifendes Linux-Werkzeug zur Konsistenzprüfung von Dateisystemen. Es startet abhängig vom erkannten Dateisystem ein passendes Prüfprogramm und kann erkannte logische Fehler häufig reparieren. Eine Reparatur ist jedoch immer ein Eingriff in die Datenstruktur und sollte vorbereitet werden.

Diese Anleitung zeigt den sicheren Ablauf für Einsteiger und Administratoren: Zielgerät bestimmen, Sicherung erstellen, Dateisystem aushängen, Prüfung ausführen, Ergebnisse bewerten und das Ergebnis kontrollieren.

Was fsck prüft und wann es benötigt wird

Ein Dateisystem organisiert Dateien, Verzeichnisse und Metadaten auf einem Datenträger. Bei ext-Dateisystemen enthalten beispielsweise Inodes Dateieigenschaften und Verweise auf Datenblöcke. fsck vergleicht solche Strukturen und sucht nach Widersprüchen.

Inkonsistenzen entstehen häufig durch:

• ein ungeplantes Ausschalten oder einen Stromausfall,
• unterbrochene Schreibvorgänge,
• Softwarefehler oder Kernelprobleme,
• beschädigte Kabel, Controller oder andere Hardware,
• fehlerhafte oder alternde Datenträger.

Mögliche Befunde sind fehlende Verzeichnisreferenzen, verwaiste Inodes oder Datenblöcke, beschädigte Metadaten und nicht mehr korrekt verknüpfte Dateien. Bei der Reparatur können Verzeichniseinträge, Dateinamen oder nicht zuordenbare Daten verloren gehen.

Ein Dateisystem kann nach einem Absturz zwar noch eingebunden werden, trotzdem sollte eine vom System angekündigte Prüfung ernst genommen werden. Wiederkehrende Fehler weisen allerdings oft auf ein Hardware- oder Softwareproblem hin, das fsck allein nicht behebt.

Sicherheitsregeln vor jeder Prüfung

1. Sichern: Erstellen Sie möglichst ein aktuelles Backup wichtiger Daten. Bei kritischen Systemen und vermuteten Lesefehlern ist ein sektorweises Abbild sinnvoll.
2. Ziel eindeutig identifizieren: Prüfen Sie Gerätepfad, Partition, Dateisystemtyp, UUID und Mountpoint. Niemals nur anhand einer vermuteten Laufwerksnummer arbeiten.
3. Nutzung beenden: Eine reparierende Prüfung darf nicht auf einem schreibbar eingehängten und aktiv genutzten Dateisystem laufen.
4. Reparaturfragen lesen: Automatische Antworten können Strukturen verändern. Bestätigen Sie eine Frage erst, wenn ihre Bedeutung klar ist.

Das Root-Dateisystem ist das Dateisystem, von dem das laufende Linux-System arbeitet. Es sollte im normalen Betrieb nicht ausgehängt werden. Verwenden Sie stattdessen den Recovery- oder Rescue-Modus, einen Wartungsmodus oder ein Live-System. Für eine Datenpartition reicht meist eine geplante Wartungssitzung, in der alle Zugriffe beendet werden.

Zielgerät, Partition und Mountpoint unterscheiden

Ein Blockgerät ist eine Gerätedatei für einen Datenträger oder einen abgegrenzten Bereich davon, zum Beispiel /dev/sdb1. Eine Partition ist ein solcher abgegrenzter Bereich. Ein Mountpoint ist dagegen ein Verzeichnis, unter dem ein Dateisystem in den Linux-Verzeichnisbaum eingehängt ist, etwa /mnt/daten.

fsck wird typischerweise gegen das Blockgerät ausgeführt, nicht gegen den Mountpoint:

sudo fsck /dev/sdb1

Ermitteln Sie die Zuordnung zunächst mit mehreren Informationen:

lsblk -f
findmnt
sudo blkid

lsblk -f zeigt Geräte, Partitionen, Dateisystemtypen, UUIDs und Mountpoints in einer Übersicht. findmnt beantwortet, welches Gerät aktuell unter welchem Verzeichnis eingehängt ist. blkid liest Dateisystemsignaturen, Typen und UUIDs.

Die sichtbare Gerätehierarchie kann durch weitere Speicherebenen komplizierter sein:

• Bei LVM liegt das Dateisystem meist auf einem Logical Volume und nicht direkt auf der physischen Partition.
• Bei RAID liegt das Dateisystem auf dem RAID-Gerät, beispielsweise einem zusammengeführten Array.
• Bei Verschlüsselung liegt das Dateisystem auf dem geöffneten verschlüsselten Gerät, nicht auf dem verschlüsselten Container selbst.

Prüfen Sie immer die Ebene, auf der das Dateisystem tatsächlich liegt. Stimmen UUID, Typ und Mountpoint nicht mit der geplanten Wartung überein, brechen Sie den Vorgang ab.

Dateisystem sicher aushängen

Beispiel für eine nicht benötigte Datenpartition:

findmnt /mnt/daten
sudo umount /mnt/daten

Danach kontrollieren Sie erneut, dass der Mountpoint nicht mehr eingehängt ist. Erst dann ist eine Prüfung mit möglichen Änderungen grundsätzlich zulässig. Offene Dateien, ein Terminal im Mountpoint oder laufende Dienste können das Aushängen verhindern.

Für das Root-Dateisystem wechseln Sie in einen Recovery- oder Rescue-Modus oder starten von einem Live-System. Identifizieren Sie dort das Zielgerät und stellen Sie sicher, dass es nicht schreibbar eingehängt ist. Bei LVM, RAID oder Verschlüsselung müssen die notwendigen Speicherlagen korrekt aktiviert sein, bevor das passende Dateisystemwerkzeug eingesetzt wird.

fsck als Frontend für spezialisierte Werkzeuge

fsck ist ein allgemeiner Aufrufer. Anhand des Dateisystemtyps wählt es ein spezialisiertes Programm aus. Die Optionen und Reparaturverfahren sind nicht für alle Dateisysteme gleich.

Für ext-Dateisysteme können Sie direkt arbeiten:

sudo e2fsck -f /dev/sdb1

-f erzwingt die Prüfung auch dann, wenn das Dateisystem seinen Zustand als sauber meldet. Eine Prüfung ohne Schreibänderungen kann bei ext-Dateisystemen beispielsweise mit e2fsck -n vorbereitet werden. Lesen Sie vor dateisystemspezifischen Optionen die passende Handbuchseite:

man fsck
man e2fsck
man xfs_repair
man btrfs-check

Wichtige fsck-Optionen

Beispiele:

sudo fsck -N -A
sudo fsck -t ext4 /dev/sdb1
sudo fsck -A -R -V

fsck -A -R -V ist kein Ersatz für die Vorbereitung: Die betroffenen Nicht-Root-Dateisysteme dürfen nicht aktiv beschreibbar genutzt werden. Die dateisystemspezifischen Optionen, etwa für ext4 oder XFS, gehören nicht automatisch zum allgemeinen fsck-Optionssatz.

Praktisches Beispiel: ext4-Datenpartition prüfen

1. Ermitteln Sie das Ziel: lsblk -f. Vergleichen Sie Gerät, Typ, UUID und Mountpoint mit Ihrer Dokumentation oder /etc/fstab.
2. Erstellen oder prüfen Sie das Backup wichtiger Daten.
3. Beenden Sie Anwendungen, die auf /mnt/daten zugreifen, und hängen Sie aus: sudo umount /mnt/daten.
4. Führen Sie zunächst eine nicht verändernde Untersuchung aus, beispielsweise sudo e2fsck -n /dev/sdb1.
5. Bewerten Sie die Ausgabe. Wenn eine Reparatur erforderlich und durch Backup oder Abbild abgesichert ist, führen Sie eine interaktive Prüfung aus: sudo e2fsck /dev/sdb1.
6. Lesen Sie jede Reparaturfrage. Automatische Antworten wie -y sollten Sie nur in einem kontrollierten, abgesicherten Ablauf verwenden.
7. Prüfen Sie das Dateisystem nach der Reparatur erneut.
8. Hängen Sie es kontrolliert ein und testen Sie den Zugriff auf wichtige Daten.

Root-Dateisystem nach einem fehlerhaften Start

Wenn Linux beim Start eine Prüfung des Root-Dateisystems verlangt oder nicht normal startet, verwenden Sie eine Recovery-/Rescue-Umgebung oder ein Live-System. Identifizieren Sie die Root-Partition oder das Logical Volume mit lsblk -f, prüfen Sie den Mountstatus und verwenden Sie das Werkzeug für den tatsächlichen Dateisystemtyp.

Bei ext4 kann das beispielsweise e2fsck sein. Bei XFS verwenden Sie xfs_repair, nachdem das XFS-Dateisystem ausgehängt wurde. Nach erfolgreicher Prüfung starten Sie das installierte System kontrolliert neu und kontrollieren anschließend Protokolle sowie die wichtigsten Daten.

Automatische Prüfung beim Systemstart und /etc/fstab

/etc/fstab beschreibt Dateisysteme, die dauerhaft eingehängt werden sollen. Die Datei enthält unter anderem Gerät oder UUID, Mountpoint, Typ, Mountoptionen und ein sechstes Feld namens fs_passno. Dieses Feld steuert die Prüfung beim Systemstart.

UUID=<uuid> /daten ext4 defaults 0 2

Dateisysteme mit derselben Priorität können je nach Startumgebung parallel geprüft werden. Das kann die Startzeit verkürzen, ist aber bei abhängigen Speicherpfaden oder gemeinsam benötigten Ressourcen nicht beliebig. Moderne Distributionen steuern Prüfungen zusätzlich über systemd, Boot-Parameter und dateisystemspezifische Mechanismen. Deshalb sollte die reale Startkonfiguration nicht allein aus dem fstab-Feld abgeleitet werden.

Ausgabe und Rückgabecodes verstehen

Eine Prüfung kann melden, dass das Dateisystem sauber ist, Inkonsistenzen gefunden wurden, Korrekturen durchgeführt wurden oder Fehler nicht behoben werden konnten. Speichern Sie bei administrativen Arbeiten die Ausgabe und notieren Sie Gerät, Zeitpunkt, Werkzeug und Rückgabecode.

Die genaue Textausgabe ist zusätzlich wichtig. Ein Code allein erklärt nicht, ob ein Gerät falsch angegeben, eine Prüfung abgebrochen oder ein Datenträger nicht lesbar war.

XFS und Btrfs: eigene Arbeitsabläufe

Bei XFS ist eine reparierende Standard-fsck-Prüfung nicht der vorgesehene Ablauf. Ermitteln Sie zuerst den Typ, hängen Sie das Dateisystem aus und simulieren Sie die Reparatur:

sudo xfs_repair -n /dev/sdb1

-n schreibt keine Reparaturen. Sichern Sie vor einem tatsächlichen Eingriff und bewerten Sie die Befunde. Bei Btrfs verwenden Sie btrfs check. Optionen und Grenzen unterscheiden sich deutlich von ext-Dateisystemen; insbesondere sollten Reparaturoptionen nicht ohne Sicherung und genaue Kenntnis der Warnhinweise eingesetzt werden.

Fehlerdiagnose und Eskalation

Gerät ist eingehängt oder in Benutzung

Prüfen Sie mit findmnt, ob das Ziel noch eingehängt ist. Beenden Sie Zugriffe, hängen Sie eine Nicht-Root-Partition sauber aus und kontrollieren Sie blockierende Dienste oder Prozesse. Ist das Ziel das laufende Root-Dateisystem, wechseln Sie in eine Rettungsumgebung.

Gerätepfad oder Ziel ist unklar

Geänderte Laufwerksreihenfolgen können Gerätenamen wie /dev/sdb verändern. LVM, RAID und Verschlüsselung können zusätzlich mehrere Ebenen einführen. Vergleichen Sie daher lsblk -f, blkid, findmnt und die UUID aus /etc/fstab, bevor Sie einen Befehl ausführen.

Fehler erscheinen nach dem Neustart erneut

Wiederkehrende Inkonsistenzen sprechen für ein ungelöstes Grundproblem. Sichern Sie wichtige Daten sofort und untersuchen Sie SMART-Werte, Kernelmeldungen, Kabel, Stromversorgung, Controller, RAID-Status und den freien Speicherplatz. Schreibfehler, I/O-Fehler oder eine wachsende Zahl defekter Sektoren können den Austausch des Laufwerks erforderlich machen.

Nicht korrigierbare Fehler

Bei Code 4 oder zusätzlichen I/O-Fehlern sollten Sie keine wiederholten riskanten Reparaturversuche ohne Sicherung durchführen. Verifizieren Sie den Dateisystemtyp und das Werkzeug. Erstellen Sie bei kritischen Daten möglichst ein sektorweises Abbild und ziehen Sie professionelle Datenrettung oder eine Wiederherstellung aus dem Backup in Betracht.

Sicherer Ablauf als Kurzcheckliste

1. Backup oder Abbild erstellen.
2. Gerät, Partition, Dateisystemtyp, UUID und Mountpoint identifizieren.
3. Abhängigkeiten wie LVM, RAID und Verschlüsselung berücksichtigen.
4. Dateisystem aushängen; Root nur aus einer geeigneten Rettungsumgebung prüfen.
5. Passendes Werkzeug und zunächst eine möglichst nicht verändernde Prüfung verwenden.
6. Ausgabe und Reparaturfragen sorgfältig bewerten.
7. Reparatur nur abgesichert durchführen.
8. Erneut prüfen, kontrolliert einhängen und Daten sowie Protokolle kontrollieren.

Für Grundlagen zu Mountpoints und Dateisysteminformationen helfen die Lektionen Dateisysteme mounten und Dateisysteminformationen anzeigen. Ergänzend behandelt die Anleitung zur Datei /etc/fstab die dauerhafte Einbindung, während Dateisysteme debuggen weiterführende Diagnosewerkzeuge einordnet.