Disque plein sous Linux : libérez de l'espace sans casser

Votre serveur Linux n’écrit plus, et quelqu’un propose de vider /var/log pour le relancer. Voici comment récupérer de l’espace sans transformer une saturation en perte de données.

Je commencerais par une question : quel chemin l’application n’arrive-t-elle plus à écrire ? Le nom du serveur ne suffit pas. Une machine peut avoir de la place sur son disque système et une partition applicative pleine. Les commandes ci-dessous visent un environnement GNU/Linux ; adaptez les chemins et les droits à votre serveur.

Repérez ce qui manque avant de chercher quoi effacer

Relevez l’erreur exacte, le chemin concerné et l’heure du premier échec. Faites ensuite exécuter ces contrôles en lecture seule, ici pour une application installée dans /var :

df -h /var
df -i /var

La première commande montre l’espace du système de fichiers contenant ce chemin. La seconde examine les inodes, ces structures nécessaires pour décrire les fichiers. La documentation GNU de df détaille les deux mesures. Une accumulation de petits fichiers peut épuiser les inodes alors que des blocs restent disponibles.

Notez le point de montage affiché. Nettoyer /tmp ne changera rien à une partition /var séparée. Si les mesures ne montrent aucune saturation, examinez les quotas et le message applicatif avant de poursuivre. Un défaut d’autorisation ne se répare pas en supprimant des archives.

Gardez ces résultats dans le dossier d’incident. Ils serviront à vérifier le gain obtenu sur le bon volume.

Faites nommer le propriétaire des fichiers volumineux

Sur le chemin confirmé, descendez progressivement dans les répertoires :

sudo du -x -h --max-depth=1 /var

Avec GNU du, -x évite de parcourir les répertoires situés sur d’autres systèmes de fichiers. --max-depth=1 limite la profondeur de l’affichage, pas celle du parcours. La documentation GNU de du décrit ces options. Sur un serveur déjà chargé, ciblez le répertoire suspect : l’analyse doit lire ses métadonnées et peut prendre du temps.

Pour chaque gros répertoire, demandez : quelle application l’alimente, qui sait interpréter son contenu, quelle procédure autorise son nettoyage ? Un nom contenant old, backup ou temp ne répond à aucune de ces questions.

Ne supprimez jamais directement les fichiers internes d’une base pour gagner de la place. Si personne ne sait qualifier leur rôle, préparez une extension maîtrisée ou une interruption convenue avec le métier.

Nettoyez les journaux avec leur mécanisme de gestion

Pour le journal systemd, commencez par mesurer :

sudo journalctl --disk-usage

La documentation de journalctl distingue les fichiers actifs des fichiers archivés. Les options --vacuum-size et --vacuum-time purgent les archives. La mesure --disk-usage, elle, inclut aussi les fichiers actifs. Une purge peut donc laisser un total supérieur à la taille demandée.

Faites choisir la limite selon les traces nécessaires au diagnostic et les règles de conservation de l’entreprise. Si une investigation est en cours, faites valider ce qui peut disparaître. Vérifiez ensuite que les événements récents sont toujours enregistrés.

Les journaux propres à une application peuvent suivre une autre procédure. Demandez au mainteneur comment déclencher leur rotation et leur réouverture. N’appliquez pas à toute l’arborescence une commande trouvée pour un seul service.

Astuce : ajoutez à la fiche d’exploitation le chemin, le producteur, la règle de conservation et la commande de nettoyage validée. Le prochain intervenant pourra agir sans deviner ce que signifie le nom du fichier.

Expliquez l’espace qui ne revient pas après suppression

Un journal a disparu du répertoire, mais le volume reste plein ? Un processus peut encore garder le fichier ouvert. Le manuel Linux de unlink précise que, même après suppression du dernier nom, le fichier subsiste jusqu’à la fermeture du dernier descripteur ouvert.

Faites identifier le processus et le fichier concernés par l’administrateur. Ne redémarrez pas tous les services pour tester cette hypothèse. Cherchez d’abord la procédure de réouverture des journaux ; si un redémarrage est nécessaire, préparez-le avec le responsable applicatif.

Un écart entre df et du ne suffit pas à prouver cette cause. Vérifiez aussi le périmètre parcouru et les erreurs d’accès de l’analyse. Conservez les sorties complètes plutôt qu’une capture limitée au total.

Après correction, relancez la mesure sur le même chemin. Un fichier disparu n’est pas une preuve d’espace récupéré. Contrôlez également que l’application écrit encore ses journaux au bon endroit.

Refusez la purge Docker globale comme premier réflexe

Sur un hôte Docker, une commande de nettoyage peut toucher bien plus que des fichiers temporaires. La référence de docker system prune annonce notamment la suppression de conteneurs arrêtés, de réseaux inutilisés, d’images sans référence et de cache de construction. L’option --volumes ajoute les volumes anonymes inutilisés au périmètre.

Un conteneur arrêté peut correspondre à une intervention suspendue. Un volume détaché peut contenir des données encore nécessaires. Faites confirmer leur usage avant de valider la purge. Ne reprenez pas une commande avec --force pour éviter de lire sa confirmation.

Demandez aussi comment récupérer l’image nécessaire à un retour arrière. Si le registre est inaccessible, supprimer la copie locale peut compliquer la reprise. Préférez un nettoyage ciblé, validé avec le responsable du déploiement, puis mesurez le résultat.

Faites cette semaine un nettoyage dont vous pouvez prouver le résultat

Choisissez un serveur dont la croissance mérite une intervention, sans attendre le blocage. Faites remplir cette checklist par son responsable :

• Identifier le chemin, le montage, l’espace libre et les inodes disponibles.
• Attribuer les répertoires qui grossissent à leurs applications.
• Valider les éléments supprimables et les traces à conserver.
• Exécuter une action ciblée, puis relever le gain sur le même volume.
• Tester une écriture applicative autorisée et vérifier les traitements interrompus.
• Corriger la production excessive ou la conservation, avec un responsable et une échéance.

Reliez le suivi à vos alertes de supervision. Fixez le seuil selon le délai nécessaire pour intervenir et la croissance observée. Si une suppression suppose de pouvoir récupérer une archive, exigez une preuve issue d’un test de restauration.

Demandez enfin au mainteneur ce qui empêchera le même répertoire de remplir à nouveau le volume. Une réponse limitée à nettoyer plus souvent doit déboucher sur une tâche attribuée, pas sur la fermeture du ticket.