23 h 40, un vendredi. L’alerte de supervision tombe sèchement : espace disque à 100 % sur le serveur qui héberge la boutique d’un client. Quelques minutes plus tard, les commandes ne s’enregistrent plus : WordPress ne parvient plus à écrire en base ni sur disque, WooCommerce affiche une erreur générique au moment du paiement. Le week-end de soldes commence mal.
Face à un disque plein, la tentation est de tout regarder en même temps. La bonne méthode est inverse : réduire le périmètre le plus vite possible, partition par partition puis dossier par dossier, pour isoler la cause en quelques minutes plutôt qu’en une heure de recherche dispersée.
Confirmer la partition réellement saturée
Premier réflexe, avant toute investigation fine : vérifier quelle partition est pleine, pas seulement l’espace global. Un serveur peut avoir un disque système presque vide et une partition /var ou /home totalement saturée si elles sont séparées.
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 40G 38G 0 100% /
/dev/sdb1 200G 120G 70G 64% /home
Ici, la partition racine / est pleine alors que /home, où résident pourtant les fichiers WordPress, a encore de la marge. Le vrai suspect se trouve donc ailleurs que dans le site lui-même : logs système, paquets en cache, ou fichiers temporaires.
Descendre niveau par niveau avec du
Lancer un du -sh récursif sur l’ensemble du disque est une mauvaise idée sous pression : sur un disque saturé et déjà lent, cette commande peut prendre de longues minutes avant de renvoyer un résultat exploitable. La méthode efficace consiste à descendre un niveau à la fois :
du -sh /* 2>/dev/null | sort -rh | head -10
du -sh /var/* 2>/dev/null | sort -rh | head -10
du -sh /var/log/* 2>/dev/null | sort -rh | head -10
Sur ce cas précis, le premier niveau a immédiatement pointé vers /var à 30 Go, et le deuxième niveau vers /var/log à 27 Go, avec un fichier syslog unique de 24 Go généré par un service de supervision mal configuré qui journalisait en boucle une erreur réseau toutes les quelques millisecondes depuis trois jours.
Les suspects habituels côté WordPress
Quand la saturation vient réellement du côté applicatif plutôt que du système, quatre sources reviennent systématiquement :
- Sauvegardes locales accumulées : un plugin de sauvegarde qui écrit ses archives sur le même disque sans purge automatique des anciennes versions.
- Révisions d’articles : sur un site actif depuis plusieurs années sans limite de révisions configurée, la table
wp_postspeut accumuler des dizaines de milliers de lignes inutiles, ce qui pèse sur la base plus que sur le disque brut mais mérite d’être vérifié en parallèle. - Médiathèque non maîtrisée : imports en masse d’images en haute résolution jamais compressées, multipliés par les différentes tailles générées automatiquement par WordPress.
- Logs applicatifs PHP ou serveur web : un site en erreur qui journalise abondamment sur une erreur répétitive peut générer plusieurs gigaoctets par jour sans que personne ne le remarque.
| Suspect | Commande de vérification rapide |
|---|---|
| Sauvegardes locales | du -sh wp-content/backups* wp-content/ai1wm-backups* 2>/dev/null |
| Médiathèque | du -sh wp-content/uploads |
| Logs applicatifs | du -sh /var/log/php*.log wp-content/debug.log 2>/dev/null |
Libérer de la place sans tout casser
Une fois le coupable identifié, la tentation de supprimer en urgence doit rester prudente : supprimer un log applicatif en cours d’écriture par un processus actif ne libère pas toujours l’espace immédiatement sous Linux, car le processus garde le descripteur de fichier ouvert. Il faut alors soit redémarrer le service concerné, soit vider le fichier plutôt que le supprimer.
# Vide le contenu sans casser le descripteur de fichier ouvert
truncate -s 0 /var/log/syslog
# Alternative : redémarrer le service après suppression classique
rm /var/log/syslog
systemctl restart rsyslog
Un disque à 92 % d’occupation n’est pas une alerte à reporter au lundi : sur un site marchand actif, le delta entre une alerte ignorée et une panne complète peut se compter en heures, pas en jours.
Prévenir plutôt que courir après l’incident
Ce diagnostic manuel reste un pansement, pas une solution : la vraie protection est une supervision qui alerte tôt, avant la saturation complète, avec un seuil d’avertissement autour de 80 % et un seuil critique autour de 90 %. Sur ce cas précis, l’alerte à 92 % avait été envoyée trois jours avant l’incident et laissée sans suite faute de destinataire clairement identifié côté agence.
En résumé
Face à un disque plein, la rapidité vient de la méthode, pas de la panique : confirmer la partition concernée avec df -h, descendre niveau par niveau avec du -sh plutôt que de scanner à l’aveugle, puis vérifier les quatre suspects habituels côté WordPress si le système lui-même n’est pas en cause. Une fois l’incident résolu, la vraie correction porte sur l’alerte qui aurait dû être traitée avant que le disque n’atteigne 100 %.
