Disque saturé : identifier et nettoyer

Un disque qui sature, c'est le grand classique du vendredi soir : le site renvoie une 500, Plesk affiche « quota atteint », les mails ne partent plus, WordPress reste coincé en mode maintenance. La cause est presque toujours la même (des logs qui n'ont jamais été rotés, un cache fou, un backup oublié), mais encore faut-il la trouver vite. Cette doc vous donne la procédure de diagnostic en SSH, les coupables habituels, et comment nettoyer sans virer ce qu'il ne faut pas.

Symptômes

• Site qui renvoie une erreur 500 ou une page blanche, souvent après une écriture PHP.
• Plesk affiche « Quota atteint » ou un bandeau rouge sur l'abonnement.
• Impossible d'envoyer ou de recevoir des mails (le MTA refuse d'écrire dans la boîte).
• Les uploads médias échouent silencieusement dans l'admin WordPress ou PrestaShop.
• WordPress reste bloqué en mode maintenance (fichier .maintenance jamais supprimé faute d'espace).
• Les sauvegardes programmées échouent.

1. Vérifier le quota côté Plesk

Premier réflexe avant de plonger en SSH : voir ce que Plesk annonce.

1. Connectez-vous à l'espace Plesk de l'abonnement.
2. Allez dans Sites Web & Domaines.
3. Cliquez sur Utilisation du disque (ou Quota usage) en haut de la page.
4. Plesk détaille la consommation par composant : fichiers web, bases de données, mails, logs, backups.

Cette vue donne déjà 80 % de la réponse. Si c'est la colonne « mails » qui explose, sautez directement à la section dédiée plus bas. Si ce sont les « fichiers web » ou les « logs », passez en SSH.

2. En SSH : mesurer d'où ça vient

Vue d'ensemble des partitions

# La partition est-elle vraiment pleine au niveau système ?
df -h

# Et au niveau inodes (nombre de fichiers) ?
df -i

Zoomer sur l'abonnement

# Poids global de chaque sous-dossier racine du vhost
du -sh /var/www/vhosts/exemple.fr/*

# Top 20 des plus gros dossiers (profondeur 2)
du -h --max-depth=2 /var/www/vhosts/exemple.fr/ 2>/dev/null | sort -hr | head -20

# Top 20 des plus gros fichiers (> 50 Mo)
find /var/www/vhosts/exemple.fr/ -type f -size +50M -exec ls -lh {} \; 2>/dev/null \
  | awk '{print $5, $9}' | sort -hr | head -20

Ces trois commandes, lancées dans l'ordre, suffisent presque toujours à cibler le coupable en moins d'une minute.

3. Les coupables habituels

Par ordre de fréquence sur l'infra Datacampus :

Logs qui n'ont jamais été rotés

Le dossier logs/ de Plesk (access_ssl_log, error_log, proxy_access_ssl_log). Sans logrotate correctement configuré, un site à trafic modéré peut y stocker plusieurs Go en quelques mois.

du -sh /var/www/vhosts/exemple.fr/logs/
ls -lhS /var/www/vhosts/exemple.fr/logs/ | head

Sessions PHP orphelines

Selon le pool PHP, elles vivent dans /var/lib/php/sessions/ ou /tmp. Sur un site mal réglé (session.gc_maxlifetime à rallonge ou garbage collector jamais déclenché), on peut voir plus d'un million de fichiers. C'est souvent ce qui fait sauter les inodes avant l'espace disque.

Cache CMS

• WordPress : wp-content/cache/, wp-content/uploads/cache/, plus les dossiers spécifiques à WP-Rocket, WP Super Cache, LiteSpeed Cache (lscache/), W3 Total Cache.
• PrestaShop : var/cache/, img/tmp/ (miniatures régénérées à la volée), translations/.
• Drupal : sites/default/files/css/, sites/default/files/js/.

Backups laissés sur le serveur

Tous les *.sql, *.tar.gz, *.zip qui traînent à la racine du site ou dans wp-content/updraft/, wp-content/backup-db/, backups/. C'est le tiercé gagnant des « je ne comprends pas pourquoi c'est plein ».

# Lister les archives qui traînent
find /var/www/vhosts/exemple.fr/ -type f \
  \( -name "*.sql" -o -name "*.tar.gz" -o -name "*.zip" -o -name "*.sql.gz" \) \
  -exec ls -lh {} \; 2>/dev/null | sort -k5 -hr | head

Uploads médias non optimisés

wp-content/uploads/YYYY/MM/ gonflé avec des photos RAW ou des JPEG de 10 Mo mis en ligne tels quels depuis l'iPhone du client. Un plugin d'optimisation (ShortPixel, Imagify) règle le problème, mais ça ne rattrapera pas les Go déjà consommés.

node_modules oublié après un build en prod

find /var/www/vhosts/exemple.fr/ -type d -name node_modules -prune -exec du -sh {} \;

À chaque fois qu'on en trouve un en prod : 300 à 800 Mo. À supprimer, le build se fait en local ou en CI, pas sur le serveur.

Mails accumulés

Une boîte IMAP jamais purgée peut peser 5 à 20 Go. Plesk mail ou Mailcow selon l'offre. Voir la doc Mailcow : administration pour la purge côté Mailcow, sinon directement dans Plesk > Mail.

4. Nettoyer proprement

Logs : truncate, pas rm

Supprimer un log en cours d'écriture par Apache/nginx laisse le process avec un file descriptor ouvert sur un inode fantôme : l'espace n'est pas libéré tant que vous ne redémarrez pas le service. La bonne méthode est de truncater :

cd /var/www/vhosts/exemple.fr/logs/
truncate -s 0 access_ssl_log
truncate -s 0 error_log
truncate -s 0 proxy_access_ssl_log

Puis vérifiez que logrotate est bien actif sur le vhost (voir la doc Tâches planifiées pour poser un cron hebdo de rotation maison si besoin).

Sessions PHP expirées

# Supprimer les sessions de plus de 7 jours
find /var/lib/php/sessions/ -type f -mtime +7 -delete 2>/dev/null

# Ou sur un /tmp partagé, cibler son propre user
find /tmp -type f -user "$(whoami)" -name 'sess_*' -mtime +7 -delete

Côté config, dans Plesk > Paramètres PHP de l'abonnement, passer session.gc_maxlifetime à une valeur raisonnable (1440 secondes par défaut, rarement besoin de plus) et session.gc_probability à 1 pour que le garbage collector tourne.

Cache WordPress

# Via WP-CLI (propre, invalide aussi les transients)
cd /var/www/vhosts/exemple.fr/httpdocs
wp cache flush
wp transient delete --all

# Si l'accès WP-CLI n'est pas disponible, à la main
rm -rf wp-content/cache/*
rm -rf wp-content/uploads/cache/*

Pour les plugins de cache tiers (WP-Rocket, LiteSpeed), videz aussi via leur UI si WP répond encore, sinon supprimez le contenu du dossier dédié du plugin.

Cache PrestaShop

# Via le back-office : Paramètres avancés > Performances > Vider le cache

# Ou en SSH
rm -rf /var/www/vhosts/exemple.fr/httpdocs/var/cache/prod/*
rm -rf /var/www/vhosts/exemple.fr/httpdocs/var/cache/dev/*
rm -rf /var/www/vhosts/exemple.fr/httpdocs/img/tmp/*

Backups laissés

Téléchargez-les en local si vous voulez les garder, puis supprimez-les du serveur. La bonne règle : un backup qui vit sur le disque qu'il sauvegarde n'est pas un backup. Voir plus bas la section prévention.

5. Quotas email

Un mailbox plein bloque tout l'abonnement Plesk : plus un seul mail n'entre ni ne sort, même pour les autres boîtes.

• Plesk Mail : espace client > Mail, vérifiez la colonne Utilisation. Ajustez le quota par boîte ou purgez.
• Mailcow : interface admin > Mailboxes, colonne Quota utilisé. Voir Mailcow : administration.

6. Prévenir plutôt que guérir

1. Alerte à 80 % : dans Plesk > Paramètres > Notifications, activez l'alerte email quota atteint, seuil 80 %. Vous êtes prévenu avant que le site tombe.
2. Log rotation : assurez-vous qu'une rotation hebdomadaire est configurée sur les logs Plesk du vhost. Voir Tâches planifiées pour poser un cron dédié si besoin.
3. Cron hebdo de purge : une tâche plesk simple qui vide les caches CMS et les sessions expirées chaque dimanche soir évite 90 % des incidents.
4. Backups externes : jamais sur le disque de prod. S3 compatible, BackBlaze B2, ou stockage Datacampus dédié. UpdraftPlus, Duplicator, restic, BorgBackup, au choix, mais la destination doit être ailleurs.

Exemple de cron de purge hebdo

# Tous les dimanches à 3 h 30, à placer dans les tâches planifiées Plesk
30 3 * * 0 find /var/www/vhosts/exemple.fr/httpdocs/wp-content/cache/ -type f -mtime +7 -delete; \
            find /tmp -type f -user "$(whoami)" -name 'sess_*' -mtime +7 -delete

7. Demander une augmentation de quota

Si après nettoyage l'usage reste légitimement proche du plafond (un site média avec beaucoup de contenus par exemple), ouvrez un ticket sur le ServiceDesk Datacampus. Chaque offre a une fourchette d'extension possible, et c'est souvent plus rentable de monter le quota que de passer des heures à nettoyer tous les mois.

Récapitulatif

1. df -h et df -i pour cadrer (espace ou inodes ?).
2. du -h --max-depth=2 trié pour identifier le gros dossier.
3. Logs : truncate -s 0, jamais rm.
4. Sessions : find ... -mtime +7 -delete.
5. Caches : via WP-CLI ou back-office CMS, sinon rm -rf ciblé.
6. Backups et archives : télécharger puis supprimer, migrer le backup ailleurs.
7. Alerte 80 % activée pour la prochaine fois.