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 -h
Si une partition dépasse ~80%, on creuse.
- Qui occupe la place à la racine ?
sudo du -h --max-depth=1 / | sort -hr | head -15
Souvent 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.conf
et ajoutez :Storage=persistent SystemMaxUse=500M SystemKeepFree=1G RuntimeMaxUse=200M SystemMaxFileSize=50M
Puis :
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 -delete
Astuce : remplacez
-delete
par-ls
pour 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 😉