Platte voll: finden, was den Speicher frisst

Eine volle Platte legt mehr lahm als man denkt: Datenbanken hören auf zu schreiben, SSH-Anmeldungen scheitern, weil keine Sitzungsdatei angelegt werden kann, und Paketupdates brechen mittendrin ab. Die gute Nachricht: Der Verursacher ist fast immer einer von fünf üblichen Verdächtigen, und du findest ihn in wenigen Minuten.

Erst messen: Platz oder Inodes?#

df -h          # belegter Platz je Dateisystem
df -i          # belegte Inodes (Dateieinträge)

Zwei verschiedene Arten von „voll“. Zeigt df -h 100 %, ist der Platz aufgebraucht. Zeigt df -h noch Luft, aber df -i 100 %, sind die Inodes aufgebraucht: Irgendwo liegen Millionen winziger Dateien, typischerweise Sitzungsdateien, Mail-Warteschlangen oder ein Cache, der nie aufgeräumt wird. Die Suche unten funktioniert für beides, bei Inodes zählst du Dateien statt Größen.

Den Verursacher finden#

# Größte Verzeichnisse auf der Root-Partition, ohne in andere Dateisysteme zu wandern
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -15

# Dann eine Ebene tiefer in den Spitzenreiter
du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -15

Das -x ist wichtig: Ohne es zählt du auch eingehängte Datenträger und /proc mit, und das Ergebnis führt in die Irre.

Bequemer geht es mit ncdu, einer interaktiven Ansicht zum Durchklicken:

apt install ncdu
ncdu -x /

Für Inodes zählst du Dateien je Verzeichnis:

for d in /var/* /home/* /tmp; do echo "$(find "$d" -xdev -type f 2>/dev/null | wc -l) $d"; done | sort -n | tail

Die fünf üblichen Verdächtigen#

Ort	Was dort wächst	Sicher aufräumen
`/var/log/journal`	Systemprotokoll	`journalctl --vacuum-size=500M`
`/var/log/*.log`	Protokolle einzelner Dienste	logrotate prüfen, nicht löschen
`/var/lib/docker`	Images, beendete Container, Build-Cache	`docker system df`, dann gezielt
`/var/cache/apt`	heruntergeladene Pakete	`apt clean`
`/boot`, `/usr/lib/modules`	alte Kernel	`apt autoremove --purge`

Das Journal begrenzen#

journalctl --disk-usage
journalctl --vacuum-size=500M

Damit es nicht wieder wächst, gehört eine Grenze in die Konfiguration:

# /etc/systemd/journald.conf.d/groesse.conf
[Journal]
SystemMaxUse=500M

systemctl restart systemd-journald

Docker aufräumen, ohne Daten zu verlieren#

docker system df                 # wer belegt wie viel
docker image prune -a            # Images, die kein Container nutzt
docker builder prune             # Build-Cache

Nicht blind docker system prune --volumes

Mit --volumes löscht Docker alle Volumes, an denen gerade kein laufender Container hängt. Ist ein Dienst in dem Moment gestoppt, sind seine Daten weg. Volumes nur einzeln und mit Namen entfernen: docker volume ls, dann docker volume rm <name>.

Wachsen einzelne Container-Protokolle, fehlt die Log-Rotation im Docker-Daemon. Wie du die einstellst, steht in Docker im echten Betrieb.

Wenn du nichts findest: drei Sonderfälle#

1. Gelöschte Dateien, die noch offen sind. Löschst du eine große Logdatei, während ein Dienst hineinschreibt, verschwindet der Name, aber der Platz bleibt belegt, bis der Dienst die Datei schließt. du sieht sie nicht mehr, df schon.

lsof +L1 2>/dev/null | head
# oder ohne lsof:
find /proc/*/fd -lname '*(deleted)' -printf '%p -> %l\n' 2>/dev/null | head

Die Lösung ist ein Neustart des betroffenen Dienstes, nicht des ganzen Servers. Merke für nächstes Mal: Eine laufende Logdatei leerst du mit truncate -s 0 datei.log, statt sie zu löschen.

2. Dateien unter einem Einhängepunkt. Lagen Daten in /mnt/backup, bevor dort ein Datenträger eingehängt wurde, sind sie verdeckt, belegen aber weiter Platz auf der Root-Partition. Prüfen lässt sich das, indem du die Root-Partition zusätzlich an einer zweiten Stelle einhängst:

mkdir /tmp/root && mount --bind / /tmp/root
du -sh /tmp/root/mnt/*
umount /tmp/root

3. Reservierte Blöcke. ext4 hält standardmäßig 5 % für root zurück. Normale Benutzer sehen dann „voll“, root hat noch Luft. Das ist gewollt: Es lässt dem System Raum zum Aufräumen. Auf großen Datenpartitionen darf der Anteil kleiner sein (tune2fs -m 1 /dev/…), auf der Root-Partition lass ihn stehen.

Damit es nicht wieder passiert#

Eine volle Platte kündigt sich an. Ein Alarm bei 85 % gibt dir Tage statt Minuten. Wie du das einrichtest, auch ohne großes Monitoring, steht in Monitoring, das dich auch nachts erreicht. Minimal reicht ein Timer:

#!/bin/sh
# /usr/local/bin/platte-pruefen.sh
df -P | awk 'NR>1 && $5+0 > 85 {print $6 " bei " $5}'

Läuft das per systemd-Timer mit OnFailure=-Benachrichtigung, meldet sich der Server, bevor die Datenbank stehen bleibt.

Häufige Fragen#

Kann ich einfach alles in /var/log löschen?#

Nein. Einige Dienste starten nicht, wenn ihre Logdatei oder ihr Verzeichnis fehlt, und du verlierst genau die Protokolle, die erklären würden, warum die Platte voll lief. Erst den Verursacher finden, dann gezielt rotieren oder kürzen.

Die Platte ist voll und ich komme nicht mehr per SSH rein. Was jetzt?#

Über die Konsole deines Anbieters (VNC oder serielle Konsole) anmelden, journalctl --vacuum-size=100M und apt clean schaffen meist genug Luft für alles Weitere. Geht auch das nicht, hilft das Rettungssystem.

Wie viel freien Platz sollte ein Server haben?#

Eine feste Zahl gibt es nicht. Praktisch: genug, um das größte Update und eine lokale Datenbanksicherung gleichzeitig abzulegen. Wer regelmäßig unter 15 % fällt, braucht eine größere Platte oder eine Aufräumregel, keinen weiteren Notfall.

Warum zeigen du und df unterschiedliche Werte?#

Meist wegen einer der drei Sonderfälle oben: offene gelöschte Dateien, verdeckte Dateien unter Einhängepunkten oder reservierte Blöcke. Kleine Abweichungen sind normal, weil du Dateien zählt und df belegte Blöcke.

Kurz gesagt#

df -h für Platz, df -i für Inodes: zwei verschiedene Arten von „voll“.
du -xh --max-depth=1 / oder ncdu -x / finden den Verursacher in Minuten.
Journal, Docker, apt-Cache und alte Kernel sind die üblichen Verdächtigen.
docker system prune --volumes nie blind ausführen.
Nichts gefunden: offene gelöschte Dateien (lsof +L1) prüfen.
Ein Alarm bei 85 % verhindert den nächsten Notfall.