Disque plein sous Linux : les commandes utiles avant de supprimer n’importe quoi

Un disque plein sous Linux, ça arrive souvent au mauvais moment : mise à jour bloquée, base de données qui refuse d’écrire, service qui plante, connexion SSH encore ouverte mais serveur à moitié paralysé. Le réflexe dangereux, c’est de lancer un rm -rf sur le premier gros dossier trouvé.

Avant de supprimer quoi que ce soit, il faut savoir quelle partition est pleine, ce qui occupe réellement l’espace, et si le problème vient des fichiers, des journaux ou parfois des inodes. Voici les commandes que j’utilise pour diagnostiquer proprement.

Commencez par identifier la partition pleine

La première commande à lancer, c’est df. Elle donne l’espace utilisé par système de fichiers, pas par dossier.

df -h

Regardez surtout les colonnes Use% et Mounted on. Si / est à 100 %, le système entier peut être touché. Si c’est /var, le problème vient souvent des logs, des caches, de Docker, d’une base de données ou d’un service qui écrit trop.

J’aime bien ajouter le type de système de fichiers quand je ne connais pas la machine :

df -hT

Vous pouvez aussi tomber sur un cas plus discret : il reste de la place en Go, mais plus assez d’inodes. Dans ce cas, beaucoup de petits fichiers peuvent bloquer les créations de fichiers.

df -i

Si les inodes sont à 100 %, chercher uniquement des gros fichiers ne suffira pas. Il faudra plutôt trouver les dossiers qui contiennent une énorme quantité de petits fichiers.

Trouvez les dossiers qui prennent le plus de place

Une fois la partition identifiée, utilisez du pour mesurer les dossiers. Sur une racine pleine, je commence souvent par ceci :

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

L’option -x évite de traverser d’autres systèmes de fichiers montés. C’est important sur un serveur avec des volumes séparés, sinon vous risquez de mélanger le diagnostic de /, /home, /mnt ou /var.

Si /var ressort comme le dossier principal, descendez d’un niveau :

sudo du -xh --max-depth=1 /var | sort -h

Puis continuez seulement dans le dossier suspect. Évitez de lancer des scans larges au hasard sur un serveur chargé. du peut faire beaucoup d’entrées/sorties disque, surtout sur de gros volumes.

Utilisez ncdu si vous voulez explorer plus vite

ncdu est très pratique quand vous voulez explorer l’espace disque dans une interface texte. Il scanne un dossier, puis vous permet de naviguer dans l’arborescence sans relancer du à chaque niveau.

sudo apt install ncdu
sudo ncdu -x /

Sur Fedora ou une distribution proche :

sudo dnf install ncdu
sudo ncdu -x /

Attention tout de même : ncdu peut supprimer des fichiers depuis son interface. Je vous conseille de l’utiliser d’abord comme outil de lecture, puis de supprimer à la main avec une commande claire quand vous êtes sûr du dossier.

Vérifiez les journaux systemd avant de toucher aux dossiers sensibles

Sur beaucoup de machines modernes, les journaux systemd peuvent prendre de la place, surtout après une erreur qui boucle. Commencez par mesurer leur poids :

journalctl --disk-usage

Si le volume est clairement trop élevé, vous pouvez réduire l’historique sans supprimer brutalement les fichiers dans /var/log/journal.

sudo journalctl --vacuum-time=14d

Ou fixer une taille maximale :

sudo journalctl --vacuum-size=1G

Si les logs regonflent immédiatement, le nettoyage n’est pas la vraie correction. Il faut identifier le service qui écrit en boucle avec journalctl -p warning..alert ou avec les logs du service concerné. Si vous touchez à une unité systemd pendant le diagnostic, gardez aussi en tête la différence avec systemctl daemon-reload.

Les nettoyages généralement moins risqués

Il existe quelques zones où le nettoyage est souvent plus sûr, à condition de comprendre ce que vous faites.

• cache APT sur Debian ou Ubuntu : sudo apt clean ;
• anciens paquets inutiles : sudo apt autoremove après vérification ;
• journaux systemd trop volumineux : journalctl --vacuum-time ou --vacuum-size ;
• fichiers temporaires d’une application connue, seulement si le service peut les recréer ;
• images, conteneurs ou volumes Docker inutilisés, si Docker est bien la cause.

Pour Docker, ne lancez pas une purge globale sans regarder ce qui existe. Sur un serveur de production, un volume Docker peut contenir des données applicatives.

docker system df

La commande vous donne déjà une idée avant de supprimer des images, des conteneurs arrêtés ou des volumes.

Les pièges qui font perdre du temps

Premier piège : supprimer un gros fichier ouvert par un processus. Dans ce cas, l’espace peut ne pas revenir tout de suite, car le processus garde encore le fichier en mémoire. Pour le vérifier :

sudo lsof +L1

Si vous voyez un ancien fichier de log supprimé mais encore ouvert, il faudra souvent redémarrer ou recharger le service concerné proprement.

Deuxième piège : confondre un dossier monté avec un dossier local. Si un disque est monté sur /data, l’espace affiché pour /data ne correspond pas forcément à la partition racine. C’est pour cela que df -h doit toujours passer avant du.

Troisième piège : supprimer dans /var/lib sans savoir quelle application utilise le dossier. Bases de données, conteneurs, dépôts, files d’attente : ce dossier peut contenir des données critiques. Si vous n’êtes pas sûr, sauvegardez avant et vérifiez le service propriétaire.

Vérifiez après le nettoyage

Après une suppression ou un nettoyage, revenez aux commandes de départ :

df -h
df -i

Si l’espace n’a pas bougé, cherchez les fichiers ouverts avec lsof +L1 ou vérifiez si vous avez nettoyé la mauvaise partition. Si l’espace revient mais se remplit à nouveau en quelques minutes, le problème est encore actif : logs qui tournent en boucle, sauvegarde qui écrit au mauvais endroit, export oublié, conteneur trop bavard.

La bonne méthode reste simple : df pour savoir quelle partition est touchée, du ou ncdu pour trouver le dossier, puis une suppression ciblée et compréhensible. C’est moins spectaculaire qu’un gros rm -rf, mais beaucoup plus sûr.

Pour aller plus loin, les pages de manuel de df, du et journalctl détaillent les options utiles.