Votre serveur crie “no space left on device” ? Pas de panique. Respirez ☺️ On va diagnostiquer en 30 secondes, nettoyer proprement, puis mettre 2–3 garde-fous pour éviter que ça revienne.
Diagnostic express (3 commandes, 30 secondes)
- Vue globale du disque
df -hSi une partition dépasse ~80%, on creuse.
- Qui occupe la place à la racine ?
sudo du -h --max-depth=1 / | sort -hr | head -15Souvent les gros sont /var, /home, /usr.
- Les suspects dans /var
sudo du -h --max-depth=1 /var | sort -hr | head -20/var/log (journaux), /var/lib (bases/containers), /var/cache (caches…)
Cas fréquents & solutions rapides
1) Journaux système (systemd-journal) qui gonflent
Symptôme : /var/log/journal pèse des centaines de Mo/Go.
- Alléger tout de suite (garder 200 Mo max) :
sudo journalctl --vacuum-size=200M - Mettre des bornes (perso, plafonds raisonnables) : éditez
/etc/systemd/journald.confet ajoutez :Storage=persistent SystemMaxUse=500M SystemKeepFree=1G RuntimeMaxUse=200M SystemMaxFileSize=50MPuis :
sudo systemctl restart systemd-journald
2) Logs d’application (Nginx/Apache/Node/etc.) déchaînés
Symptôme : un fichier .log unique fait plusieurs Go (ex. /var/log/nginx/access.log).
- Vider sans casser le service (le fichier reste ouvert) :
sudo truncate -s 0 /var/log/nginx/access.log - Activer la rotation automatique (logrotate, exemple Nginx) :
/var/log/nginx/*.log { daily rotate 14 size 50M compress delaycompress missingok notifempty copytruncate }
3) Snap qui empile des versions
- Supprimer les révisions désactivées :
snap list --all | awk '/disabled/{print $1, $3}' \ | while read pkg rev; do sudo snap remove "$pkg" --revision="$rev"; done - Limiter la rétention :
sudo snap set system refresh.retain=2
4) Cache APT inutile
- Nettoyage sûr :
sudo apt-get clean
5) Docker qui garde images/containers orphelins
⚠️ Attention : ces commandes suppriment ce qui n’est pas utilisé. À éviter en prod sans vérifier.
- État :
docker system df - Ménage (dangling & non utilisés) :
docker system prune -af docker volume prune -f
6) MySQL/MariaDB : binlogs et tables volumineuses
Symptôme : /var/lib/mysql grossit à cause des binary logs.
- Voir les binlogs (dans MySQL) :
SHOW BINARY LOGS; - Purges contrôlées (dans MySQL) :
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY); - Prévenir (my.cnf) :
binlog_expire_logs_seconds=604800 # 7 jours
7) Trop de petits fichiers (inodes saturés)
- Diagnostiquer :
df -i sudo bash -c 'for d in /var /home; do \ echo "--- $d ---"; sudo find "$d" -xdev -type f 2>/dev/null | wc -l; done' - Nettoyer un dossier qui génère des fichiers quotidiens (ex. logs d’une app maison, > 7 jours) :
sudo find /var/log/monapp -type f -mtime +7 -print -deleteAstuce : remplacez
-deletepar-lspour vérifier avant de supprimer.
8) /tmp & coredumps
- Nettoyer /tmp (géré par systemd-tmpfiles, forcer une passe) :
sudo systemd-tmpfiles --clean - Voir et purger les coredumps :
coredumpctl list sudo coredumpctl purge
9) Vieux kernels (si /boot est plein)
- Nettoyage sûr :
sudo apt autoremove --purge
Prévenir la récidive (2 minutes chrono)
- Mettre des limites à journald (voir plus haut).
- Activer/ajuster logrotate pour vos services bruyants (web, apps, bots).
- Créer un alias “checkdisk” pour un contrôle éclair :
echo "alias checkdisk='df -h; echo; sudo du -h --max-depth=1 / | sort -hr | head -15; echo; sudo du -h --max-depth=1 /var | sort -hr | head -20'" \ >> ~/.bashrc && source ~/.bashrc
FAQ express
“Tronquer un log, ça casse mon service ?”
Non. truncate -s 0 garde le fichier ouvert et vide. Votre service continue d’écrire dedans.
“Et mes données (scores, bases, etc.) ?”
Ne supprimez que les logs (.log) ou caches. Vos données (ex. .json, .db) sont ailleurs : ne les ciblez pas.
“Je peux automatiser ?”
Oui : logrotate + limites journald suffisent souvent. Le reste : un check manuel régulier avec l’alias checkdisk.
C’était utile ?
Si ce guide vous a dépanné, laissez un petit commentaire — ça motive à publier d’autres tutos 😉
