Linux-Server Festplatte voll: Diagnose und Lösung

Ist auf einem Linux-Server die Festplatte voll, prüfen Sie zuerst mit df -h und df -i, ob Speicherplatz oder Inodes fehlen. Danach finden Sie mit du und lsof die Verursacher und schaffen gezielt Platz bei Logs, Paket-Caches, alten Kerneln oder gelöschten, aber noch geöffneten Dateien. Erst wenn der Dienst wieder läuft, beheben Sie die eigentliche Ursache und richten eine Überwachung ein, die vor dem nächsten Engpass warnt.

Dieser Ratgeber führt Sie in der Reihenfolge durch die Diagnose, in der Sie sie im Ernstfall brauchen: erst stabilisieren, dann verstehen, dann dauerhaft lösen.

Woran erkennen Sie, dass der Speicher voll ist?

Die eindeutigste Meldung ist No space left on device in Logs oder auf der Konsole. Häufig sehen Sie aber zuerst nur Folgeschäden, die auf den ersten Blick nichts mit Speicherplatz zu tun haben:

Datenbanken stoppen Schreibvorgänge oder starten nicht mehr.
Webanwendungen liefern Fehler 500, weil Sessions oder Cache-Dateien nicht geschrieben werden können.
Mailserver stauen Nachrichten in der Warteschlange.
Paketupdates brechen mitten im Vorgang ab.
SSH-Logins dauern lange oder Tab-Vervollständigung in der Shell schlägt fehl.

Sobald mehrere Dienste gleichzeitig seltsam reagieren, lohnt der Blick auf den Füllstand vor jeder anderen Fehlersuche.

Linux-Server Festplatte voll: Speicherplatz oder Inodes?

Ein Dateisystem kann auf zwei Arten volllaufen. Entweder sind die Datenblöcke belegt, oder es gibt keine freien Inodes mehr. Jede Datei, jedes Verzeichnis und jeder Symlink verbraucht genau einen Inode. Millionen kleiner Dateien können ein Dateisystem also unbenutzbar machen, obwohl df -h noch freien Platz anzeigt.

df -h          # belegter Speicher je Dateisystem
df -i          # belegte Inodes je Dateisystem
lsblk -f       # welche Partition ist wo eingehängt

Achten Sie auf die Spalte Use% bzw. IUse%. Notieren Sie, welches Dateisystem betroffen ist. Ist es nicht die Root-Partition, sondern etwa /var oder ein separates Datenvolume, grenzt das die Suche bereits stark ein.

Welche Verzeichnisse belegen den Platz?

Für die Suche nach großen Verzeichnissen genügen Bordmittel. Die Option -x sorgt dafür, dass du auf dem betroffenen Dateisystem bleibt und nicht in eingehängte Netzlaufwerke oder andere Partitionen wandert.

du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -n 15
du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -n 15

Arbeiten Sie sich so Ebene für Ebene vor. Einzelne große Dateien finden Sie direkt:

find / -xdev -type f -size +500M -exec ls -lh {} \; 2>/dev/null

Fehlen Inodes, suchen Sie stattdessen nach Verzeichnissen mit sehr vielen Einträgen:

du --inodes -x --max-depth=1 /var 2>/dev/null | sort -n | tail -n 10

Typische Treffer bei Inode-Mangel sind PHP-Session-Verzeichnisse, Cache-Ordner von Anwendungen, Mail-Warteschlangen oder Verzeichnisse mit Thumbnails. Steht das Werkzeug ncdu zur Verfügung, bietet es eine interaktive Übersicht, ist im Notfall aber nicht nötig.

Platz freigeben, ohne etwas kaputtzumachen

Löschen Sie nie blind: Stellen Sie erst fest, ob Blöcke oder Inodes fehlen und welcher Prozess schreibt, schaffen Sie dann gezielt Platz und stellen Sie anschließend die Ursache ab. Die folgenden Schritte sind nach Risiko sortiert, die ungefährlichsten zuerst.

Systemjournal begrenzen. Prüfen Sie mit journalctl --disk-usage die Größe und kürzen Sie mit journalctl --vacuum-size=500M oder journalctl --vacuum-time=14d.
Paket-Caches leeren. Auf Debian und Ubuntu apt-get clean, auf RHEL-Derivaten dnf clean all. Die Pakete werden bei Bedarf neu geladen.
Alte Kernel und verwaiste Pakete entfernen. Mit apt-get autoremove --purge bzw. dnf autoremove. Der laufende Kernel bleibt dabei erhalten, prüfen Sie ihn trotzdem vorher mit uname -r.
Rotierte und komprimierte Logs prüfen. Alte Archive wie *.log.5.gz unter /var/log lassen sich meist entfernen, sofern Sie sie nicht für Nachweise oder Auswertungen brauchen.
Container-Altlasten aufräumen. docker system df zeigt die Belegung, docker system prune entfernt gestoppte Container, ungenutzte Netzwerke und hängende Images. Volumes bleiben ohne den Zusatz --volumes unangetastet, und das sollte im Zweifel auch so bleiben.
Lokale Sicherungen und Dumps auslagern. Alte Datenbank-Dumps oder Archivdateien im Home- oder Backup-Verzeichnis sind häufige Platzfresser. Verschieben Sie sie auf einen anderen Speicher, bevor Sie sie löschen.

Gelöschte Dateien, die weiter Platz belegen

Ein klassischer Stolperstein: Sie löschen eine große Logdatei, aber df zeigt keinen Gewinn. Der Grund sind gelöschte, aber geöffnete Dateien. Solange ein Prozess die Datei offen hält, gibt der Kernel den Platz nicht frei.

lsof +L1 2>/dev/null | sort -k7 -n | tail

Die Ausgabe nennt Prozess, PID und Dateideskriptor. Am saubersten ist ein Neustart oder Reload des Dienstes. Ist das gerade nicht möglich, leeren Sie die Datei über den Deskriptor:

: > /proc/1234/fd/7

Für die Zukunft gilt: Große, aktive Logdateien nicht mit rm entfernen, sondern mit truncate -s 0 /pfad/zur/datei.log leeren. So bleibt die Datei für den schreibenden Prozess gültig.

Reservierte Blöcke bei ext4

ext4 hält standardmäßig fünf Prozent der Blöcke für root zurück. Deshalb kann ein Dateisystem für normale Nutzer voll sein, während root noch schreiben darf. Den Wert sehen Sie mit:

tune2fs -l /dev/sdb1 | grep -i reserved

Auf reinen Datenpartitionen lässt sich die Reserve mit tune2fs -m 1 /dev/sdb1 verkleinern. Auf der Root-Partition sollten Sie die Reserve nicht antasten, denn sie hält das System im Notfall bedienbar.

Was Sie auf keinen Fall einfach löschen sollten

Unter Zeitdruck sind manche Verzeichnisse verlockend groß. Einige davon führen beim direkten Löschen zu größeren Schäden als der volle Speicher selbst:

Datenbankverzeichnisse wie /var/lib/mysql oder /var/lib/postgresql. Binärlogs von MySQL oder MariaDB entfernen Sie über die Datenbank, etwa mit PURGE BINARY LOGS BEFORE NOW() - INTERVAL 3 DAY;, und nie per rm.
PostgreSQL-WAL-Dateien in pg_wal. Wachsen sie unkontrolliert, hängt oft ein Replikationsslot oder die WAL-Archivierung schlägt fehl. Prüfen Sie pg_replication_slots, statt Dateien zu entfernen.
/var/lib/docker von Hand. Nutzen Sie ausschließlich die Docker-Befehle, sonst sind Images und Volumes inkonsistent.
/boot ohne Paketmanager. Kernel werden über den Paketmanager entfernt, sonst stimmt die Bootkonfiguration nicht mehr.

Typische Ursachen und wie Sie sie dauerhaft abstellen

Platz zu schaffen verschafft nur Zeit. Wenn Sie die Ursache nicht beheben, läuft das Dateisystem wieder voll, oft in einem ungünstigeren Moment. Die häufigsten Muster:

Logs ohne Rotation

Eigene Anwendungen schreiben gern in Verzeichnisse, die keine Logrotation kennen. Eine Konfiguration unter /etc/logrotate.d/meineapp löst das:

/var/log/meineapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

Begrenzen Sie zusätzlich das Systemjournal dauerhaft mit SystemMaxUse=500M in /etc/systemd/journald.conf und anschließendem systemctl restart systemd-journald. Wenn Sie Logs ohnehin länger aufbewahren müssen, gehören sie nicht auf den Anwendungsserver, sondern an eine zentrale Stelle. Wie das aussieht, beschreibt der Beitrag zum zentralen Logging im Serverbetrieb.

Datenbank-Logs ohne Ablaufzeit

Binärlogs und WAL-Dateien wachsen mit jeder Schreiboperation. Setzen Sie eine Ablaufzeit, etwa binlog_expire_logs_seconds in MySQL 8 oder den entsprechenden Parameter Ihrer MariaDB-Version, und überwachen Sie Replikationsslots in PostgreSQL.

Sicherungen auf derselben Platte

Lokale Dumps sind praktisch, aber sie verbrauchen genau den Speicher, den die Produktion braucht, und schützen nicht vor einem Plattenausfall. Lassen Sie lokal höchstens die letzte Sicherung liegen und übertragen Sie alles Weitere auf ein getrenntes System.

Kleine Dateien ohne Aufräumjob

Session-Dateien, Cache-Einträge und temporäre Uploads verbrauchen wenig Speicher, aber viele Inodes. Prüfen Sie, ob die Garbage Collection der Anwendung tatsächlich läuft, oder ergänzen Sie einen Systemd-Timer bzw. Cronjob, der Dateien älter als einen definierten Zeitraum entfernt, zum Beispiel mit find /var/lib/php/sessions -type f -mmin +1440 -delete.

Wie Sie den nächsten Engpass rechtzeitig erkennen

Ein voller Speicher ist fast nie ein plötzliches Ereignis, sondern das Ende eines Verlaufs, den niemand beobachtet hat. Zwei Arten von Alarmen haben sich in der Praxis bewährt:

Feste Schwellen als Grundabsicherung: eine Warnung ab etwa 80 Prozent Belegung, ein kritischer Alarm ab etwa 90 Prozent. Dasselbe gilt für Inodes, die viele Setups vergessen.
Prognose auf Basis der Wachstumsrate: Ein Volume mit 70 Prozent Belegung, das täglich zwei Prozent wächst, ist dringlicher als eines mit 88 Prozent, das seit Monaten stabil ist.

Wer Prometheus mit dem node_exporter einsetzt, kann die Prognose direkt als Alarmregel formulieren:

predict_linear(node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"}[6h], 24 * 3600) < 0

Die Regel schlägt an, wenn das Dateisystem bei gleichbleibendem Trend innerhalb von 24 Stunden voll wäre. Ob Sie eine solche Überwachung selbst betreiben oder als Dienst nutzen, ist eine eigene Abwägung. Den Aufwand dahinter beleuchtet der Beitrag Server Monitoring selbst hosten oder als Service.

Wann ist Erweitern die richtige Antwort?

Nicht jeder volle Datenträger ist ein Aufräumproblem. Wächst der Datenbestand durch das normale Geschäft, etwa durch mehr Kunden, Dokumente oder Transaktionen, ist mehr Speicher die sachlich richtige Lösung. Unterscheiden Sie deshalb nach der Bereinigung zwischen Müll, der nicht hätte entstehen dürfen, und Nutzdaten, die zu Recht wachsen.

Für die zweite Gruppe hilft eine Kapazitätsplanung, die den Verlauf der letzten Monate fortschreibt und rechtzeitig Erweiterungen einplant. Die Methodik dazu finden Sie im Beitrag Server richtig dimensionieren. Bewährt hat sich außerdem, Betriebssystem und wachsende Daten auf getrennte Volumes zu legen. Läuft dann das Datenvolume voll, bleibt das System selbst bedienbar und Sie können in Ruhe reagieren.

Betrieb selbst übernehmen oder abgeben

Alle beschriebenen Schritte lassen sich mit Bordmitteln umsetzen. Entscheidend ist, dass jemand die Alarme empfängt, die Ursachen nachhält und Rotations- und Aufräumregeln pflegt, wenn neue Anwendungen hinzukommen. In kleinen IT-Teams fällt genau diese Daueraufgabe oft zwischen die Zuständigkeiten.

Eine Möglichkeit ist, den Betrieb an einen Dienstleister zu übergeben. NETARO bietet zum Beispiel Cloud Server in Frankfurt wahlweise selbst verwaltet oder als Managed-Variante an, bei der Härtung, Updates, Backups und 24/7-Monitoring übernommen werden. Was im Managed Hosting zum laufenden Betrieb gehört, ist dort beschrieben. Ob sich das lohnt, hängt davon ab, wie viel Betriebswissen und Bereitschaft Sie im eigenen Haus vorhalten wollen.

FAQ

Warum zeigt df einen vollen Speicher, du aber deutlich weniger?

Meist hält ein Prozess gelöschte Dateien noch geöffnet. Mit lsof +L1 finden Sie diese Dateien, ein Neustart des betroffenen Dienstes gibt den Platz frei. Seltener liegen Daten unter einem Mountpoint verborgen, die vor dem Einhängen eines anderen Dateisystems geschrieben wurden.

Was bedeutet No space left on device, obwohl noch Platz frei ist?

In diesem Fall sind in der Regel die Inodes erschöpft. Prüfen Sie mit df -i und suchen Sie mit du --inodes nach Verzeichnissen mit sehr vielen kleinen Dateien, etwa Sessions oder Cache-Einträgen.

Kann ich Dateien in /var/log einfach löschen?

Rotierte und komprimierte Archive können Sie in der Regel löschen, wenn Sie sie nicht für Nachweise benötigen. Aktive Logdateien sollten Sie mit truncate -s 0 leeren statt zu löschen, damit schreibende Prozesse den Platz tatsächlich freigeben.

Ab welcher Belegung sollte ein Alarm auslösen?

Als Ausgangspunkt bewähren sich eine Warnung ab etwa 80 Prozent und ein kritischer Alarm ab etwa 90 Prozent, jeweils für Speicher und Inodes. Ergänzen Sie eine Prognose auf Basis der Wachstumsrate, damit schnell wachsende Volumes früher auffallen.

Linux-Server: Festplatte voll? Ursachen finden, sicher Platz schaffen und den nächsten Engpass verhindern