Ist 'docker system prune -a' sicher?

Der Befehl entfernt gestoppte Container, ungenutzte Netzwerke, Build-Cache und alle Images, die kein laufender Container braucht. Ihre Daten bleiben erhalten, solange Sie nicht --volumes anhängen. Damit werden auch ungenutzte Volumes gelöscht — und das Volume eines gestoppten Datenbank-Containers gilt als ungenutzt. Lassen Sie das Flag weg, wenn Sie nicht absolut sicher sind.

Ich habe eine große Logdatei gelöscht, aber df zeigt die Platte immer noch voll. Warum?

Ein laufender Prozess hält die Datei noch offen, deshalb gibt der Kernel den Platz nicht frei. Finden Sie ihn mit 'lsof +L1' und starten Sie den Dienst neu. Leeren Sie aktive Logs künftig mit 'truncate -s 0 datei', statt sie zu löschen.

Wie viel freien Platz sollte ich lassen?

Mindestens 10–15 %. Datenbanken, Paket-Updates und Docker-Pulls brauchen temporären Platz, und eine zu 100 % volle Platte kann eine Datenbank mitten im Schreiben beschädigen.

Kann ich mehr Speicher ohne Neuinstallation bekommen?

Ja. Ein Wechsel auf einen größeren Tarif vergrößert die Platte direkt und behält Ihre Daten — Nano hat 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Der Server startet dabei einmal neu.

Was füllt einen kleinen VPS meistens?

Nach unserer Erfahrung: Docker-Images und Build-Cache, systemd-Journale, Anwendungslogs ohne Rotation und vergessene Datenbank-Dumps oder Archive in /root.

Speicherplatz auf dem VPS freigeben, ohne etwas zu zerstören

VPS-Festplatte voll? Mit du und ncdu finden, was Platz frisst, dann apt-Cache, Journale, Docker-Reste und Logs aufräumen — ohne wichtige Daten zu verlieren.

„No space left on device“ kommt nie zu einem passenden Zeitpunkt. Die Datenbank nimmt keine Schreibvorgänge mehr an, apt kann ein Upgrade nicht abschließen, und Docker weigert sich, genau das Image zu ziehen, das Sie gerade brauchen. Die gute Nachricht: Auf einem kleinen VPS ist der Schuldige fast immer einer von fünf Kandidaten, und Sie finden ihn in zwei Minuten.

1. Wie schlimm ist es?

df -h /
df -i /

Die erste Zeile zeigt den belegten Platz, die zweite die Inodes. Stehen die Inodes bei 100 %, während genug Platz frei scheint, haben Sie Millionen winziger Dateien (Session-Dateien, eine Mail-Queue, ein Cache-Verzeichnis). Anderes Problem, gleiches Symptom.

2. Finden, was groß ist

Vom Wurzelverzeichnis aus durchgehen und nach Größe sortieren:

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

-x bleibt auf einem Dateisystem und läuft nicht in /proc. Danach im größten Verzeichnis weitergraben. Zum interaktiven Stöbern ist ncdu deutlich angenehmer:

apt install -y ncdu
ncdu -x /

Pfeiltasten zum Navigieren, d zum Löschen. Mit Letzterem vorsichtig sein.

3. Die schnellen Erfolge

Das ist auf jedem Ubuntu- oder Debian-Server sicher:

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove räumt auch alte Kernel weg. Das systemd-Journal überrascht die meisten — ohne Grenze wächst es auf mehrere Gigabyte. Um es dauerhaft zu begrenzen, setzen Sie SystemMaxUse=200M in /etc/systemd/journald.conf und führen systemctl restart systemd-journald aus.

4. Docker-Reste

Wenn Sie Docker nutzen, schauen Sie zuerst hier. Alte Images und Build-Cache stapeln sich mit jedem Deploy:

docker system df
docker image prune -a
docker builder prune

docker image prune -a löscht Images, die kein laufender Container verwendet. Meist ist das gewollt, beim nächsten Deploy werden sie eben neu gezogen.

Gefährlich ist docker system prune -a --volumes. Volumes enthalten Ihre Daten, und ein Volume eines gestoppten Containers gilt als ungenutzt. So gehen Datenbanken verloren. Kopieren Sie das nicht aus einer Forenantwort.

Container-Logs sind der zweite versteckte Platzfresser. Begrenzen Sie sie in /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Danach Docker neu starten. Die Grenze gilt nur für Container, die danach erstellt werden, also erzeugen Sie die gesprächigen mit docker compose up -d --force-recreate neu.

5. Logs und vergessene Dateien

Große Dateien auf der ganzen Platte finden:

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

Die üblichen Funde: ein backup.tar.gz von vor einem halben Jahr in /root, ein Datenbank-Dump, den jemand herunterladen wollte, ein App-Log ohne Rotation.

Ein Log, in das ein Dienst noch schreibt, nicht mit rm löschen — leeren:

truncate -s 0 /var/log/myapp/app.log

Wenn Sie schon gelöscht haben und der Platz nicht zurückkam, hält ein Prozess die Datei noch offen:

lsof +L1

Starten Sie den dort gelisteten Dienst neu, und der Platz ist wieder da.

Wenn Aufräumen nicht reicht

Manchmal sind die Daten einfach echt — eine wachsende Datenbank, Uploads von Nutzern, eine Modelldatei. Dann ist die ehrliche Lösung mehr Speicher. Ein Tarifwechsel vergrößert die Platte direkt und behält alles: Nano hat 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Der Server startet einmal neu. Details stehen in der Tarif-Dokumentation.

Noch etwas belegt still Platz: eine Swap-Datei. Wenn Sie unserer Swap-Anleitung gefolgt sind, sind diese 1–2 GB bewusst eingeplant. Und wenn Docker der Hauptverbraucher ist, zeigen die Docker-Installation und das Deployment eines Compose-Stacks, wie Sie den Image-Wildwuchs im Griff behalten.

Die Gewohnheit, die all das verhindert: Begrenzen Sie Journal und Docker-Logs am ersten Tag. Zwei Konfigurationszeilen, und „Platte voll“ passiert kaum noch.