100% d'utilisation du disque ! Comment j'ai sauvé mon serveur WordPress de crashes répétés sur AWS
La nuit où mon serveur a lâché
Je n'oublierai jamais la sensation d'angoisse en voyant mes sites WordPress tomber soudainement hors ligne — encore une fois. Les visiteurs étaient accueillis par des pages blanches ou des messages d'erreur. Les outils de surveillance de disponibilité ont commencé à déclencher des alertes en pleine nuit. Mon niveau de stress a grimpé en flèche. Le coupable ? Des crashes serveur répétés sur AWS, tous à cause d'un seul problème : 100% d'utilisation du disque.
Si vous gérez un site WordPress (ou plusieurs) sur une instance AWS EC2 et remarquez des temps d'arrêt aléatoires, des performances lentes ou des erreurs étranges, vous êtes peut-être sur le même chemin que moi. Mais la bonne nouvelle ? Vous pouvez le résoudre — et le prévenir définitivement. Voici mon parcours réel de dépannage.
Ce que signifie "100% d'utilisation du disque" sur AWS EC2 (et comment le détecter)
Lorsque votre serveur Linux atteint 100% d'utilisation du disque, chaque service — de Nginx/Apache à MySQL et PHP — commence à échouer. Vous pourriez voir :
- Les sites web crashent soudainement ou deviennent inaccessibles
- WordPress "error establishing a database connection"
- Impossibilité d'utiliser SSH ou d'exécuter des commandes basiques (même sauvegarder des fichiers échoue)
- Les logs ou outils de surveillance affichant "No space left on device"
- AWS CloudWatch montrant des erreurs d'écriture disque ou des erreurs I/O
Outils clés que j'ai utilisés pour détecter le problème :
df -h(affiche l'utilisation de l'espace disque en format lisible)du -sh /*etdu -sh /var/*(trouve les gros dossiers)- AWS EC2 Monitoring et alarmes CloudWatch
- Logs d'erreurs :
/var/log/syslog,/var/log/messages, logs Apache/Nginx/MySQL
Astuce pro : Si vous pouvez utiliser SSH et exécuter df -h, et que vous voyez / ou /dev/xvda1 à 100%, vous avez trouvé le problème !
Creuser plus profond : Découvrir la véritable cause
Pour moi, l'histoire ne s'est pas arrêtée à "disque plein." J'avais besoin de savoir pourquoi. Voici ce que j'ai découvert :
- Fichiers de sauvegarde : Des sauvegardes anciennes et automatisées s'accumulaient dans
/var/www/temp— plus de 14 Go de fichiers .zip et .tgz, dont aucun n'était plus nécessaire. - Cache et logs WordPress : Certains sites avaient des dossiers de cache gonflés et d'énormes logs d'erreurs.
- Aucun processus de nettoyage : Il n'y avait ni script ni politique pour supprimer les anciens fichiers, donc le même cycle se répétait toutes les quelques semaines.
- Surveillance manquée : Je n'avais pas configuré les alertes d'espace disque AWS CloudWatch, donc le problème a atteint "critique" avant que je ne le remarque.
Leçon : Sur un serveur multi-sites, même quelques gigaoctets de sauvegardes ou de logs peuvent vous pousser rapidement à 100% d'utilisation du disque.
La solution : Comment j'ai libéré de l'espace et arrêté les crashes
1. Identifiez les gros consommateurs de disque
Connectez-vous en SSH à votre instance et découvrez ce qui consomme l'espace :
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. Supprimez les sauvegardes, logs et caches inutilisés
Nettoyez les gros coupables. Pour moi, ces commandes ont fait des merveilles :
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. Confirmez l'espace libre
Vérifiez toujours après le nettoyage :
df -h
L'utilisation du disque est passée instantanément de 100% à 72% — et le serveur était de nouveau en ligne.
4. Redémarrez les services si nécessaire
Parfois Apache, Nginx ou MySQL ont besoin d'un redémarrage pour récupérer :
sudo systemctl restart nginx
sudo systemctl restart apache2 # (si vous utilisez Apache)
sudo systemctl restart mysql
5. Configurez des sauvegardes et un nettoyage automatisés
-
Snapshots hebdomadaires automatisés : J'ai configuré AWS Data Lifecycle Manager (DLM) pour créer un snapshot EBS hebdomadaire (et supprimer automatiquement les anciens).
-
Nettoyage régulier : Ajouté un cron job simple pour supprimer tout dans
/var/www/tempchaque semaine :0 3 * * 0 rm -rf /var/www/temp/* -
Alarmes CloudWatch : Activé les alertes CloudWatch pour une utilisation élevée du disque — plus de mauvaises surprises !
Comment prévenir 100% d'utilisation du disque sur les serveurs WordPress AWS
Si vous exécutez WordPress (ou toute application web) sur AWS EC2, voici ce que je recommande :
- Surveillez tout : Configurez CloudWatch pour vous alerter quand l'utilisation du disque atteint 75%, 85% et 95%.
- Automatisez les sauvegardes — mais faites une rotation : Utilisez AWS Lifecycle Manager pour les snapshots EBS et définissez une politique de rétention. Déplacez les sauvegardes WordPress/base de données vers S3 au lieu de les stocker localement.
- Automatisez le nettoyage : Utilisez des cron jobs ou des scripts pour nettoyer régulièrement les fichiers temporaires, cache et logs.
- Évoluez si nécessaire : Si vos sites dépassent constamment le disque, envisagez un volume EBS plus grand ou séparez les sauvegardes/médias sur S3.
- Vérifiez les plugins et le cache : Des plugins de sauvegarde ou de cache mal configurés peuvent remplir les disques rapidement.
Conclusion : Du chaos au contrôle
Atteindre 100% d'utilisation du disque sur AWS peut être un cauchemar, mais cela n'a pas à faire tomber votre entreprise. Avec quelques vérifications intelligentes, des nettoyages et un peu d'automatisation, vous pouvez passer de crashes constants à une confiance totale. Mes blogs WordPress sont maintenant stables, sauvegardés, et je dors mieux la nuit en sachant qu'AWS est là pour moi.
Avez-vous rencontré des problèmes de disque serveur ou souhaitez-vous partager votre propre solution ? Laissez un commentaire ou une question ci-dessous — aidons-nous mutuellement à garder nos sites en ligne !
