Où part l’espace disque d’un VPS
Récapitulatif des sources les plus fréquentes, établi le 14 novembre 2026 :Avant de nettoyer : un snapshot
Un nettoyage se fait vite, une suppression de trop aussi. Prenez un snapshot depuis la console avant de toucher aux binlogs, aux volumes Docker ou aux noyaux. Vous gardez un point de retour en un clic. Les sauvegardes restent votre protection de fond.Diagnostiquer un disque plein
Quel système de fichiers est plein
Mounted on). Le plus souvent, c’est /.
Blocs ou inodes
Un disque peut être plein sans quedf -h le montre. Chaque fichier consomme un inode, et leur nombre est fixé à la création du système de fichiers sur ext4. Des millions de petits fichiers les épuisent avant l’espace.
IUse% est à 100 %, trouvez le répertoire qui contient le plus de fichiers :
sudo du --inodes -x -d 1 /var | sort -n | tail). Les coupables habituels : sessions PHP, cache applicatif, file d’attente de messagerie.
Trouver les gros répertoires
-x est essentielle : elle reste sur le système de fichiers de / et ne compte pas les autres montages.
Pour naviguer plus vite, ncdu fait la même chose de façon interactive :
apt clean ou dnf clean all (plus bas) pour gagner un peu de place.
Fichiers supprimés mais toujours ouverts
Problème. Vous avez supprimé un gros log avecrm, et df n’a pas bougé. Le fichier n’existe plus dans l’arborescence, mais un processus le garde ouvert : l’espace n’est rendu qu’à la fermeture. C’est aussi le cas quand du donne un total bien inférieur à df.
Solution. Listez les fichiers dont le dernier lien a été supprimé :
COMMAND donne le processus, SIZE/OFF la taille. Redémarrez le service concerné :
PID et le FD (sans la lettre finale, 4w devient 4) viennent de la sortie de lsof :
sudo lsof -nP +L1 ne liste plus le fichier, et df -h / affiche l’espace rendu.
Réduire le journal systemd
Problème./var/log/journal occupe plusieurs gigaoctets.
Solution. Mesurez, puis réduisez :
journald.conf recommande un fichier à part dans /etc/systemd/journald.conf.d/ plutôt que de modifier le fichier principal :
journalctl --disk-usage reste sous la valeur choisie dans les jours qui suivent.
Vider et faire tourner les logs applicatifs
Problème. Un fichier de/var/log ou d’une application grossit sans fin.
Solution. Trouvez-le :
truncate plutôt que rm :
/etc/logrotate.d/ :
copytruncate copie le fichier puis le vide sur place : l’application continue d’écrire au même endroit. Si elle sait rouvrir ses logs sur signal, préférez un bloc postrotate qui le lui envoie.
Vérification. Le mode débogage simule la rotation sans rien modifier :
Vider le cache des paquets
Problème. Les paquets téléchargés lors des mises à jour restent sur le disque. Solution.sudo du -sh /var/cache/apt ou sudo du -sh /var/cache/dnf est revenu à quelques mégaoctets.
Supprimer les anciens noyaux
Problème. Chaque mise à jour du noyau en installe une nouvelle version à côté des précédentes, avec ses modules dans/lib/modules et son image dans /boot.
Solution sur Debian et Ubuntu. Simulez d’abord, puis supprimez :
autoremove retire aussi les dépendances devenues orphelines.
Solution sur AlmaLinux et Rocky. dnf garde un nombre fixe de versions des paquets « installonly », dont le noyau, réglé par installonly_limit dans /etc/dnf/dnf.conf. Pour retirer les versions en trop dès maintenant :
uname -r donne le noyau en cours, qui figure toujours dans dpkg -l 'linux-image*' ou rpm -q kernel.
Nettoyer Docker
Problème./var/lib/docker grossit : images remplacées, conteneurs arrêtés, cache de construction, logs des conteneurs.
Solution. Mesurez par catégorie :
json-file, ne fait aucune rotation. Repérez les plus gros :
/etc/docker/daemon.json (fusionnez avec le contenu existant si le fichier existe) :
docker compose up -d --force-recreate pour un projet Compose).
Vérification. docker system df affiche une colonne RECLAIMABLE proche de zéro.
Purger les binlogs MySQL et MariaDB
Problème./var/lib/mysql contient des dizaines de fichiers binlog.000123 ou mysql-bin.000123.
Solution. Ne les supprimez jamais avec rm : le serveur tient un index de ces fichiers. Passez par SQL :
SHOW REPLICA STATUS\G) : un réplica arrêté ou en retard a encore besoin des binlogs qu’il n’a pas lus.
Pour une expiration automatique, la variable dépend du serveur :
expire_logs_days a été retirée de MySQL en 8.2 : sur MySQL 8.4, seule binlog_expire_logs_seconds existe.
Appliquez la valeur à chaud, puis rendez-la permanente :
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; renvoie 604800, et SHOW BINARY LOGS; ne remonte pas au-delà de sept jours.
La réserve root d’ext4
Problème.df affiche 100 % pour vos applications, alors que root peut encore écrire. C’est voulu.
Explication. ext4 réserve par défaut 5 % des blocs aux processus privilégiés. La page de manuel tune2fs donne la raison : limiter la fragmentation et laisser les démons système fonctionner quand les utilisateurs ne peuvent plus écrire. C’est cette réserve qui vous permet encore de vous connecter et de nettoyer.
/, ne le faites que pour sortir d’une urgence, puis remettez la valeur :
La réserve ne concerne qu’ext2, ext3 et ext4. Sur XFS,
tune2fs ne s’applique pas : findmnt vous indique le type.Si le disque est trop petit
Une fois le ménage fait, si/ repasse au-dessus de 85 % en quelques semaines, votre usage a simplement grandi. Choisissez une offre VPS avec plus de stockage, puis étendez la partition pour profiter du nouvel espace.
Si le VPS ne répond plus
Prévenir : une alerte sur seuil
Le disque plein se voit venir. Un script de quelques lignes vous prévient avant, pour l’espace comme pour les inodes :mail (paquet bsd-mailx sur Debian et Ubuntu, s-nail sur AlmaLinux et Rocky) et un serveur de messagerie local. Notre guide SPF, DKIM, DMARC et reverse DNS couvre la délivrabilité.
Vérification. Lancez le script avec un seuil à 1 pour recevoir un message de test :
Pièges courants
rm sur un log ouvert. L’espace n’est pas rendu tant que le processus tourne. Utilisez truncate -s 0, ou redémarrez le service après coup.
Supprimer les fichiers du journal à la main. journalctl --vacuum-size ne supprime que les archives, jamais le fichier en cours d’écriture. Laissez-lui le travail plutôt que rm dans /var/log/journal.
Des fichiers cachés sous un point de montage. Des fichiers écrits dans un répertoire avant qu’un disque y soit monté occupent / mais restent invisibles pour du. Montez / ailleurs pour les voir :
df -h affiche de la place libre et l’erreur persiste : regardez df -i.
docker system prune --volumes en production. Il supprime les volumes non utilisés à cet instant, y compris celui d’une base dont le conteneur est arrêté.
Les binlogs supprimés à la main. Le serveur garde leur liste dans un fichier d’index, que rm ne met pas à jour. Passez toujours par PURGE BINARY LOGS.
Pour aller plus loin
- Snapshots : un point de retour avant chaque nettoyage risqué
- Sauvegardes : la protection de fond de vos données
- Étendre une partition après un passage à une offre plus grande
- Console KVM et mode rescue : reprendre la main sur un VPS qui ne répond plus
- VPS qui ne démarre plus : le mode rescue, pas à pas
- Mises à jour de sécurité automatiques : elles aussi ont besoin d’espace libre pour s’installer

