file system check in linux

Festplatten sterben leise. Manchmal fängt es mit einer winzigen Verzögerung beim Speichern an, ein anderes Mal verschwindet einfach ein Ordner im digitalen Nirgendwo. Wer dann nicht weiß, wie man einen ordentlichen File System Check In Linux durchführt, steht vor einem Scherbenhaufen aus Nullen und Einsen. Es ist kein Geheimnis, dass Linux-Systeme als stabil gelten. Aber Hardware ist fehleranfällig. Ein Stromausfall im falschen Moment reicht aus, um die Metadaten deines ext4- oder btrfs-Dateisystems zu korrumpieren. Ich habe schon Admins gesehen, die schweißgebadet vor Servern saßen, weil sie die Warnsignale ignoriert haben. In diesem Text zeige ich dir, wie du dein System prüfst, ohne alles kaputtzumachen.

Die harte Realität der Dateisystemfehler

Dateisysteme sind im Grunde gigantische Buchhaltungssysteme. Sie halten fest, welches Bit zu welcher Datei gehört. Wenn diese Buchführung Fehler aufweist, spricht man von Inkonsistenz. Das passiert oft durch unsauberes Herunterfahren. Wenn der Kernel die Schreibpuffer nicht leeren kann, bevor der Saft weg ist, fehlen Informationen. Moderne Journaling-Dateisysteme fangen viel ab. Sie führen ein Tagebuch über geplante Änderungen. Trotzdem ist das kein Freifahrtschein für Nachlässigkeit.

Warum fsck dein bester Freund ist

Das Standardwerkzeug für diese Aufgabe ist fsck. Der Name steht für file system consistency check. Es ist ein Wrapper, der je nach Typ des Dateisystems das passende Unterprogramm aufruft. Für ext4 ist das zum Beispiel e2fsck. Wer nur stur den Befehl eintippt, riskiert jedoch Datenverlust. Die wichtigste Regel lautet: Prüfe niemals eine eingehängte Partition. Das ist wie eine Operation am offenen Herzen, während der Patient gerade einen Marathon läuft. Das System versucht ständig zu schreiben, während das Prüftool versucht, Fehler zu korrigieren. Das Ergebnis ist meist ein totales Chaos.

Anzeichen für drohendes Unheil

Du merkst es oft zuerst an Fehlermeldungen in den Logs. Schau mit dmesg oder in /var/log/syslog nach. Wenn dort Begriffe wie "I/O error" oder "Read-only file system" auftauchen, brennt die Hütte. Linux schaltet Partitionen oft automatisch in den Nur-Lese-Modus, wenn es schwere Fehler erkennt. Das ist eine Schutzmaßnahme. Es verhindert, dass noch mehr kaputte Daten geschrieben werden. In so einem Moment darfst du nicht einfach neu starten und hoffen. Du musst handeln.

Den File System Check In Linux richtig vorbereiten

Bevor du die Reparatur startest, brauchst du einen Plan. Wenn es sich um dein Root-Verzeichnis handelt, kannst du es nicht einfach im laufenden Betrieb aushängen. Hier kommt ein Live-System ins Spiel. Ein USB-Stick mit Ubuntu oder Fedora ist in jedem Werkzeugkasten Pflicht. Boote von diesem Stick. So bleiben deine internen Platten unangetastet und "kalt".

Den richtigen Gerätenamen finden

Bevor du loslegst, musst du wissen, welche Partition du bearbeitest. Der Befehl lsblk gibt dir eine Übersicht. Achte auf die Spalte "MOUNTPOINT". Wenn dort ein Schrägstrich oder ein Pfad steht, ist die Partition eingehängt. Mit umount /dev/sdX1 hängst du sie aus. Ersetze das X durch den Buchstaben deiner Platte. Sei hier extrem vorsichtig. Ein Tippfehler und du löschst die falsche Partition. Ich habe das einmal bei einem Backup-Server gemacht. Das war kein schöner Nachmittag.

Die Bedeutung des Superblocks

Jedes Dateisystem hat einen Superblock. Er enthält die kritischen Informationen über die Struktur. Wenn der Haupt-Superblock beschädigt ist, verweigert Linux den Dienst. Zum Glück gibt es Sicherheitskopien. Mit dem Befehl mke2fs -n /dev/sdX1 kannst du dir anzeigen lassen, wo diese Backups liegen. Das Flag -n ist hier lebenswichtig. Es simuliert den Befehl nur. Ohne das -n würdest du ein neues Dateisystem erstellen und alles löschen. Mit den Informationen aus dieser Simulation kannst du fsck anweisen, einen alternativen Superblock zu nutzen.

Schritt für Schritt zur Reparatur

Wenn du bereit bist, startest du den Prozess. Meistens reicht ein einfacher Aufruf. Aber Profis nutzen Parameter. Der Schalter -p steht für "preen". Damit korrigiert das Tool alle Fehler, die sicher ohne menschliches Eingreifen repariert werden können. Wenn du mehr Kontrolle willst, nimm -y. Das beantwortet alle Fragen automatisch mit Ja. Das ist bequem, aber riskant bei schweren Schäden.

Umgang mit lost+found

Nach einem intensiven Lauf findest du oft Dateien im Ordner lost+found. Das sind Datenfragmente, die das System zwar retten konnte, aber keiner Datei mehr zuordnen kann. Sie heißen dann einfach #12345. Du musst diese Dateien manuell prüfen. Meistens ist es Müll. Manchmal sind es aber die letzten Zeilen deines wichtigsten Projekts. Das Arch Wiki bietet hierzu tiefgehende technische Erklärungen, die über die Standard-Handbücher hinausgehen.

Besonderheiten bei SSDs

SSDs funktionieren anders als klassische Festplatten. Hier spielt der TRIM-Befehl eine Rolle. Ein Dateisystemcheck auf einer SSD ist meist schneller, aber die physische Abnutzung der Zellen ist ein Faktor. Wenn fsck ständig Fehler findet, ist oft nicht die Software schuld. Dann stirbt der Flash-Speicher. In so einem Fall hilft keine Reparatur mehr. Dann hilft nur noch der Austausch der Hardware.

Alternative Dateisysteme und ihre Eigenheiten

Nicht jedes System nutzt ext4. Wenn du mit XFS arbeitest, ist fsck fast nutzlos. XFS repariert sich beim Einhängen oft selbst durch das Log-Replay. Wenn das scheitert, brauchst du xfs_repair. Dieses Tool ist extrem mächtig und schnell. Es arbeitet anders als die ext-Tools, da es den gesamten Baum neu aufbaut, anstatt nur Löcher zu flicken.

Das moderne Btrfs

Btrfs ist eine ganz andere Hausnummer. Es nutzt Copy-on-Write. Fehler werden hier oft durch Prüfsummen erkannt, bevor sie Schaden anrichten. Ein herkömmlicher File System Check In Linux ist hier nicht vorgesehen. Stattdessen nutzt man btrfs scrub. Dieser Befehl liest alle Daten im Hintergrund und vergleicht sie mit den Prüfsummen. Wenn du ein RAID-Setup mit Btrfs hast, kann das System defekte Daten sogar automatisch von einer gesunden Platte wiederherstellen. Das ist echte Magie im Alltag eines Administrators.

ZFS unter Linux

ZFS ist zwar nicht Teil des Standard-Kernels, aber bei vielen Profis beliebt. Hier heißt der Vorgang "Resilvering" oder einfach "Scrub". Die Integrität wird auf Blockebene sichergestellt. Wer einmal die Zuverlässigkeit von ZFS erlebt hat, will selten zurück. Dennoch ist die Einrichtung komplexer als bei Standardlösungen. Informationen zur Lizenzierung und Installation findest du direkt bei OpenZFS, dem Projekt hinter der quelloffenen Implementierung.

Automatisierung der Prüfung

Du musst nicht warten, bis das Kind in den Brunnen gefallen ist. Du kannst Prüfungen erzwingen. Früher gab es einen Zähler, der nach 30 Systemstarts einen Check auslöste. Das nervt heute eher, besonders bei großen Servern. Mit tune2fs -c 0 -i 0 /dev/sdX1 schaltest du diese Automatik ab. Aber Vorsicht: Wer die Automatik abschaltet, muss manuell prüfen. Ich empfehle, alle paar Monate einen Check einzuplanen.

Die Datei forcefsck

Ein alter Trick ist das Erstellen einer leeren Datei namens forcefsck im Root-Verzeichnis. Beim nächsten Booten erkennt das System diese Datei und führt eine Prüfung durch. Das funktioniert bei modernen Systemen mit systemd aber nicht mehr immer zuverlässig. Hier nutzt man besser Kernel-Parameter beim Booten. Füge fsck.mode=force in deiner GRUB-Konfiguration hinzu. Das zwingt das System dazu, alles genau unter die Lupe zu nehmen.

Monitoring mit SMART-Werten

Ein Dateisystemcheck repariert nur die logische Struktur. Wenn die Hardware versagt, ist das nur Kosmetik. Nutze smartctl aus dem Paket smartmontools, um den Gesundheitszustand deiner Platte zu prüfen. Wenn die Anzahl der "Reallocated Sectors" steigt, ist die Platte Schrott. Kein Befehl der Welt kann eine physisch zerkratzte Magnetscheibe heilen.

Praktische Beispiele aus der Administration

Stell dir vor, dein Webserver reagiert plötzlich nicht mehr. Du loggst dich per SSH ein und jeder Befehl endet mit "Read-only file system". Jetzt bloß nicht panisch reboot tippen. Zuerst versuchst du, wichtige Konfigurationsdateien zu lesen und wegzusichern. Dann startest du den Server neu in den Single-User-Mode oder das Rettungssystem deines Hosters.

1. Identifiziere die Partition: mount | grep "on / "
2. Versuche sie auszuhängen: umount /dev/vda1
3. Starte die Reparatur: fsck -y /dev/vda1

Oft sind es nur verwaiste Inodes. Das sind Verwaltungsstrukturen, die auf Dateien zeigen, die gar nicht mehr existieren. Das Tool löscht diese Verweise und alles läuft wieder. Das dauert bei einer 500 GB Platte meist nur ein paar Minuten. Bei Terabyte-Platten kann es Stunden dauern. In dieser Zeit darfst du den Prozess niemals abbrechen. Ein Abbruch mitten im Verschieben von Verzeichnisstrukturen ist der sicherste Weg, den Rest deiner Daten auch noch zu vernichten.

Die Rolle von LVM

Wenn du den Logical Volume Manager (LVM) nutzt, wird es eine Ebene komplexer. Du prüfst hier nicht /dev/sdb1, sondern zum Beispiel /dev/mapper/vg0-lv_root. Der Vorteil von LVM ist, dass du Snapshots erstellen kannst. Erstelle einen Snapshot, bevor du eine riskante Reparatur versuchst. Wenn fsck alles schlimmer macht, springst du einfach zum Snapshot zurück. Das ist das Sicherheitsnetz, das jeder Profi nutzt.

Journal-Fehler beheben

Manchmal ist gar nicht das Dateisystem kaputt, sondern nur das Journal. Mit debugfs kannst du tief in die Strukturen schauen. Das ist aber eher etwas für Spezialisten. Für den normalen Gebrauch reicht es oft, das Journal mit tune2fs -O ^has_journal /dev/sdX1 zu entfernen und danach mit -O has_journal wieder hinzuzufügen. Das löscht das alte Tagebuch und legt ein frisches an. Damit verschwinden oft hartnäckige Fehlermeldungen beim Booten.

Verschlüsselte Partitionen

Wenn du LUKS-Verschlüsselung nutzt, musst du zuerst den Container öffnen. Erst dann liegt das Dateisystem offen. Der Befehl cryptsetup open /dev/sdX1 my_temp_drive macht die Daten zugänglich. Danach führst du die Prüfung auf /dev/mapper/my_temp_drive aus. Viele Anfänger versuchen fsck direkt auf der verschlüsselten Partition. Das kann natürlich nicht funktionieren, da das Tool nur verschlüsselten Zeichensalat sieht.

Nächste Schritte für dein System

Du solltest jetzt nicht warten, bis die erste Fehlermeldung aufploppt. Prävention spart Zeit und Nerven. Hier sind die konkreten Schritte, die du jetzt gehen kannst:

• Erstelle ein aktuelles Backup deiner wichtigsten Daten auf einem externen Medium. Ein RAID ist kein Backup.
• Prüfe mit lsblk, wie deine Festplatten strukturiert sind und welche Dateisysteme du nutzt.
• Installiere die smartmontools und schau dir die SMART-Werte deiner Platten an: smartctl -a /dev/sdX.
• Lege dir einen bootfähigen Linux-USB-Stick in die Schublade. Du wirst ihn brauchen, wenn das System nicht mehr startet.
• Schau dir die Logs deines Systems an. Ein einfacher journalctl -p 3 -xb zeigt dir alle schweren Fehler seit dem letzten Bootvorgang.

Wer seine Dateisysteme versteht, verliert weniger Daten. Es geht nicht darum, jeden technischen Parameter auswendig zu kennen. Es geht darum, im Ernstfall ruhig zu bleiben und die richtigen Werkzeuge in der richtigen Reihenfolge einzusetzen. Linux gibt dir alle Macht dazu in die Hand. Du musst sie nur nutzen. Wenn du mehr über die Kernel-Entwicklung und die Implementierung von Dateisystemen erfahren willst, ist die Seite von Kernel.org die erste Adresse für offizielle Dokumentationen. Vertraue auf deine Backups, aber verlasse dich auf deine Fähigkeiten mit der Kommandozeile. Dann haben auch Hardwarefehler keine Chance mehr, deinen Feierabend zu ruinieren. Es gibt kaum ein befriedigenderes Gefühl in der IT, als ein totgeglaubtes System mit ein paar gezielten Befehlen wieder zum Leben zu erwecken. Jedes Mal, wenn fsck eine Reihe von Korrekturen ausgibt und am Ende "FILE SYSTEM WAS MODIFIED" steht, hast du gerade eine digitale Katastrophe verhindert. Bleib wachsam, prüfe regelmäßig und verlass dich nie blind auf die Hardware. Letztlich ist jedes Dateisystem nur so sicher wie die Sorgfalt des Administrators, der es pflegt. Ein regelmäßiger Check gehört dazu wie das Ölwechseln beim Auto. Es ist lästig, aber notwendig für ein langes Leben deiner Daten. Und jetzt schau in deine Logs, ob deine Platten vielleicht schon um Hilfe rufen. Viel Erfolg beim Sichern deiner digitalen Welt. Die Werkzeuge sind da, du musst sie nur anwenden. Ein sauberer Check ist das Fundament für ein stabiles System. Wer hier spart, zahlt später mit Datenverlust. Und das ist ein Preis, den niemand zahlen will. Also, ran an die Konsole und prüf deine Mounts. Es lohnt sich fast immer. Und wer weiß, vielleicht findest du dabei sogar ein paar Gigabyte Platz, die durch alte Temp-Dateien belegt waren. Viel Spaß beim Aufräumen.