Dateisystemspeicher auf einem Debian Home-Server - Bloecke, Inodes und versteckte offene Dateien diagnostizieren

Geschrieben von Adam Muiz 14 Sep 2026 Aktualisiert: 14 Sep 2026 10 Min. gelesen

Ein Dienst kann keine weiteren Daten in seine Datenbank schreiben, ein Backup bricht mittendrin ab oder eine Anwendung protokolliert No space left on device. Die naheliegende Erklärung lautet: Der Datenträger ist voll. Das kann stimmen, ist aber noch keine brauchbare Diagnose. Welches eingehängte Dateisystem ist betroffen? Sind Datenblöcke oder Inodes erschöpft? Hält ein laufender Prozess noch eine gelöschte Datei offen? Oder wird der Fehler tatsächlich durch ein Kontingent oder ein schreibgeschütztes Dateisystem verursacht?

Eine gute Reaktion sollte diese Fragen beantworten, bevor irgendetwas gelöscht wird. Auf einem Home-Server ähnelt die sicherste Reihenfolge eher der Suche nach einem undichten Rohr als dem wahllosen Leeren von Schränken: den Druck lokalisieren, den weiteren Zufluss stoppen, anhand einer Richtlinie bestimmen, was entfernt werden darf, und anschließend prüfen, ob die abhängigen Dienste weiterhin funktionieren.

„No space left“ ist ein Symptom, keine vollständige Diagnose

Auf der Ebene der Systemaufrufe kann Linux ENOSPC zurückgeben, wenn das Gerät, auf dem sich eine Datei befindet, keinen Platz für weitere Daten hat. Das Linux-Handbuch zu write(2) unterscheidet davon EDQUOT: Das Kontingent eines Benutzers für Dateisystemblöcke ist erschöpft. Anwendungen vereinfachen solche Fehler häufig in ihren Protokollen. Deshalb sollte die Untersuchung mit den Belegen auf dem Host beginnen und nicht allein mit dem Wortlaut der Meldung.

Kapazität gehört außerdem zu einem Dateisystem und nicht einfach „zur Festplatte“. Auf einem Server kann ein eingehängtes Dateisystem freien Platz haben, während /var, ein Datenbank-Volume oder ein Backup-Mount voll ist. Ein Schreibvorgang kann deshalb scheitern, obwohl auf einem anderen Gerät noch Hunderte Gigabyte verfügbar sind.

Mindestens drei Kapazitätsfragen sollten getrennt betrachtet werden:

Blöcke: Hat das Dateisystem keinen Platz mehr für Dateidaten und Metadaten?
Inodes: Kann das Dateisystem noch eine weitere Datei oder einen weiteren Verzeichniseintrag anlegen?
Weiterhin referenzierter Platz: Wurde eine Datei aus ihrem Verzeichnis entfernt, während ein Prozess sie weiterhin offen hält?

Für eine Anwendung können diese Fälle ähnlich aussehen, sie erfordern jedoch unterschiedliche Maßnahmen.

Mit dem betroffenen Dateisystem beginnen

Die GNU-Coreutils-Dokumentation zu df beschreibt das Werkzeug als Bericht über belegten und verfügbaren Platz auf Dateisystemen. Übergeben Sie den Pfad, bei dem der Fehler aufgetreten ist, statt automatisch das Root-Dateisystem verantwortlich zu machen:

df -h /path/that/failed
df -T /path/that/failed
df -i /path/that/failed

Der erste Befehl zeigt die Blockkapazität des Dateisystems, das den Pfad enthält, in menschenlesbarer Form. Der zweite ergänzt den Dateisystemtyp. Der dritte ersetzt die Blockstatistik durch eine Inode-Statistik. Notieren Sie das Quellgerät und den Mountpoint; die weitere Untersuchung sollte auf dieses Dateisystem begrenzt bleiben.

Menschenlesbare Ausgabe ist für eine Person praktisch, Skripte sollten jedoch explizite Felder oder stabile Einheiten anfordern. Vor allem ist ein angezeigter Prozentwert nicht die ganze Geschichte. Der für einen unprivilegierten Dienst verfügbare Platz kann von einer einfachen Rechnung aus Gesamtkapazität minus Nutzung abweichen, und Dateisysteme besitzen eigene Details für Zuweisung und Reservierung.

Inodes prüfen, auch wenn noch Bytes verfügbar sind

Ein Inode speichert Informationen über ein Dateisystemobjekt, darunter Metadaten und den Ort seiner Daten. Ein Workload, der sehr viele kleine Cache-Dateien, Sitzungen, Queue-Einträge oder entpackte Paketdateien erzeugt, kann die verfügbaren Inodes verbrauchen, bevor die Bytes ausgehen. In diesem Fall kann das Löschen eines großen Archivs zwar Blöcke freigeben, aber den eigentlichen Engpass nicht beheben.

Wenn df -i auf Inode-Druck hinweist, kann GNU du abschätzen, welche Verzeichnisbäume besonders viele Dateisystemobjekte enthalten:

sudo du --inodes -x --max-depth=1 /affected/mount
sudo du --inodes -x --max-depth=1 /affected/mount/suspect-directory

Laut dem GNU-Handbuch zu du meldet --inodes die Inode-Nutzung anstelle der Blocknutzung, während -x die Traversierung auf ein Dateisystem beschränkt. Wiederholen Sie den zweiten Befehl nur für ein Verzeichnis, das eine genauere Untersuchung verdient. Eine hohe Anzahl zeigt, wo gesucht werden sollte; sie entscheidet nicht, was sicher gelöscht werden darf.

`du` zum Auffinden von Wachstum nutzen, nicht als Ersatz für `df`

Wenn Blöcke knapp werden, untersuchen Sie die oberste Ebene des betroffenen Mounts:

sudo du -x -h --max-depth=1 /affected/mount
sudo du -x -h --max-depth=1 /affected/mount/suspect-directory

df und du beantworten unterschiedliche Fragen. df meldet die Zuweisung auf Dateisystemebene. du schätzt den Platz, der durch erreichbare Dateien im ausgewählten Verzeichnisbaum repräsentiert wird. Ihre Summen müssen nicht genau übereinstimmen.

Eine Abweichung kann normal sein. Berechtigungen können verhindern, dass ein Benutzer Teile eines Baums sieht. Hardlinks, Sparse-Dateien, Copy-on-Write-Speicher, Kompression, verschachtelte Mounts und Dateisystemmetadaten erschweren die Bilanzierung. Deshalb verwenden die obigen Befehle sudo für bessere Sichtbarkeit und -x, damit nicht unbemerkt ein anderes eingehängtes Dateisystem durchsucht wird. Dennoch bleibt du eine Schätzung.

Eine große Differenz kann zugleich ein wertvoller Hinweis sein. Wenn df eine hohe Belegung des Dateisystems meldet, die von du gemeldeten erreichbaren Dateien aber wesentlich weniger erklären, sollte nach gelöschten Dateien gesucht werden, die noch offen sind.

Gelöschte Dateien finden, die ein Prozess noch offen hält

Auf Unix-ähnlichen Systemen gibt das Entfernen eines Pfadnamens den zugrunde liegenden Speicher nicht unbedingt sofort frei. Solange ein Prozess die Datei offen hält, kann er sie weiter verwenden, bis der Dateideskriptor geschlossen wird. Das ist häufig relevant, wenn eine Protokolldatei manuell entfernt wurde, ihr Dienst aber weiter hineinschreibt.

sudo lsof +L1

Das lsof(8)-Handbuch erklärt, dass +L1 offene Dateien mit einer Link-Anzahl kleiner als eins auswählt, also offene Dateien, deren Verknüpfung aufgehoben wurde. Ausreichende Berechtigungen sind wichtig, weil eine eingeschränkte Ansicht Dateien anderer Prozesse auslassen kann.

Lesen Sie Prozessname, PID, Dateideskriptor, Größe und Pfad, bevor Sie handeln. Beenden Sie nicht jeden aufgelisteten Prozess. Ein kontrollierter Neustart des konkret zuständigen Dienstes kann den Deskriptor schließen und den Platz freigeben, hat jedoch ebenfalls betriebliche Folgen. Prüfen Sie zuvor die Dokumentation des Dienstes, laufende Aufgaben und seine Neustartrichtlinie. Bei einer Datenbank oder einem anderen zustandsbehafteten Dienst ist die Integrität wichtiger, als den Speicher wenige Sekunden früher zurückzugewinnen.

Wahrscheinliche Erzeuger untersuchen, bevor sie bereinigt werden

Die Größe eines Verzeichnisses ist nur der Anfang der Frage. Als Nächstes ist zu klären, warum es gewachsen ist. Häufige Erzeuger sind Anwendungsprotokolle, System-Journale, Caches, temporäre Exporte, Upload-Staging-Bereiche, Datenbankdateien, Container-Layer und Backups. Jeder davon besitzt einen anderen Eigentümer und eine andere Aufbewahrungsrichtlinie. Ein allgemeiner rm-Befehl kann nicht wissen, welche Daten entbehrlich sind.

Bei systemd-Journalen ist die Untersuchung einfach:

journalctl --disk-usage

Die journalctl(1)-Dokumentation erläutert, dass diese Summe aktive und archivierte Journaldateien umfasst. Die Vacuum-Operationen entfernen archivierte, aber keine aktiven Journale. Ein angefordertes Vacuum-Limit garantiert daher nicht, dass die angezeigte Summe exakt auf diesen Wert sinkt. Bewusst konfigurierte Aufbewahrung und der unterstützte Bereinigungsmechanismus eines Dienstes sind einer manuellen Notfalllöschung vorzuziehen.

Erfassen Sie vor der Bereinigung genug Kontext, um den Vorfall später erklären zu können: betroffener Mount, verfügbare Blöcke und Inodes, größte relevante Verzeichnisse, wachsender Prozess und aktuelle Dienstfehler. Stoppen oder begrenzen Sie anschließend den Erzeuger, falls er weiterhin Daten produziert. Eine Bereinigung, während ein unkontrollierter Prozess weiter schreibt, verschafft nur eine unbekannte Menge Zeit.

Eine vorsichtige Reihenfolge für die Wiederherstellung

Fehlgeschlagenen Pfad und Fehler bestätigen. Diagnostizieren Sie nicht einen anderen Mount, nur weil er leichter zu untersuchen ist.
Blöcke und Inodes messen. Speichern Sie die relevante df-Ausgabe und notieren Sie den Mountpoint.
Verantwortlichen Baum oder versteckte Referenz lokalisieren. Verwenden Sie begrenzte du-Durchläufe und lsof +L1; beginnen Sie nicht mit einer serverweiten Suche nach Löschkandidaten.
Wachstum stoppen. Pausieren Sie den fehlgeschlagenen Job, begrenzen Sie eingehende Arbeit oder führen Sie gegebenenfalls eine kontrollierte Dienstaktion aus.
Nach Zuständigkeit und Richtlinie bereinigen. Nutzen Sie die Aufbewahrungsfunktion der Anwendung, Logrotation, Cache-Verwaltung oder eine etablierte Backup-Richtlinie.
Erneut messen und testen. Prüfen Sie die verfügbaren Blöcke und Inodes erneut und testen Sie anschließend den ausgefallenen sowie jeden neu gestarteten Dienst.
Wiederholung verhindern. Passen Sie Aufbewahrung, Kapazität, Workload-Verhalten oder Alarmierung an die ermittelte Ursache an.

Diese Reihenfolge trennt Diagnose bewusst von Löschung. Wenn die Dateien Belege für einen außer Kontrolle geratenen Job oder einen Sicherheitsvorfall sind, kann eine vorschnelle Löschung die Erklärung beseitigen. Handelt es sich um das einzige aktuelle Backup, kann das Freigeben von Platz ein größeres Risiko als der ursprüngliche Ausfall erzeugen.

Bytes und Inodes überwachen

Regelmäßige Prüfungen sollten beide Dimensionen abdecken. Der Prometheus-Leitfaden zum Node Exporter dokumentiert beispielsweise Dateisystemmetriken einschließlich des für Nicht-Root-Benutzer verfügbaren Platzes. Andere Monitoring-Systeme können entsprechende Werte erfassen.

Es gibt keinen seriösen universellen Warnprozentsatz. Ein langsam wachsendes Archiv und eine stark beschäftigte Datenbank benötigen unterschiedliche Reserven. Zehn Prozent können auf einem Volume Monate und auf einem anderen nur Minuten bedeuten. Eine bessere Richtlinie berücksichtigt mindestens die Wachstumsrate, die Reaktionszeit eines Menschen, den größten erwarteten Vorgang und die Vertrauenswürdigkeit einer automatischen Bereinigung.

Die Prometheus-Empfehlungen raten zu handlungsorientierten Alarmen, Spielraum für kleine Ausschläge und einer Behandlung nahender Kapazitätsgrenzen als möglichen Interventionsbedarf. Ein Alarm sollte deshalb Instanz und Mount nennen, zwischen Byte- und Inode-Druck unterscheiden und auf ein kurzes Runbook verweisen. Ein Alarm, der nur „disk high“ meldet, erzwingt im ungünstigsten Moment Vermutungen.

Erkennen, wann dieses Runbook nicht ausreicht

Kapazität ist nicht der einzige Grund für fehlgeschlagene Schreibvorgänge. Ein Kontingent kann erschöpft sein, obwohl das Dateisystem noch Platz hat. Ein Dateisystem kann nach Fehlern schreibgeschützt neu eingehängt werden. Berechtigungen, Dateigrößenbeschränkungen, Speicherfehler und das Verhalten von Netzwerkdateisystemen können andere Meldungen erzeugen. Der genaue Fehler in Anwendung und System-Journal bleibt wichtig.

Dateisystemspezifische Werkzeuge können außerdem Details melden, die allgemeine Coreutils nicht erklären. Wenn df, du und die Prüfung offener Dateien die Beobachtungen nicht in Einklang bringen, sollte keine einfache Antwort erzwungen werden. Bewahren Sie die Belege auf und konsultieren Sie die Dokumentation des jeweiligen Dateisystems und der Speicherschicht.

Fazit

„No space left“ ist der Beginn einer Untersuchung. Lokalisieren Sie zuerst das betroffene Dateisystem, trennen Sie dann Block- von Inode-Druck, vergleichen Sie die Dateisystembilanz mit dem erreichbaren Dateibaum und prüfen Sie, ob ein Prozess gelöschte Dateien festhält. Erst nachdem die Zuständigkeit ermittelt wurde, sollte die Bereinigung beginnen.

Die tiefere Lektion ist kein bestimmter Befehl. Kapazitätsmanagement funktioniert, wenn Beobachtung, Zuständigkeit, Aufbewahrung und Alarmierung einen Kreislauf bilden. Die hilfreiche Frage lautet nicht nur „Was kann jetzt gelöscht werden?“, sondern „Was ist gewachsen, warum blieb keine Zeit zum Reagieren und welche Belege würden die nächste Reaktion ruhiger machen?“