Un disque plein à 100 % est pire qu'il n'y paraît : la base de données refuse les écritures, le site renvoie des erreurs 500, et même les journaux cessent d'enregistrer — vous laissant aveugle. Voici une procédure standard, de la localisation au nettoyage.

Étape 1 : évaluer globalement

Exécutez df -h pour voir l'utilisation par partition et confirmer si c'est la partition racine ou un point de montage qui est plein. Si les inodes sont épuisés (df -i affiche 100 %) alors qu'il reste de l'espace, vous avez un problème de fichiers minuscules — même approche, mais cherchez les répertoires au nombre de fichiers énorme.

Étape 2 : localiser les gros répertoires

Descendez depuis la racine : du -h --max-depth=1 / 2>/dev/null | sort -rh | head. Entrez dans le plus gros répertoire et répétez — deux ou trois tours suffisent à cibler le coupable.

Les cinq suspects habituels

  • Journaux : les logs sous /var/log et ceux écrits par vos applications. Réduisez le journal système avec journalctl --vacuum-size=200M et configurez logrotate pour les logs applicatifs ;
  • Docker : images orphelines et cache de build consomment énormément — inspectez avec docker system df, nettoyez avec docker system prune (vérifiez que rien d'utilisé ne sera supprimé) ;
  • Vieilles sauvegardes : les scripts qui ajoutent sans jamais supprimer remplissent un disque en quelques mois — ajoutez une politique de rétention ;
  • Caches de paquets : apt clean libère les caches de téléchargement ;
  • Fichiers supprimés mais ouverts : l'espace n'est pas libéré tant qu'un processus détient le descripteur d'un fichier supprimé — trouvez-le avec lsof | grep deleted et redémarrez ce processus.

Deux règles d'or pour le nettoyage

Premièrement, regardez avant de supprimer : confirmez l'usage d'un fichier — ne faites jamais rm sur des répertoires de base de données ou des journaux en cours d'écriture. Deuxièmement, tronquez les gros fichiers actifs au lieu de les supprimer : vider un log actif avec truncate -s 0 est plus sûr que le supprimer. Ensuite, configurez une alerte d'utilisation disque (avertir au-delà de 80 %) pour que le prochain incident n'atteigne jamais 100 %.