Passer au contenu principal
Publié le 14 novembre 2026 « No space left on device » : votre VPS Linux a rempli son disque. À partir de là, tout ce qui écrit échoue. La base de données refuse les requêtes, PHP ne crée plus de sessions, une mise à jour s’arrête au milieu, le journal perd des lignes. La bonne nouvelle : l’espace se récupère presque toujours sans rien casser, à condition de savoir où il est parti. Ce guide suit l’ordre d’un diagnostic, sur Debian, Ubuntu, AlmaLinux et Rocky Linux. Chaque section donne le problème, la commande qui le règle et la vérification.

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

Repérez la ligne à 100 % et son point de montage (Mounted on). Le plus souvent, c’est /.

Blocs ou inodes

Un disque peut être plein sans que df -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.
Si IUse% est à 100 %, trouvez le répertoire qui contient le plus de fichiers :
Descendez ensuite d’un niveau dans le répertoire en tête (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

L’option -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 :
Quand le disque est plein à 100 %, l’installation peut échouer. Commencez alors par 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 avec rm, 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é :
La colonne COMMAND donne le processus, SIZE/OFF la taille. Redémarrez le service concerné :
Si le service ne peut pas être redémarré tout de suite, videz le fichier par son descripteur. Le PID et le FD (sans la lettre finale, 4w devient 4) viennent de la sortie de lsof :
Vérification. 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 :
Le nettoyage ne touche que les fichiers archivés. Pour qu’il tienne dans le temps, fixez un plafond. Par défaut, journald s’autorise 10 % du système de fichiers. La page de manuel journald.conf recommande un fichier à part dans /etc/systemd/journald.conf.d/ plutôt que de modifier le fichier principal :
Vérification. 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 :
Pour le vider sans couper le service qui écrit dedans, utilisez truncate plutôt que rm :
Puis donnez-lui une rotation. logrotate est installé sur les quatre distributions et lit /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.
Les deux commandes sont sans risque : les paquets seront retéléchargés si besoin. Vérification. 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 :
APT protège le noyau en cours d’exécution et le plus récent. Relisez quand même la liste : 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 :
Vérification. 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 :
Puis nettoyez ce qui n’est plus utilisé :
N’ajoutez pas --volumes sans avoir vérifié la liste avec docker volume ls. Un volume contient souvent les données d’une base. Un volume supprimé ne se récupère pas, sauf depuis un snapshot ou une sauvegarde.
Les logs des conteneurs sont l’autre source fréquente. Le pilote par défaut, json-file, ne fait aucune rotation. Repérez les plus gros :
Activez la rotation dans /etc/docker/daemon.json (fusionnez avec le contenu existant si le fichier existe) :
La documentation Docker le précise : le réglage ne s’applique qu’aux conteneurs créés ensuite. Recréez les conteneurs existants (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 :
Avec un réplica, vérifiez d’abord sur lui le fichier en cours de lecture (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 :
Vérification. 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.
Sur un grand disque de données, vous pouvez la réduire. Sur /, 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 :
L’envoi passe par la commande 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 :
Ajoutez-y une règle logrotate pour chaque application qui écrit ses propres logs, et un plafond pour le journal : ce sont les deux sources qui reviennent le plus vite.

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 :
Des inodes épuisés, pas l’espace. 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

Une question sur un serveur hébergé chez nous ? Notre équipe est disponible depuis votre espace client.