Disque plein ? Le grand nettoyage d'un homelab qui déborde

Je suis en formation TSSR, j'ai un homelab qui tourne depuis quelques mois — et l'autre jour, j'ai reçu l'alerte fatidique : plus d'espace. Rien de grave, mais assez pour que je doive sortir la truelle et faire le ménage. Voilà comment j'ai libéré plusieurs Go en une demi-heure, avec les vraies commandes qui ont marché.

1. Repérer ce qui bouffe l'espace

Premier réflexe : regarder où ça pèse vraiment. Pas de panique, on commence par scanner calmement :

df -h /
du -sh /home/fr33m1nd/* /home/fr33m1nd/.* | sort -rh | head -20

Le df -h te donne la vue macro : ta partition racine, son taux d'occupation.
Le deuxième coup détaille dossier par dossier — là tu vois direct les suspects : ~/.cache/, ~/.local/, ~/.npm/, ~/.bun/.

Dans mon cas, les trois gros consommateurs étaient :

• Les logs système (journald) qui avaient accumulé des centaines de Mo
• Les caches npm/bun qui ne sont jamais nettoyés automatiquement
• LM Studio — lourd et je ne l'utilisais plus

2. Nettoyer les logs système (journald facile)

Le piège avec journald c'est qu'il garde tout, indéfiniment, sans te prévenir. 10 secondes pour le remettre à la raison :

journalctl --vacuum-size=200M
journalctl --disk-usage

La première commande réduit les logs à 200 Mo. La deuxième vérifie que ça a marché. Pas de service à redémarrer, pas de fichier de conf à éditer — c'est instantané.

Pour que ça ne revienne pas, tu peux passer par journald.conf (SystemMaxUse=200M), mais le vacuum manuel suffit pour un coup d'urgence.

3. Purger les caches npm et bun

Si tu bricoles du Node.js ou du Bun, tu as probablement des caches qui prennent plusieurs centaines de Mo sans que tu t'en rendes compte :

du -sh ~/.npm/_cacache
npm cache ls | tail -3
du -sh ~/.bun/install/cache
bun pm cache rm

Dans mon cas, le cache Bun faisait à lui seul ~1.2 Go. Une fois nettoyé, la différence était immédiatement visible.

4. Désinstaller ce qui ne sert plus (LM Studio)

LM Studio, c'est pratique pour tester des modèles localement, mais une fois qu'on sait quel modèle on utilise, ça prend juste de la place :

du -sh ~/.lmstudio/*/

Si tu ne t'en sers plus, n'hésite pas à supprimer le dossier. Dans mon cas c'était un geste symbolique — depuis que je passe par Ollama pour les modèles légers et OmniRoute pour les autres, je n'y touche plus. 3 Go libérés d'un coup.

5. Auditer les gros dossiers qui trainent

Une fois les suspects habituels traités, un second passage plus fin permet de repérer les dossiers oubliés :

du -sh ~/.bun/*/ | sort -rh
du -sh ~/.cache/* ~/.local/* | sort -rh | head -15
du -sh ~/.config/*/ | sort -rh | head -15

Les outils comme fd ou ncdu sont pratiques, mais du -sh + sort -rh suffisent pour un audit rapide. L'idée c'est de repérer ce qui est anormalement volumineux.

6. Backups Fedora compressés

Un autre point que j'ai découvert en fouillant : mon script de backup Fedora générait des archives .tar.zst dans des volumes Docker — sans exclusion des caches. Résultat : les backups étaient aussi gros que les dossiers à sauvegarder.

J'ai ajusté les exclusions dans mon fedora-backup.sh (Brave cache, Chromium, npm) et ajouté une rotation automatique. Les backups sont passés de 5 Go à 1.5 Go.

Ce que j'en retiens

• Les logs et les caches sont les premiers bouffeurs d'espace — un nettoyage rapide tous les mois ou deux suffit
• Les outils qu'on n'utilise plus (LM Studio, vieux runtimes, SDKs) prennent souvent le plus de place
• Un homelab ça se nettoie comme un atelier — régulièrement, pas quand ça déborde

Les commandes sont simples, reproductibles, et ne cassent rien si on y va avec méthode. Si tu veux une procédure plus automatisée, un petit script hebdomadaire avec journalctl --vacuum-size=200M + bun pm cache rm + rotation des backups règle 90% du problème avant qu'il n'arrive.

Tags: homelab, linux, sysadmin, tutorial, storage Category: homelab | tutorial