Disque plein : nettoyer /var sans casser le système

Ça arrive souvent au pire moment.

Un apt install qui échoue. Un service qui refuse de redémarrer. Un docker pull qui tourne en boucle puis… plus rien. Et quand tu regardes, tu vois le coupable : la partition est pleine. Souvent /, parfois une partition dédiée. Très souvent… /var.

Et le piège, c’est que /var n’est pas un simple dossier « fourre tout ». C’est un endroit vivant. Logs, cache, spool, bases de données, paquets, conteneurs, mails. Donc oui, il faut nettoyer. Mais sans jouer au bulldozer, sinon tu te crées une panne encore plus sympa que « disque plein ».

Dans cet article, je te donne une méthode claire, un peu pragmatique, pour libérer de l’espace dans /var sans casser ton système. Et si tu aimes ce mélange Linux plus productivité terrain, tu peux garder un œil sur Le Blog Tech Pro de Samyn-Antoy ABASSE sur https://monblog-sa-abasse.blogspot.com, j’y poste ce genre de guides quand je tombe sur des vrais problèmes.

---

Ce qu’il y a vraiment dans /var (et pourquoi ça grossit)

Avant de supprimer quoi que ce soit, il faut comprendre la logique :

• /var/log : journaux système et applicatifs. Peut exploser si un service boucle.
• /var/cache : caches (APT, thumbnails, etc.). En général nettoyable.
• /var/lib : données persistantes des services (dpkg, docker, containers, mysql, postfix…). Ici, on casse vite.
• /var/tmp : fichiers temporaires, censés survivre à un reboot. Nettoyable en principe.
• /var/spool : files d’attente (mail, impression, cron). À vérifier avant de supprimer.
• /var/backups : sauvegardes automatiques de certains outils. Parfois oubliées.

Le bon état d’esprit : on identifie ce qui prend de la place, on comprend pourquoi, puis on nettoie ciblé.

---

Étape 1 : confirmer que /var est le problème

bash df -h df -ih

• df -h : place disque.
• df -ih : inodes. Oui, on peut être « plein » en inodes même avec de la place libre, surtout avec des millions de petits fichiers.

Ensuite :

bash sudo du -xhd1 /var | sort -h

• -x évite de traverser d’autres systèmes de fichiers montés sous /var (utile si /var/lib/docker est sur un autre mount).
• -d1 te donne les gros dossiers de premier niveau.

Puis tu zoomes :

bash sudo du -xhd1 /var/log | sort -h sudo du -xhd1 /var/lib | sort -h sudo du -xhd1 /var/cache | sort -h

À ce stade, tu sais où regarder.

---

Étape 2 : trouver les fichiers énormes et les « suspects »

Les plus gros fichiers :

bash sudo find /var -xdev -type f -size +200M -printf '%s %p\n' | sort -n | tail -50

Les fichiers ouverts mais supprimés (le grand classique) :

bash sudo lsof +L1 | grep '/var'

Quand un process garde un fichier log ouvert, même supprimé, l’espace n’est pas libéré tant que le process n’est pas relancé. Donc tu peux supprimer, voir df inchangé, et paniquer. Alors que c’est juste un service à redémarrer.

---

Étape 3 : nettoyage safe et rapide (ce que je fais en premier)

Nettoyer le cache APT (souvent gratuit)

Debian / Ubuntu :

bash sudo apt-get clean sudo apt-get autoclean sudo apt-get autoremove --purge

• clean : supprime tous les paquets en cache.
• autoclean : supprime surtout les paquets obsolètes.
• autoremove : enlève les dépendances inutiles.

Vérifie ensuite :

bash sudo du -sh /var/cache/apt

Nettoyer /var/tmp

En général, tu peux vider ce dossier, mais je préfère éviter si un déploiement est en cours ou si tu as des jobs qui s’en servent.

bash sudo ls -lah /var/tmp | head sudo find /var/tmp -mindepth 1 -mtime +7 -delete

On supprime ici les fichiers de plus de 7 jours. Ajuste selon ton contexte.

---

Étape 4 : logs, logs, logs… sans faire n’importe quoi

Regarder la taille des logs

bash sudo du -sh /var/log/* sudo du -sh /var/log/journal 2>/dev/null

Sur beaucoup de systèmes modernes, systemd-journald peut grossir vite.

Nettoyer journald correctement

Voir la conso :

bash journalctl --disk-usage

Garder par exemple 7 jours :

bash sudo journalctl --vacuum-time=7d

Ou limiter à 500 Mo :

bash sudo journalctl --vacuum-size=500M

Et ensuite, pour éviter que ça recommence :

bash sudo nano /etc/systemd/journald.conf

Paramètres utiles :

• SystemMaxUse=500M
• SystemMaxFileSize=50M
• MaxRetentionSec=7day

Puis :

bash sudo systemctl restart systemd-journald

Pour une compréhension approfondie sur le diagnostic et la gestion de systemd, je te recommande cet article Systemd sans douleur: Diagnostiquer un problème.

Pour les logs en .log classiques (logrotate)

Regarde si logrotate tourne :

bash sudo systemctl status logrotate.timer 2>/dev/null || true sudo cat /etc/logrotate.conf sudo ls /etc/logrotate.d

Tu peux forcer une rotation :

bash sudo logrotate -f /etc/logrotate.conf

Cas « disque plein maintenant » : tronquer un log énorme

Si tu vois un *.log de 20 Go, souvent tu veux libérer vite.

Au lieu de supprimer (risque fichier ouvert), tu tronques :

bash sudo truncate -s 0 /var/log/monservice.log

Ou :

bash sudo sh -c ': > /var/log/monservice.log'

Ensuite, tu corriges la cause. Parce qu’un log qui grossit sans limite, c’est rarement normal.

Étape 5 : /var/lib, la zone dangereuse

C’est là où il faut ralentir un peu. /var/lib contient des données applicatives. On ne supprime pas au hasard.

Cas 1 : Docker ou containerd mange tout

Très fréquent : /var/lib/docker ou /var/lib/containerd.

bash sudo du -sh /var/lib/docker 2>/dev/null sudo docker system df 2>/dev/null

Nettoyage safe :

bash sudo docker image prune -a sudo docker container prune sudo docker volume prune sudo docker network prune

Nettoyage agressif (attention, ça supprime tout ce qui n’est pas utilisé) :

bash sudo docker system prune -a --volumes

Et si tu utilises Kubernetes, microk8s, k3s… on adapte. Là, le nettoyage « bourrin » peut te faire perdre des volumes.

Cas 2 : Snap (Ubuntu) qui accumule des révisions

Regarde :

bash sudo du -sh /var/lib/snapd snap list --all

Supprimer les anciennes révisions (exemple) :

bash sudo snap set system refresh.retain=2

Puis désinstaller les révisions désactivées. Il y a plusieurs scripts qui circulent, mais l’idée est toujours la même : garder 2 révisions, virer le reste.

Cas 3 : apt et dpkg, archives et états

• /var/lib/dpkg est vital.
• /var/cache/apt est nettoyable, on l’a déjà fait.

Si tu as eu une panne pendant une install, tu peux avoir des paquets cassés :

bash sudo dpkg --configure -a sudo apt-get -f install

Ce n’est pas du nettoyage, mais ça évite les surprises après une saturation disque.

Cas 4 : bases de données (MySQL, PostgreSQL)

Si /var/lib/mysql ou /var/lib/postgresql est énorme, ne supprime rien à la main. Là, c’est du ménage applicatif : purge de tables, archivage, rotation, compression, retention. Donc on commence par mesurer et comprendre.

Pour PostgreSQL :

bash sudo du -sh /var/lib/postgresql/*

Pour MySQL :

bash sudo du -sh /var/lib/mysql/*

Si tu dois libérer immédiatement, le meilleur « quick win » peut être ailleurs : logs, caches, journald, docker.

---

Étape 6 : repérer les causes racines (sinon ça revient demain)

Une fois que tu as récupéré de l’espace, tu veux répondre à une question simple : pourquoi /var a explosé ?

Quelques causes typiques :

• Un service en erreur qui spamme les logs.
• Journald sans limite.
• Docker qui garde des images et des layers non utilisés.
• Une application qui écrit des fichiers temporaires sans purge.
• Un agent (monitoring, backup, CI) qui déverse des artefacts.
• Un spool mail qui se remplit (postfix) à cause d’un problème SMTP.

Donc, après nettoyage :

bash sudo du -xhd1 /var | sort -h sudo journalctl -p err -n 200 sudo systemctl --failed

Tu cherches le truc anormal. Souvent, c’est évident quand tu le vois.

---

Le mode panique : quand le disque est à 100 % et que plus rien ne marche

Quand / ou /var est à 100 %, certains services ne peuvent même plus écrire un fichier PID, un socket, ou une rotation de log. Il faut libérer un minimum, vite.

Voilà un plan simple :

1. Trouver les gros fichiers :

bash sudo find /var -xdev -type f -size +500M -ls | sort -k7 -n | tail -20

2. Tronquer un ou deux logs énormes :

bash sudo truncate -s 0 /var/log/syslog 2>/dev/null || true sudo truncate -s 0 /var/log/messages 2>/dev/null || true

3. Nettoyer cache apt :

bash sudo apt-get clean

4. Si journald est énorme :

bash sudo journalctl --vacuum-size=200M

5. Relancer le service qui tenait un fichier supprimé :

bash sudo lsof +L1 | head -50

Puis systemctl restart ... sur le process concerné.

Ce n’est pas élégant, mais ça remet de l’air.

---

Pour éviter ces situations désastreuses à l'avenir et améliorer la performance de ton serveur Linux, il serait bénéfique de comparer les systèmes d'exploitation comme Linux et Windows. Une analyse approfondie sur ce sujet pourrait fournir des informations précieuses.

De plus, si ton serveur devient lent malgré toutes ces optimisations, il peut être utile de faire une autopsie d'un serveur lent pour identifier

Images utiles (à intégrer dans l’article)

Tu peux insérer ces images pour rendre l’article plus visuel. Sur WordPress, tu peux soit uploader tes propres captures, soit utiliser des visuels existants.

Exemple de capture : analyser l’espace disque

Exemple de capture : journald et logs

Exemple de capture : Docker cleanup

---

Checklist finale : ce que tu peux nettoyer sans te faire peur

• /var/cache/apt via apt-get clean
• journald via journalctl --vacuum-size=… ou --vacuum-time=…
• rotation forcée via logrotate -f
• /var/tmp (idéalement les anciens fichiers)
• ressources Docker via docker system prune (en comprenant l’impact)

Et ce que tu touches avec prudence :

• /var/lib/* (surtout bases de données, docker volumes, données applicatives)
• /var/spool/* (mail, cron, impression)
• tout fichier dont un service dépend explicitement

---

Conclusion (et petite suite logique)

Nettoyer /var, ce n’est pas « supprimer des trucs ». C’est plutôt : mesurer, identifier, libérer proprement, puis empêcher la récidive.

Si tu veux, tu peux faire un mini rituel mensuel sur tes serveurs :

• vérifier df -h
• vérifier journalctl --disk-usage
• vérifier docker system df
• vérifier que logrotate tourne

Ça prend 5 minutes, et ça évite les pannes idiotes.

Et si ce guide t’a été utile, passe sur Le Blog Tech Pro de Samyn-Antoy ABASSE (https://monblog-sa-abasse.blogspot.com). J’y publie aussi des articles Linux orientés terrain, avec ce côté « on veut que ça marche, maintenant, et proprement ».

Questions fréquemment posées

Pourquoi la partition /var grossit-elle souvent et cause des problèmes de disque plein ?

La partition /var contient des dossiers vivants comme les logs (/var/log), les caches (/var/cache), les bases de données et conteneurs (/var/lib), ainsi que des fichiers temporaires. Ces éléments peuvent rapidement occuper beaucoup d'espace, notamment si un service boucle ou si les logs ne sont pas nettoyés régulièrement.

Comment vérifier si la partition /var est pleine et identifie ce qui prend de la place ?

Utilisez la commande 'df -h' pour vérifier l'espace disque et 'df -ih' pour les inodes. Ensuite, avec 'sudo du -xhd1 /var | sort -h', vous pouvez voir quels sous-dossiers de /var occupent le plus d'espace. Vous pouvez approfondir dans /var/log, /var/lib, ou /var/cache selon les résultats.

Quels fichiers dans /var sont souvent responsables d'une consommation excessive d'espace ?

Les gros fichiers comme les logs volumineux dans /var/log, les caches dans /var/cache, ou encore les bases de données et conteneurs dans /var/lib peuvent être responsables. On peut aussi trouver des fichiers ouverts mais supprimés qui continuent à occuper de l'espace jusqu'au redémarrage du service.

Quelle est une méthode sûre pour nettoyer le cache APT dans /var/cache sans risquer de casser le système ?

Sur Debian ou Ubuntu, utilisez les commandes : 'sudo apt-get clean' pour supprimer tous les paquets en cache, 'sudo apt-get autoclean' pour supprimer les paquets obsolètes, et 'sudo apt-get autoremove --purge' pour enlever les dépendances inutiles. Cela libère souvent beaucoup d'espace sans risque.

Comment gérer efficacement le nettoyage des logs système dans /var/log sans provoquer d'erreurs ?

Commencez par vérifier la taille des logs avec 'sudo du -sh /var/log/*'. Pour systemd-journald, utilisez 'journalctl --disk-usage' puis nettoyez avec 'sudo journalctl --vacuum-time=7d' pour ne garder que 7 jours de logs. Évitez de supprimer manuellement les fichiers ouverts par des services actifs.

Que faire si un fichier log supprimé continue à consommer de l'espace disque ?

Cela signifie qu'un processus garde encore le fichier ouvert. Utilisez 'sudo lsof +L1 | grep '/var'' pour identifier ces fichiers. Pour libérer l'espace, il faut redémarrer le service concerné afin que le fichier soit réellement fermé et l'espace libéré.