Storage und Dateisysteme: Schichten, Mounts, Kapazität

Ein Dienst schreibt seit Wochen brav nach /srv/data — nur liegt dort gar nicht die Platte, die dafür gekauft wurde, sondern das Wurzeldateisystem, das jetzt langsam vollläuft. Ein anderes System meldet „kein Platz mehr“, obwohl 60 Prozent frei sind. Und ein drittes bootet nach dem Einbau einer zweiten Platte nicht mehr. Drei Fehlerbilder, drei verschiedene Schichten zwischen Platte und Pfad. Dieses Modul zeigt dir, welche Schichten das sind, wie du in einer Zeile feststellst, auf welcher es klemmt, und warum ein größeres Volume noch kein größeres Dateisystem ist.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-03

Zwischen der Platte und deiner Datei liegen vier Schichten

Wenn ein Dienst nach /srv/data schreibt, hat der Weg dorthin mehrere Stationen. Fast jedes Storage-Problem im Betrieb ist die Frage, auf welcher dieser Stationen es klemmt — und die Fehlermeldung nennt fast nie die richtige.

Blockgerät: Die eigentliche Platte oder LUN, etwa /dev/sdb. Kennt nur Blöcke, keine Dateien.
Partition oder Logical Volume: Ein abgegrenzter Bereich darauf. Hier entscheidet sich, wie groß etwas werden kann.
Dateisystem: Die Struktur *im* Bereich: Verzeichnisse, Dateien, Metadaten. Hier entscheidet sich, wie viele Objekte hineinpassen.
Mount: Die Verbindung zwischen Dateisystem und einem Pfad im Verzeichnisbaum. Ohne sie ist das Dateisystem da und trotzdem unerreichbar.

Die vierte Schicht ist die unsichtbarste und deshalb die tückischste: Ein Pfad sieht immer gleich aus, egal ob das erwartete Dateisystem dort hängt oder nicht. lsblk zeigt dir die ersten drei Schichten als Baum, findmnt die vierte.

LVM: warum zwischen Platte und Dateisystem noch eine Schicht liegt

Eine Partition hat einen festen Anfang und ein festes Ende. Wächst der Bedarf, ist das ein Problem — der Platz dahinter gehört meistens schon jemand anderem. Genau dafür gibt es eine Zwischenschicht.

LVM — Logical Volume Management. Physische Datenträger werden zu einem Pool zusammengefasst, aus dem logische Volumes beliebiger Größe geschnitten werden. Ein Volume kann später wachsen, ohne dass die darunterliegenden Platten zusammenhängen müssen.

Physical Volume (PV): Eine Platte oder Partition, die für LVM freigegeben wurde.
Volume Group (VG): Der Pool aus einem oder mehreren PVs. Hier liegt der freie Platz, aus dem verteilt wird.
Logical Volume (LV): Der Bereich, auf dem am Ende ein Dateisystem liegt. Das, was du vergrößerst.

Der Gewinn ist Beweglichkeit: neue Platte dazu, in die Gruppe aufnehmen, ein Volume vergrößern — ohne Umpartitionieren. Der Preis ist eine zusätzliche Schicht, die man verstehen und beim Wiederherstellen mitdenken muss. Wer eine LVM-Platte in ein anderes System steckt, bekommt sie nicht durch bloßes Einhängen zurück.

Auf dem Volume liegt dann ein Dateisystem, und dessen Wahl legt Eigenschaften fest, die du später nur schwer änderst. Zwei Beispiele aus diesem Modul: Bei ext4 steht die Anzahl der Inodes seit dem Anlegen fest, und XFS verlangt zum Vergrößern ausdrücklich ein eingehängtes Dateisystem. Solche Regeln unterscheiden sich je Dateisystem und Version — sie gehören vor der Entscheidung nachgelesen, nicht während des Wartungsfensters.

Der Mount: sechs Felder, die beim Booten zählen

Welche Dateisysteme beim Start eingehängt werden, steht in /etc/fstab. Jede Zeile hat sechs Felder, und drei davon werden regelmäßig unterschätzt.

1 — Quelle: Welches Gerät oder Dateisystem eingehängt wird.
2 — Ziel: Der Pfad, an dem es erscheinen soll.
3 — Typ: Die Art des Dateisystems.
4 — Optionen: Die Mount-Optionen — hier liegen Sicherheitsgrenzen und das Verhalten im Fehlerfall.
5 — dump: Wird von dump ausgewertet. In der Praxis fast immer 0.
6 — pass: Die Reihenfolge der Dateisystemprüfung beim Booten: 1 für die Wurzel, 2 für andere, 0 bedeutet keine Prüfung.

Warum kein Gerätename in Feld 1 gehörtDie Dokumentation ist hier ausdrücklich: Statt eines Gerätenamens sollten UUID= oder LABEL= stehen — das ist die empfohlene Methode, weil Gerätenamen oft nur ein Zufall der Hardware-Erkennungsreihenfolge sind und sich ändern können, sobald andere Platten hinzukommen oder wegfallen. blkid und lsblk zeigen dir die UUID.

Damit ist auch klar, warum ein System nach dem Einbau einer zweiten Platte plötzlich nicht mehr bootet: Aus /dev/sdb1 ist /dev/sdc1 geworden, die Zeile zeigt ins Leere — und der Start bleibt stehen.

Die Option, die dich nicht aussperrt

Ein fehlschlagender Mount ist beim Booten kein kleiner Fehler. Der Start wartet auf das Gerät und läuft in ein Zeitlimit; je nach System landest du in einer Notfall-Eingabeaufforderung statt in einem erreichbaren Server. Bei einem Datenlaufwerk, ohne das der Host durchaus starten könnte, ist das eine unnötig harte Reaktion.

Dagegen gibt es die Option nofail: Sie sorgt dafür, dass für dieses Gerät kein Fehler gemeldet wird, wenn es nicht existiert. Der Host bootet, der Pfad bleibt leer, und du kannst dich anmelden und nachsehen.

Der Preis dieser WahlGenau dieselbe Option macht den Ausfall still. Der Dienst startet, schreibt in ein leeres lokales Verzeichnis und niemand merkt es — bis Wochen später jemand die Daten sucht. nofail gehört deshalb immer mit einer Überwachung des Mount-Zustands zusammen, nicht allein.

Mount-Optionen sind eine Sicherheitsgrenze

Feld 4 ist mehr als eine Formalie. Drei Optionen begrenzen, was auf einem Dateisystem überhaupt möglich ist — unabhängig von den Dateirechten darauf:

noexec: Erlaubt keine direkte Ausführung von Programmen auf diesem Dateisystem.
nosuid: Ignoriert setuid- und setgid-Bits sowie Dateisystem-Capabilities beim Ausführen — ein dort abgelegtes Programm kann keine erhöhten Rechte erlangen.
nodev: Interpretiert keine Geräteknoten auf dem Dateisystem, sperrt also den Umweg über ein selbst mitgebrachtes Blockgerät.
ro: Hängt das Dateisystem schreibgeschützt ein.

Die drei gehören auf jedes Dateisystem, auf das Nutzer oder Anwendungen schreiben dürfen und von dem nichts ausgeführt werden soll — Upload-Verzeichnisse, Datenpartitionen, Wechselmedien. Der Preis ist ehrlich zu nennen: noexec bricht jedes Skript, das dort liegt und aufgerufen werden soll, und das fällt oft erst Monate später auf.

Eine vierte Option betrifft nicht Sicherheit, sondern Last: noatime verhindert, dass bei jedem Lesen die Zugriffszeit im Inode aktualisiert wird — also ein Schreibvorgang für jeden Lesevorgang. Auf Dateisystemen mit vielen kleinen Lesezugriffen ist das spürbar.

Kapazität hat zwei Zahlen, und du siehst meist nur eine

Ein Dateisystem kann aus zwei völlig verschiedenen Gründen „voll“ sein. Datenblöcke halten den Inhalt, Inodes die Metadaten — einen pro Datei, Verzeichnis und Link. Beide sind endlich, und beide werden getrennt gezählt.

df -h zeigt die Blockbelegung, df -i die Inodebelegung. Bei ext4 wird die Anzahl der Inodes beim Anlegen festgelegt und lässt sich später nicht mehr erhöhen — ein Cache mit Millionen winziger Dateien kann ein Dateisystem also an die Wand fahren, während df -h beruhigende 60 Prozent frei meldet.

Die dritte Verwirrung: df und du widersprechen sichdf fragt das Dateisystem, du zählt die Dateien unter einem Pfad. Wenn df voll meldet und du viel weniger findet, fehlt die Differenz irgendwo dazwischen — typischerweise in einer gelöschten Datei, die ein Prozess noch offen hält, oder unter einem Verzeichnis, das von einem darüberliegenden Mount verdeckt wird.

Ein Volume vergrößern — zwei Schichten, zwei Schritte

Der Platz reicht nicht mehr

Szenario

/var/lib/app liegt auf einem Logical Volume und läuft voll. In der Volume Group sind noch 50 GB frei. Der Dienst soll währenddessen weiterlaufen.

Anforderungen

Beide Schichten vergrößern, nicht nur eine
Kein Ausfall, wenn das Dateisystem es zulässt
Hinterher belegen, dass der Platz wirklich angekommen ist

Schritte

Prüfen, wo der Pfad tatsächlich liegt und wie viel Platz die Volume Group noch hat — nicht raten, welches LV gemeint ist.
Das Logical Volume vergrößern. Das allein bringt noch nichts: Darüber liegt weiterhin ein Dateisystem in alter Größe.
Das Dateisystem auf die neue Größe ziehen. lvextend kann das mit der Option -r gleich mit erledigen — sie vergrößert das darunterliegende Dateisystem zusammen mit dem LV.
Mit df -h gegenprüfen. Erst diese Zahl zeigt, ob die Vergrößerung an der Stelle angekommen ist, an der der Dienst sie braucht.

Merksatz: Ein größeres Volume ist kein größeres Dateisystem. Wer nur den ersten Schritt macht, hat Platz gekauft, den niemand benutzen kann.

Vergrößern geht bei den gängigen Dateisystemen im laufenden Betrieb — bei XFS muss das Dateisystem dafür sogar gemountet sein. Beim Verkleinern ist es umgekehrt schwierig bis unmöglich, und die Regeln unterscheiden sich je Dateisystem und Version. Plane deshalb nie damit, dass du eine Vergrößerung später einfach zurücknimmst — prüfe vorher, ob dein Dateisystem das überhaupt kann.

Kurzcheck

Nach einem lvextend um 50 GB meldet df -h für den Pfad unverändert 98 Prozent Belegung. Der Befehl lief fehlerfrei durch. Was ist passiert?

Das Logical Volume ist größer, das Dateisystem darauf nicht — der zweite Schritt fehlt.
Die Vergrößerung wird erst nach einem Neustart oder einem erneuten Einhängen wirksam.
Die Volume Group hatte nicht genug freien Platz, deshalb wurde nur ein Teil zugewiesen.

Treffer. Genau. lvextend arbeitet auf der Volume-Schicht. Das Dateisystem muss separat auf die neue Größe gezogen werden, oder man lässt es über die Option -r gleich mitmachen.

Snapshots sind kein Backup

Ein LVM-Snapshot liefert ein eingefrorenes Abbild eines Volumes: Das Original läuft weiter, während der Snapshot den Stand von vorhin zeigt. Für eine konsistente Sicherung ist das sehr nützlich — man friert ein, sichert in Ruhe vom Snapshot, wirft ihn weg.

Er ist aber kein Ersatz für ein Backup, und zwar aus einem strukturellen Grund: Der Snapshot lebt in derselben Volume Group wie das Original. Fällt die Platte darunter aus, sind beide weg. Ein Backup ist per Definition eine unabhängige Kopie.

Und er ist nicht kostenlosEin Snapshot speichert die Unterschiede zum Original. Je mehr sich seit dem Einfrieren geändert hat, desto mehr Platz braucht er — und der kommt aus derselben Volume Group. Die Dokumentation empfiehlt deshalb ausdrücklich, den Verbrauch zu überwachen und die Größe automatisch nachziehen zu lassen, damit er nicht vollläuft.

Wenn es eng wird: die Reserve und wer sie noch benutzen darf

Ein volles Dateisystem ist selten für alle gleichzeitig voll. Bei den ext-Dateisystemen wird beim Anlegen ein Anteil der Blöcke für den Superuser reserviert — standardmäßig fünf Prozent.

Das hat laut Dokumentation zwei Zwecke: Es vermeidet Fragmentierung, und es erlaubt Diensten, die als root laufen, weiterzuarbeiten, nachdem unprivilegierte Prozesse bereits nicht mehr schreiben dürfen. Genau deshalb kann ein System noch protokollieren und bedienbar bleiben, während die Anwendung schon scheitert.

Was das für die Fehlersuche heißtWenn ein Dienst „kein Platz mehr“ meldet, du dich aber problemlos anmelden und Dateien anlegen kannst, ist das kein Widerspruch — du bist root und benutzt die Reserve. Die Anzeige von df weist diesen Anteil je nach Werkzeug unterschiedlich aus; verlass dich auf das, was der Dienstbenutzer sieht, nicht auf deine eigene Sicht.

Auf reinen Datenvolumes ohne Root-Dienste sind fünf Prozent allerdings verschenkter Platz — bei einem 4-TB-Volume immerhin 200 GB. Der Anteil lässt sich nachträglich anpassen. Der Preis dafür ist genau die Eigenschaft, für die er gedacht war: Wer ihn auf null setzt, verliert den Puffer, der ein volles Dateisystem noch bedienbar hält.

Wo mehrere Nutzer oder Mandanten auf dasselbe Dateisystem schreiben, reicht diese eine Reserve nicht. Dafür gibt es Quotas: Grenzen pro Benutzer, Gruppe oder Projekt — und zwar getrennt für belegten Platz und für die Anzahl der Objekte, weil beides eigene Grenzen sind.

Der Trade-off bei QuotasEine Quota verhindert, dass ein einzelner Verursacher das Dateisystem für alle anderen füllt — der eigentliche Gewinn. Sie verlagert das Problem aber auf die Frage nach der richtigen Zahl: zu eng gesetzt bricht sie den Betrieb an einer Stelle, an der niemand mit einem Limit gerechnet hat, und die Fehlermeldung sieht aus wie ein volles Dateisystem, obwohl reichlich Platz da ist.

Wenn der Pfad nicht das Volume ist

Der stillste Storage-Fehler überhaupt: Ein Verzeichnis existiert, ein Dienst schreibt hinein, alles läuft — nur ist das erwartete Volume gar nicht eingehängt. Die Daten landen auf dem Wurzeldateisystem, das langsam vollläuft, und die eigentliche Platte bleibt leer.

Der Grund, warum das niemand bemerkt: Ein Programm prüft beim Schreiben nicht, wohin es schreibt. Es öffnet einen Pfad, und der funktioniert. findmnt -T <pfad> beantwortet die Frage in einer Zeile — welcher Mount diesen Pfad tatsächlich bedient.

Die Reparatur ist heikler als die DiagnoseEinfach das Volume darüberzuhängen versteckt die inzwischen lokal geschriebenen Daten, statt sie zu retten: Sie liegen weiter darunter und sind nicht mehr sichtbar. Der saubere Weg ist, den Dienst zu stoppen, die lokalen Daten wegzusichern, dann zu mounten und die Daten kontrolliert zurückzuspielen.

Wenn das Dateisystem selbst Fehler meldet

Bei einem schweren Fehler hängen sich viele Dateisysteme selbst schreibgeschützt neu ein. Das sieht aus wie ein Anwendungsproblem — Schreibvorgänge scheitern, obwohl Platz und Rechte stimmen — ist aber eine Schutzreaktion: Lieber nichts mehr schreiben als kaputt schreiben.

Die Konsequenz daraus ist unbequem und wichtig: Eine Dateisystemprüfung läuft nicht auf einem eingehängten, beschreibbaren Dateisystem. Wer es trotzdem versucht, prüft gegen einen Zustand, der sich unter ihm verändert — und kann dabei Schaden anrichten, den es vorher nicht gab. Deshalb hängt man vorher aus, oder man prüft von einem Rettungssystem aus.

Genau dafür ist auch das sechste fstab-Feld da: Es legt fest, in welcher Reihenfolge Dateisysteme beim Booten geprüft werden — die Wurzel zuerst, dann die übrigen. Ein 0 an dieser Stelle bedeutet, dass gar nicht geprüft wird.

Ob ein Dateisystem tatsächlich schreibgeschützt eingehängt ist, siehst du an den aktiven Mount-Optionen — nicht an dem, was in der fstab steht. Die Datei beschreibt die Absicht beim Booten; der laufende Zustand kann davon abweichen, und im Fehlerfall tut er das gerade.

Die Reihenfolge im FehlerfallErst den Grund suchen, nicht die Wirkung wegräumen. Das Kernel-Log nennt den auslösenden Fehler, und der ist fast immer eine Ebene tiefer — ein Lesefehler auf dem Blockgerät, ein ausgefallener Pfad zum Speichersystem. Ein einfaches Wieder-beschreibbar-Einhängen ohne diese Klärung macht den Schutz rückgängig und schreibt weiter auf ein Gerät, das gerade gemeldet hat, dass es nicht mehr zuverlässig ist.

Was danach kommt, hängt vom Befund ab: bei einem Hardwarefehler die Wiederherstellung aus der Sicherung auf gesundem Gerät, bei einer Inkonsistenz die Dateisystemprüfung im ausgehängten Zustand. Beides sind Wartungsfenster — und beides ist der Grund, warum die vorherige Frage „habe ich eine geprüfte Sicherung?“ keine Formalie ist.

Die Reihenfolge bei einem Storage-Problem

Schicht bestimmen: lsblk für Gerät und Volume, findmnt für den Mount→Beide Kapazitätszahlen lesen: df -h und df -i→Bei Widerspruch zwischen df und du nach verdeckten oder offenen Dateien suchen→Erst dann ändern — und die passende Schicht ändern, nicht die sichtbarste→Nach der Änderung am Pfad gegenprüfen, nicht am Volume

Was du mitnehmen solltestVier Sätze tragen dieses Modul. Ein Pfad sieht immer gleich aus — ob das richtige Dateisystem darunter hängt, sagt nur findmnt. Voll hat zwei Bedeutungen — Blöcke und Inodes werden getrennt gezählt. Ein größeres Volume ist kein größeres Dateisystem — das sind zwei Schichten und zwei Schritte. Und ein Snapshot teilt das Schicksal seines Originals — er ist ein Konsistenzwerkzeug, kein Backup.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität14 Primärquellen · zuletzt geprüft: 2026-09-03