Objectif
Rétablir une marge de sécurité sur un filesystem Linux saturé en déterminant d’abord si la pénurie concerne les blocs ou les inodes, en identifiant les vrais consommateurs, en libérant uniquement des données maîtrisées et en corrigeant la croissance ou la rétention responsable de l’incident.
Prérequis
- Accès sudo/root et identification du filesystem réellement saturé.
- Connaissance des services critiques stockant leurs données sur ce volume.
- Sauvegarde ou politique de rétention pour les données qui pourraient être supprimées.
- Fenêtre de maintenance si un service doit être redémarré pour libérer un fichier ouvert.
- Seuil de marge à rétablir et alerte de supervision à mettre en place après incident.
Procédure pas à pas
Confirmer le filesystem et le type de saturation
Commencez par df -hT et df -i. Identifiez le point de montage, le type de filesystem et si le problème vient de l’espace ou des inodes. Vérifiez aussi les mounts afin de ne pas analyser /var alors qu’un sous-répertoire est un volume distinct.
df -hTdf -ifindmnt- Le point de montage critique et le type de ressource manquante sont connus.
Repérer les gros répertoires au bon niveau
Utilisez du sur le filesystem concerné avec -x pour ne pas traverser d’autres mounts. Commencez large puis descendez dans les répertoires volumineux. Évitez un find récursif massif sur un serveur en difficulté si le stockage est déjà très sollicité.
sudo du -xhd1 /var 2>/dev/null | sort -hsudo du -xhd1 / 2>/dev/null | sort -h- Les principaux consommateurs sont identifiés sans mélanger plusieurs filesystems.
Chercher les fichiers supprimés mais encore ouverts
Si df indique beaucoup plus d’espace utilisé que du, recherchez les fichiers marqués deleted encore ouverts. Un service de log ou une application peut conserver un descripteur vers un ancien fichier géant. Redémarrez ou rechargez uniquement le processus concerné selon la procédure de l’application.
sudo lsof +L1- Tout espace retenu par un fichier supprimé est attribué à un processus précis.
Mesurer journald et les logs
Contrôlez l’espace du journal systemd et les répertoires /var/log. Pour journald, utilisez les options de vacuum supportées plutôt que rm dans /var/log/journal. Pour rsyslog ou une application, préférez logrotate
journalctl --disk-usagesudo du -sh /var/log/* 2>/dev/null | sort -hsudo logrotate -d /etc/logrotate.conf- Les logs responsables et leur mécanisme de rotation sont connus.
Nettoyer uniquement les données maîtrisées
Supprimez caches, archives ou logs anciens uniquement si leur rétention le permet. Avec journalctl, –vacuum-time ou –vacuum-size cible les journaux archivés. Ne videz pas un journal actif sans justification, surtout si l’incident peut nécessiter une investigation.
sudo journalctl --vacuum-time=30dsudo journalctl --disk-usage- Une marge est récupérée sans perte incontrôlée de données.
Vérifier Docker ou conteneurs
Sur un hôte Docker, images, build cache, volumes et logs JSON peuvent consommer beaucoup d’espace. Commencez par docker system df. Ne lancez pas docker system prune -a –volumes sur un serveur de production sans inventaire : des images nécessaires au rollback ou des volumes non montés peuvent être supprimés.
docker system df -vsudo du -sh /var/lib/docker/* 2>/dev/null | sort -h- La consommation Docker est comprise avant toute purge.
Traiter les inodes si nécessaire
Si df -i est à 100 %, recherchez les répertoires contenant des millions de petits fichiers : sessions, queues, cache, mail, tmp ou application. Comptez progressivement plutôt que de lancer une commande coûteuse sur tout le disque. Corrigez ensuite la politique qui crée ces fichiers.
sudo find /var/tmp -xdev -type f | wc -lsudo find /tmp -xdev -type f | wc -l- La saturation d’inodes est rattachée à un répertoire ou une application.
Agrandir le filesystem si la croissance est légitime
Si les données doivent être conservées, la bonne correction peut être d’étendre le volume, le LV ou le filesystem plutôt que de supprimer. Vérifiez la couche stockage, partition/LVM puis la commande d’extension spécifique au filesystem. Ne réduisez pas ou ne redimensionnez pas à l’aveugle pendant l’incident.
lsblk -fsudo pvs; sudo vgs; sudo lvs- La capacité structurelle est adaptée à la croissance réelle.
Prévenir la récidive
Ajoutez des seuils sur espace et inodes, corrigez logrotate/journald, les limites Docker et les rétentions applicatives. Documentez le volume, sa croissance quotidienne et le niveau critique. Un nettoyage manuel récurrent indique un problème d’exploitation à corriger.
- Une alerte prévient avant la prochaine saturation et la cause de croissance est maîtrisée.
Validation
La procédure est validée lorsque :
- df -hT et df -i montrent une marge suffisante sur le filesystem concerné.
- Les services critiques fonctionnent et aucun fichier métier n’a été supprimé sans validation.
- La cause de croissance ou de rétention est identifiée et corrigée.
- La supervision alerte désormais sur blocs et inodes.
Retour arrière
- Restaurer depuis sauvegarde tout fichier supprimé par erreur.
- Si un service a été redémarré, vérifier sa configuration et ses données avant de poursuivre les purges.
- Annuler les nouvelles politiques de purge si elles suppriment trop de données.
- Si une extension de volume échoue, arrêter et revenir au plan stockage supporté plutôt que tenter une réduction.
Dépannage / erreurs fréquentes
- df plein mais du ne retrouve pas l’espace : lancer lsof +L1 et vérifier les mounts/snapshots.
- Inodes à 100 % : chercher des millions de petits fichiers plutôt que de gros logs.
- /var/lib/docker énorme : utiliser docker system df avant toute prune.
- journalctl –vacuum libère peu : seuls les journaux archivés éligibles sont purgés ; vérifier les fichiers actifs et la configuration.
- Espace revient puis disparaît vite : surveiller la croissance par service et corriger la source, pas seulement la conséquence.