Linux schijf vol: zo vind je wat de ruimte opeet en los je het op

Het klassieke scenario: het is vrijdagmiddag, een klant belt dat de webshop een foutmelding geeft, en in de logs staat No space left on device. Een volle schijf is een van de meest voorkomende oorzaken van serverincidenten, en gelukkig ook een van de makkelijkst op te lossen als je weet waar je moet kijken. Het gevaar zit in haastig opruimen: wie in paniek rm -rf typt, maakt van een klein probleem soms een groot probleem.

Hieronder loop je stap voor stap door de diagnose. Heb je meer algemene problemen, bijvoorbeeld een trage machine? Lees dan ook Linux server traag: oorzaken en oplossingen.

Hoe controleer je de schijfruimte in Linux?

Begin altijd met een overzicht. Het commando df (disk free) laat per bestandssysteem zien hoeveel ruimte er is gebruikt. De optie -h maakt de uitvoer leesbaar met eenheden als GB en MB.

df -h

Kijk naar de kolom Use% en naar de kolom Mounted on. Dat laatste is belangrijk: een server heeft vaak meerdere bestandssystemen, bijvoorbeeld /, /var en /home. Vol zit meestal maar één ervan. Negeer regels met tmpfs of udev; dat zijn virtuele bestandssystemen in het werkgeheugen.

Grote mappen vinden met du

Weet je welk bestandssysteem vol zit, dan zoek je met du (disk usage) uit welke map de ruimte inneemt. De optie -x zorgt dat du binnen één bestandssysteem blijft, zodat je niet per ongeluk andere mounts meetelt.

sudo du -xh --max-depth=1 / | sort -rh | head -15

Zie je bijvoorbeeld dat /var de grootste is, dan duik je daar een niveau dieper in en herhaal je dat totdat je de boosdoener hebt gevonden:

sudo du -xh --max-depth=1 /var | sort -rh | head -10

Sneller met ncdu

Wie dit vaker doet, wil ncdu. Dit is een interactieve variant van du waarmee je met de pijltjestoetsen door mappen navigeert en direct ziet wat het meeste ruimte kost. Op een server met honderden gigabytes bespaart dat veel typwerk.

sudo apt install ncdu
sudo ncdu -x /

Zoek je specifiek naar losse reuzenbestanden, bijvoorbeeld een vergeten database-dump of een core dump? Dan werkt find goed:

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

De klassieke boosdoeners op een Linux-server

In onze ervaring met incidenten komt het bijna altijd neer op dezelfde handvol oorzaken. Loop ze in deze volgorde na.

1. Logbestanden opruimen

Logs in /var/log zijn de nummer één oorzaak. Een applicatie die in een foutloop zit, kan in een paar uur tientallen gigabytes aan regels wegschrijven. Controleer ook het systemd-journal:

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

Voor een los logbestand dat enorm is geworden geldt: verwijder het niet met rm, maar leeg het. Als een proces het bestand open heeft, blijft de ruimte namelijk bezet totdat dat proces stopt (meer hierover verderop). Met truncate komt de ruimte direct vrij:

sudo truncate -s 0 /var/log/applicatie/grote-logfile.log

Zoek daarna uit waarom het log zo groot werd, en controleer of logrotate goed is ingesteld voor die applicatie. Een configuratietest doe je zo:

sudo logrotate --debug /etc/logrotate.conf

2. Pakketcache en oude kernels

Op Debian en Ubuntu bewaart apt gedownloade pakketten in een cache. Daarnaast blijven na elke kernelupdate de oude kernels staan, wat op een kleine /boot-partitie snel tot een volle partitie leidt. Een volle /boot is een bekende reden dat updates halverwege mislukken.

sudo apt clean
sudo apt autoremove --purge

Wil je zeker weten welke kernel je gebruikt en welke er nog staan? Check dat eerst, zodat je nooit de draaiende kernel verwijdert:

uname -r
dpkg --list 'linux-image*' | grep ^ii

Start de server niet opnieuw op voordat je zeker weet dat er een werkende kernel overblijft. Gaat het toch mis, dan helpt ons artikel over een Linux server die niet meer opstart.

3. Docker: images, containers en build cache

Draai je containers, dan zit de ruimte vaak in /var/lib/docker. Ongebruikte images, gestopte containers, volumes en build cache stapelen zich op. Bekijk eerst wat Docker zelf rapporteert:

docker system df
docker system prune
docker builder prune

Let op: docker system prune verwijdert alle gestopte containers, ongebruikte netwerken en dangling images. Draait er een container die tijdelijk gestopt is maar later terug moet komen, dan raak je die kwijt. Voeg je --volumes toe, dan verdwijnen ook ongebruikte volumes, en daar kan data in zitten die je echt nodig hebt. Gebruik die optie dus alleen als je zeker weet wat er in zit.

4. Backups, dumps en tijdelijke bestanden

Een nachtelijke database-dump die nooit wordt opgeruimd, een tar-bestand dat iemand een keer in /tmp heeft gezet of een core dump van een gecrashte applicatie: ze zijn allemaal onschuldig tot de schijf vol raakt. Kijk ook in /var/spool (mail- en printqueues) en /var/crash.

Wat betekent 'No space left on device' terwijl df ruimte toont?

Dit is een van de meest verwarrende situaties: df -h zegt dat er nog 20% vrij is, en toch krijg je de foutmelding. Er zijn vier gangbare verklaringen.

Je inodes zijn op

Elk bestand en elke map gebruikt een inode, een vermelding in de administratie van het bestandssysteem. Het aantal inodes ligt bij het formatteren vast. Heb je miljoenen kleine bestanden, zoals sessiebestanden, mailqueues of cachebestanden, dan raken de inodes op voordat de schijfruimte op is.

df -i

Staat IUse% op 100%? Dan heb je een inode-probleem. Vind de map met de meeste bestanden met dit commando:

sudo find /var -xdev -type f | cut -d/ -f1-3 | sort | uniq -c | sort -rn | head

De oplossing is meestal het opruimen van die ene map met honderdduizenden kleine bestanden, bijvoorbeeld PHP-sessies of een verlopen cache. Voorkom herhaling door een opruimjob in te stellen.

Een verwijderd bestand is nog in gebruik

Verwijder je een bestand dat een proces nog open heeft, dan verdwijnt de naam, maar de data blijft op schijf staan totdat het proces het bestand sluit. Het gevolg: du telt veel minder dan df rapporteert. Zo spoor je ze op:

sudo lsof +L1

Je ziet dan welk proces welk verwijderd bestand vasthoudt. Herstart die service (bijvoorbeeld nginx of de applicatie zelf) en de ruimte komt vrij.

Gereserveerde blokken op ext4

Standaard reserveert ext4 5% van het bestandssysteem voor root. Gewone gebruikers en services die niet als root draaien krijgen dan de foutmelding terwijl df nog ruimte laat zien. Op een grote datapartitie is 5% veel; je kunt dit verlagen.

sudo tune2fs -l /dev/sdb1 | grep -i "reserved block count"

Pas dit alleen aan op partities met data, niet op de rootpartitie, en doe het bewust: die reserve is bedoeld om het systeem bruikbaar te houden als het bijna vol zit.

Je kijkt naar het verkeerde bestandssysteem

Schrijft je applicatie naar /var/lib/mysql en is dat een aparte mount, dan helpt het niets dat / nog ruimte heeft. Controleer met df -h /pad/naar/map welk bestandssysteem echt wordt gebruikt.

Welke bestanden kun je veilig verwijderen op een Linux-server?

Dit is de vraag waar het misgaat. Als vuistregel: ruim op wat opnieuw gegenereerd kan worden, en blijf af van wat data of configuratie is. De tabel hieronder helpt je bij die afweging.

Twijfel je bij een bestand? Verplaats het dan eerst naar een andere schijf of maak er een back-up van voordat je het weggooit. Zeker bij een productieserver is een minuut extra voorzichtigheid goedkoper dan een herstel uit de back-up.

Voorkomen dat je schijf opnieuw vol loopt

Opruimen lost het symptoom op. Wil je dat het niet terugkomt, doe dan minimaal het volgende:

1. Monitor schijfruimte en inodes. Stel een waarschuwing in bij 80% gebruik. Dan heb je dagen of weken om te handelen in plaats van minuten.
2. Check logrotate per applicatie. Eigen applicaties en third-party software krijgen vaak geen rotatieregel en groeien eindeloos.
3. Begrens het journal. Stel SystemMaxUse in via /etc/systemd/journald.conf.
4. Ruim Docker periodiek op en begrens de logs van containers met max-size en max-file.
5. Plan een aparte partitie voor /var of voor data, zodat een uit de hand gelopen log niet het hele systeem platlegt.

Wil je dit niet zelf bijhouden? Met ons SLA as a Service bewaken wij uw schijfruimte, logs en updates, en grijpen we in voordat een klant iets merkt.

Wanneer schakel je beter hulp in?

Veel gevallen los je zelf op met bovenstaande stappen. Maar in een aantal situaties is doorgaan op eigen houtje riskant:

• Je kunt niet meer inloggen omdat de root-partitie 100% vol is en SSH geen sessie meer kan aanmaken.
• Een database is gecrasht of corrupt geraakt doordat de schijf volliep, en MySQL, PostgreSQL of MariaDB start niet meer op.
• De schijfruimte groeit abnormaal snel en je kunt niet verklaren waarom. Dat kan wijzen op een aanval, bijvoorbeeld een server die wordt misbruikt. Lees dan direct wat te doen als je Linux server is gehackt.
• Er spelen LVM, RAID of versleutelde volumes en je moet een bestandssysteem vergroten of herstellen. Een foute stap kan hier data kosten.
• De server draait productie en elke minuut downtime kost omzet.

In die gevallen is snelle, ervaren hulp meestal goedkoper dan zelf experimenteren. Meer over wat betaalde ondersteuning kost en oplevert, lees je in Linux hulp inhuren: wanneer betaalde support loont. Voor een bredere aanpak van problemen is ook ons stappenplan voor Linux troubleshooten handig.