Is 'docker system prune -a' veilig?

Het verwijdert gestopte containers, ongebruikte netwerken, losse build-cache en elke image die geen draaiende container gebruikt. Je data blijft staan, tenzij je --volumes toevoegt. Met --volumes gaan ook ongebruikte volumes weg — en het volume van een gestopte databasecontainer telt als ongebruikt. Laat die vlag weg als je het niet zeker weet.

Ik heb een groot logbestand verwijderd, maar df toont nog steeds een volle schijf. Waarom?

Een draaiend proces heeft het bestand nog open, dus de kernel houdt de ruimte vast. Zoek het met 'lsof +L1' en herstart die service. Maak een actief log de volgende keer leeg met 'truncate -s 0 bestand' in plaats van het te verwijderen.

Hoeveel vrije ruimte moet ik overhouden?

Minstens 10–15%. Databases, pakketupdates en Docker-pulls hebben tijdelijk ruimte nodig, en een schijf op 100% kan een database midden in een schrijfactie beschadigen.

Kan ik schijfruimte bijkrijgen zonder herinstallatie?

Ja. Een upgrade naar een groter plan vergroot de schijf ter plekke en houdt je data — Nano heeft 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. De upgrade herstart de server één keer.

Wat vult een kleine VPS meestal?

In onze ervaring: Docker-images en build-cache, het systemd-journal, applicatielogs die niemand roteert, en vergeten databasedumps of back-uparchieven in /root.

Schijfruimte vrijmaken op een VPS zonder iets kapot te maken

Schijf vol op je VPS? Zoek met du en ncdu uit wat ruimte vreet en ruim apt-cache, journal, Docker-restjes en logs op zonder data te verliezen.

"No space left on device" komt nooit gelegen. De database weigert schrijfacties, apt kan een upgrade niet afmaken en Docker wil precies de image die je nu nodig hebt niet binnenhalen. Het goede nieuws: op een kleine VPS is de boosdoener bijna altijd een van vijf dingen, en je vindt hem in twee minuten.

1. Hoe erg is het?

df -h /
df -i /

De eerste regel toont gebruikte ruimte. De tweede toont inodes — als de inodes op 100% staan terwijl er genoeg ruimte lijkt, heb je miljoenen piepkleine bestanden (sessiebestanden, een mailwachtrij, een cachemap). Ander probleem, zelfde symptoom.

2. Zoek wat groot is

Loop de boom van boven af en sorteer op grootte:

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

-x blijft op één bestandssysteem, zodat hij niet in /proc belandt. Duik daarna in wat het grootst is. Om interactief rond te kijken is ncdu veel prettiger:

apt install -y ncdu
ncdu -x /

Pijltjestoetsen om te navigeren, d om te verwijderen. Wees voorzichtig met die laatste.

3. De snelle winst

Deze zijn veilig op elke Ubuntu- of Debian-server:

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

apt autoremove ruimt ook oude kernels op. Het systemd-journal verrast de meeste mensen — als je het laat begaan, groeit het tot enkele gigabytes. Begrens het voorgoed met SystemMaxUse=200M in /etc/systemd/journald.conf en voer systemctl restart systemd-journald uit.

4. Docker-restjes

Draai je Docker, kijk dan eerst hier. Oude images en build-cache stapelen zich op bij elke deploy:

docker system df
docker image prune -a
docker builder prune

docker image prune -a verwijdert images die geen draaiende container gebruikt. Meestal is dat wat je wilt, maar de volgende deploy haalt ze opnieuw binnen.

De gevaarlijke is docker system prune -a --volumes. Volumes bevatten je data, en een volume aan een gestopte container telt als ongebruikt. Zo raken mensen databases kwijt. Plak dit niet uit een forumantwoord.

De andere verborgen slokop zijn containerlogs. Begrens ze in /etc/docker/daemon.json:

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

Herstart daarna Docker. De limiet geldt alleen voor containers die daarna worden aangemaakt, dus maak de luidruchtige opnieuw aan met docker compose up -d --force-recreate.

5. Logs en vergeten bestanden

Vind grote bestanden overal op de schijf:

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

De gebruikelijke vondsten: een backup.tar.gz van zes maanden geleden in /root, een databasedump die iemand wilde downloaden, een applicatielog dat nooit wordt geroteerd.

Een log waar een service nog naar schrijft, verwijder je niet met rm — je maakt het leeg:

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

Heb je er al een verwijderd en kwam de ruimte niet terug, dan houdt een proces hem nog open:

lsof +L1

Herstart de service die daar staat en de ruimte komt terug.

Als opruimen niet genoeg is

Soms is de data gewoon echt — een groeiende database, uploads van gebruikers, een modelbestand. Dan is de eerlijke oplossing meer schijf. Een upgrade van je plan vergroot de schijf ter plekke en houdt alles: Nano heeft 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. De server herstart één keer. De details staan in de documentatie over plannen.

Nog iets wat stilletjes ruimte eet: een swapbestand. Heb je onze swap-handleiding gevolgd, dan is die 1–2 GB bewust ingeruimd. En als Docker de grootste verbruiker is, laten de Docker-installatiehandleiding en de handleiding voor Compose-stacks zien hoe je de images in toom houdt.

De gewoonte die dit allemaal voorkomt: begrens het journal en de Docker-logs op dag één. Twee regels configuratie, en "schijf vol" gebeurt vrijwel niet meer.