100% schijfgebruik! Hoe ik mijn WordPress-server redde van herhaalde crashes op AWS
De nacht dat mijn server het opgaf
Ik zal het beklemmende gevoel nooit vergeten toen mijn WordPress-sites plotseling offline gingen — weer. Bezoekers werden begroet met blanco pagina's of foutmeldingen. Uptime-monitoringtools begonnen midden in de nacht waarschuwingen af te vuren. Mijn stressniveau schoot omhoog. De boosdoener? Herhaalde servercrashes op AWS, allemaal door één enkel probleem: 100% schijfgebruik.
Als je een WordPress-site (of meerdere) draait op een AWS EC2-instantie en willekeurige downtime, trage prestaties of vreemde fouten opmerkt, zit je misschien op hetzelfde pad als ik. Maar het goede nieuws? Je kunt het oplossen — en voorgoed voorkomen. Hier is mijn echte probleemoplossingstraject.
Wat "100% schijfgebruik" op AWS EC2 betekent (en hoe je het herkent)
Wanneer je Linux-server 100% schijfgebruik bereikt, begint elke dienst — van Nginx/Apache tot MySQL en PHP — te falen. Je ziet mogelijk:
- Websites crashen plotseling of worden onbereikbaar
- WordPress "error establishing a database connection"
- Onmogelijkheid om te SSH'en of basisbewerkingen uit te voeren (zelfs bestanden opslaan mislukt)
- Logs of monitoringtools die "No space left on device" tonen
- AWS CloudWatch die schijfschrijffouten of I/O-fouten toont
Belangrijke tools die ik gebruikte om het probleem te ontdekken:
df -h(toont schijfruimtegebruik in leesbaar formaat)du -sh /*endu -sh /var/*(vindt grote mappen)- AWS EC2 Monitoring & CloudWatch-alarmen
- Foutenlogboeken:
/var/log/syslog,/var/log/messages, Apache/Nginx/MySQL-logs
Pro tip: Als je kunt SSH'en en df -h uitvoeren, en je ziet / of /dev/xvda1 op 100%, heb je het probleem gevonden!
Dieper graven: De echte oorzaak ontdekken
Voor mij eindigde het verhaal niet bij "schijf vol." Ik moest weten waarom. Dit is wat ik ontdekte:
- Back-upbestanden: Oude, geautomatiseerde back-ups stapelden zich op in
/var/www/temp— meer dan 14GB aan .zip- en .tgz-bestanden, die geen van alle meer nodig waren. - WordPress cache en logs: Sommige sites hadden opgeblazen cachemappen en enorme foutenlogboeken.
- Geen opruimproces: Er was geen script of beleid om oude bestanden te verwijderen, dus dezelfde cyclus herhaalde zich elke paar weken.
- Gemiste monitoring: Ik had geen AWS CloudWatch schijfruimte-alarmen ingesteld, dus het probleem bereikte "kritiek" voordat ik het merkte.
Les: Op een multi-site server kunnen zelfs een paar gigabytes aan back-ups of logs je snel naar 100% schijfgebruik duwen.
De oplossing: Hoe ik ruimte vrijmaakte en de crashes stopte
1. Identificeer de schijfvreters
SSH naar je instantie en ontdek wat ruimte opslokt:
df -h
sudo du -h --max-depth=1 / | sort -hr | head -20
sudo du -h --max-depth=1 /var/www | sort -hr | head -20
2. Verwijder ongebruikte back-ups, logs en cache
Ruim de grote boosdoeners op. Voor mij werkten deze commando's wonderbaarlijk:
sudo rm -rf /var/www/temp/*
sudo rm -rf /var/log/*.gz
sudo rm -rf /var/log/*.1
sudo journalctl --vacuum-time=3d
sudo rm -rf /tmp/*
3. Bevestig de vrije ruimte
Controleer altijd opnieuw na het opruimen:
df -h
Het schijfgebruik daalde direct van 100% naar 72% — en de server was weer online.
4. Herstart diensten indien nodig
Soms hebben Apache, Nginx of MySQL een herstart nodig om te herstellen:
sudo systemctl restart nginx
sudo systemctl restart apache2 # (als je Apache gebruikt)
sudo systemctl restart mysql
5. Stel geautomatiseerde back-ups en opruiming in
-
Geautomatiseerde wekelijkse snapshots: Ik heb AWS Data Lifecycle Manager (DLM) ingesteld om wekelijks een EBS-snapshot te maken (en oude automatisch te verwijderen).
-
Regelmatig opruimen: Een eenvoudige cron-job toegevoegd om elke week alles in
/var/www/tempte verwijderen:0 3 * * 0 rm -rf /var/www/temp/* -
CloudWatch-alarmen: CloudWatch-waarschuwingen ingeschakeld voor hoog schijfgebruik — geen onaangename verrassingen meer!
Hoe je 100% schijfgebruik op AWS WordPress-servers voorkomt
Als je WordPress (of een andere webapp) draait op AWS EC2, is dit mijn advies:
- Monitor alles: Stel CloudWatch in om je te waarschuwen wanneer schijfgebruik 75%, 85% en 95% bereikt.
- Automatiseer back-ups — maar roteer ze: Gebruik AWS Lifecycle Manager voor EBS-snapshots en stel een bewaarbeleid in. Verplaats WordPress/database-back-ups naar S3 in plaats van lokaal op te slaan.
- Automatiseer opruiming: Gebruik cron-jobs of scripts om regelmatig temp-, cache- en logbestanden te wissen.
- Schaal indien nodig: Als je sites steeds de schijf ontgroeien, overweeg dan een groter EBS-volume of splits back-ups/media naar S3.
- Controleer plugins en cache: Slecht geconfigureerde back-up- of cacheplugins kunnen schijven snel vullen.
Conclusie: Van chaos naar controle
100% schijfgebruik op AWS kan een nachtmerrie zijn, maar het hoeft je bedrijf niet plat te leggen. Met een paar slimme controles, opruimacties en wat automatisering kun je van constante crashes naar totaal vertrouwen gaan. Mijn WordPress-blogs zijn nu stabiel, geback-upt, en ik slaap 's nachts beter wetende dat AWS achter me staat.
Heb je serverschijfproblemen gehad of wil je je eigen oplossing delen? Laat een reactie of vraag achter — laten we elkaar helpen onze sites online te houden!
