Une erreur HTTP 500 (Internal Server Error) peut faire paniquer n’importe quel administrateur système : la page tombe, les logs restent muets et les visiteurs voient seulement un message sibyllin. L’une des raisons les plus courantes, mais aussi les plus sournoises, est… un disque totalement saturé. Quand la partition système atteint 100 %, de nombreux services (Apache / Nginx, PHP-FPM, MySQL / MariaDB, Plesk, etc.) cessent d’écrire leurs fichiers temporaires, leurs sockets ou leurs journaux. Résultat : tout plante en silence et le serveur renvoie un laconique « 500 ».

Ce guide pas-à-pas vous montre comment identifier rapidement le problème d’espace disque, libérer de l’espace sans risque et mettre en place une stratégie de prévention pour que cette mésaventure ne se reproduise plus.

Se connecter au serveur en SSH

La première étape consiste à établir une connexion sécurisée :

ssh utilisateur@adresse-ip

• utilisateur : compte disposant des droits sudo (par exemple debian ou root).
• adresse-ip : IP publique / privée de votre machine virtuelle ou serveur dédié.

Vérifier l’utilisation du disque

Une fois connecté, exécutez :

sudo df -h

Si la colonne Use% révèle immédiatement les partitions à 100 %. Un tel chiffre est un indicateur sans ambiguïté : l’espace libre est épuisé et il faut agir sans tarder.

Repérer les répertoires volumineux

Pour savoir où se cache le coupable :

sudo du -h --max-depth=1 / | sort -hr

Quelques dossiers problématiques récurrents :

Dossier	Pourquoi il gonfle
/var	Les journaux applicatifs et les dumps Plesk s’y accumulent.
/home	Uploads FTP, sauvegardes locales, médias oubliés.
/usr	Rarement plein, sauf compilations ou dépôts locaux.
/tmp	Cache PHP, uploads inachevés, sessions.

Trouver directement les gros fichiers (> 500 Mo)

sudo find / -xdev -type f -size +500M \
  -exec du -sh {} + 2>/dev/null | sort -hr | head -n 20

Vous obtenez une liste classée ; par exemple :

17G /var/log/plesk-php74-fpm/error.log.1
16G /var/lib/psa/dumps/domains/mon-site.com/backup_2024-12-01.tzst
14G /var/www/vhosts/mon-site.com/logs/error_log
 3.5G /var/lib/mysql/ma_base/ps_table.ibd

Sauvegarder puis supprimer en toute sécurité

Sauvegarder

1. Copiez hors du serveur les archives (.tzst, .sql) via SCP ou vers un NAS.
2. Compressez les logs historiques pour gagner encore de la place :

   sudo gzip -9 /var/log/mon_service/*.log
   

Supprimer

sudo rm -f /var/log/plesk-php74-fpm/*.log*
sudo rm -f /var/lib/psa/dumps/domains/mon-site.com/*.tzst
sudo rm -f /var/www/vhosts/mon-site.com/logs/error_log

⚠️ Attention : rm est irréversible. Vérifiez chaque chemin deux fois avant validation.

Libérer l’espace toujours occupé par des processus

Il arrive qu’un service garde un descripteur de fichier ouvert sur un fichier pourtant supprimé, ce qui retarde la libération de l’espace.

sudo lsof | grep deleted

Notez le PID coupable, puis redémarrez le service concerné :

sudo systemctl restart apache2
sudo systemctl restart plesk-php74-fpm
sudo systemctl restart mariadb

Enfin, purgez les caches système :

sudo sync
echo 3 | sudo tee /proc/sys/vm/drop_caches

Un nouveau df -h doit désormais afficher une utilisation plus saine.

Vérifier et relancer les services web

sudo systemctl restart apache2
sudo systemctl status apache2

Contrôlez votre site : la page devrait se charger à nouveau sans erreur 500. Pensez à inspecter les journaux (/var/log/apache2/error.log) pour confirmer que tout fonctionne normalement.

Mettre en place une prévention automatique avec Cron

Ouvrez la crontab root :

sudo crontab -e

Ajoutez, par exemple :

# Nettoyer les logs PHP-FPM chaque lundi à 02:00
0 2 * * 1 find /var/log/plesk-php74-fpm -type f -name "*.log*" -delete

# Purger les backups Plesk de plus de 7 jours tous les jours à 03:00
0 3 * * * find /var/lib/psa/dumps -type f -name "*.tzst" -mtime +7 -delete

️ Bon réflexe : avant d’effacer vos backups locaux, assurez-vous d’avoir au moins une sauvegarde récente hors site (cloud, stockage objet, autre datacenter).

Bonnes pratiques supplémentaires

1. Surveillance active : installez un outil de monitoring (Zabbix, Prometheus, Netdata) pour recevoir des alertes avant saturation.
2. Sauvegardes différentielles : privilégiez rsnapshot, borg, ou les sauvegardes incrémentales Plesk pour limiter la taille des dumps quotidiens.
3. Mises à jour régulières : un système à jour corrige des fuites de logs ou de caches connues.
4. Sécurisation SSH : désactivez root en login direct ; employez des clés ; changez le port si nécessaire ; activez un pare-feu (ufw, firewalld).

Ces gestes simples, effectués régulièrement, réduisent drastiquement la probabilité d’une nouvelle saturation disque suivie d’une erreur 500 impromptue.

Conclusion

Un disque plein est un avertissement sévère : il bloque silencieusement les processus vitaux et fait tomber vos applications web dans une opacité totale. Grâce aux étapes détaillées ci-dessus — diagnostic précis, suppression réfléchie, redémarrage contrôlé et automatisation préventive — vous disposez à présent d’une méthode complète pour rétablir la disponibilité de vos services et pérenniser la santé de votre infrastructure.

En mettant en œuvre une surveillance proactive et des tâches Cron intelligentes, vous transformez une réparation ponctuelle en stratégie de maintenance continue, garantissant ainsi la satisfaction durable de vos utilisateurs et la sérénité de vos nuits d’admin !