# Disque plein sur un serveur WordPress : identifier vite ce qui prend la place

> Une alerte tombe à 23 h : le disque est à 100 %, WordPress ne peut plus écrire, les commandes échouent. Voici la méthode pour retrouver le coupable en quelques minutes, sans paniquer.

- Auteur : Clément Hadrot
- Publié le : 2023-12-18
- Mis à jour le : 2023-12-18
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/disque-plein-serveur-wordpress-identifier-vite/

## L’essentiel

- df -h avant tout pour confirmer la partition saturée
- du -sh niveau par niveau, jamais un scan complet à l'aveugle
- Suspects habituels : sauvegardes locales, logs, révisions, médiathèque

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 :

> L'essentiel à retenir : df -h avant tout pour confirmer la partition saturée ; du -sh niveau par niveau, jamais un scan complet à l'aveugle ; Suspects habituels : sauvegardes locales, logs, révisions, médiathèque

```
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_posts` peut 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 %.