Commandes Linux essentielles : du et df pour surveiller l’espace disque

Temps de lecture : 13 min

Votre serveur Linux semble lent ou refuse d’écrire de nouveaux fichiers : savez-vous si le problème vient réellement de l’espace disque, des inodes ou d’un répertoire qui grossit sans contrôle ? En administration système Linux, cette distinction évite des interventions inutiles et limite le risque de coupure. Une supervision serveur Linux open source bien pensée commence par des indicateurs simples, compréhensibles et vérifiables. Pour une infrastructure informatique en production, les commandes df et du offrent justement une méthode rapide pour séparer la capacité disponible de l’origine de l’occupation.

Une partition saturée peut empêcher une application d’écrire ses journaux, bloquer une base de données, faire échouer une sauvegarde ou compliquer la protection des données. Il ne faut pourtant pas supprimer des fichiers dès la première alerte. La démarche fiable consiste à observer l’état global, vérifier les inodes, isoler le point de montage concerné, puis analyser seulement le répertoire utile. Cette progression réduit l’impact sur les services et laisse une trace exploitable pour l’administration système et réseau.

Comprendre ce que mesurent df et du sur un serveur Linux

Les deux commandes répondent à des questions différentes. df, pour disk free, interroge les systèmes de fichiers montés. Il indique la taille de chaque partition ou volume, la part utilisée, la place encore disponible et le pourcentage d’occupation. C’est la commande à lancer en premier lorsqu’une alerte remonte depuis un outil de supervision ou qu’un service ne peut plus créer de fichier.

du, pour disk usage, parcourt quant à lui les répertoires et les fichiers accessibles dans un chemin donné. Il ne dit pas immédiatement quelle partition est critique à l’échelle du serveur ; il aide à comprendre ce qui consomme la place une fois la partition identifiée. Employer du sur tout le système sans objectif peut être long, générer beaucoup de sorties et perturber la lisibilité du diagnostic. Son intérêt augmente lorsque le périmètre est précis, par exemple /var/log, /var/lib, un répertoire applicatif ou un espace utilisateur.

Différencier espace disponible, espace utilisé et inodes

La capacité libre ne résume pas toujours la santé d’un système de fichiers. Un volume peut afficher plusieurs gigaoctets disponibles tout en refusant la création de nouveaux fichiers. Ce cas survient lorsque les inodes sont épuisés. Un inode représente les métadonnées d’un fichier : propriétaire, droits, dates, emplacement des blocs et autres informations techniques. Chaque fichier et chaque répertoire consomme généralement un inode.

Les inodes sont particulièrement importants sur des serveurs qui hébergent un très grand nombre de petits fichiers. Cela peut concerner un cache applicatif mal maîtrisé, des sessions Web, des fichiers temporaires, des artefacts de développement web, une boîte de réception de traitement automatisé ou des journaux découpés de façon excessive. df -i affiche la disponibilité des inodes par système de fichiers. Une colonne d’utilisation proche de 100 % doit déclencher une investigation, même si df -h montre encore de l’espace en gigaoctets.

Il faut également interpréter les points de montage. Un serveur peut présenter une racine /, une partition /var, un volume de données, un montage réseau ou un volume persistant de conteneur. Un taux élevé sur /var ne se traite pas comme une saturation de /home. Les services concernés, les sauvegardes, les droits d’accès et la possibilité de restaurer les données ne sont pas les mêmes.

Choisir des unités lisibles pour un diagnostic rapide

La forme brute de df utilise des blocs peu confortables à lire pendant un incident. L’option -h convertit l’affichage dans des unités adaptées, telles que Mio ou Gio. La commande df -hT ajoute le type de système de fichiers, ce qui facilite l’interprétation d’un montage ext4, XFS, tmpfs, NFS ou overlay. Cette information peut orienter la suite du diagnostic, notamment lorsque Docker, une machine virtuelle ou un stockage distant est impliqué.

Une bonne habitude consiste à comparer l’état présent à l’état habituel. Une partition à 82 % n’est pas automatiquement critique : elle peut être stable depuis des mois ou avoir augmenté de vingt points en quelques heures. La valeur utile dépend de la taille du volume, de sa vitesse de croissance, de son rôle métier et de l’espace nécessaire à une restauration ou à une rotation de journaux. Dans une exploitation sérieuse, le seuil est donc documenté par point de montage plutôt qu’appliqué uniformément à tout le serveur.

Diagnostiquer une saturation avec du et df sans perturber la production

Lorsqu’une alerte apparaît, la priorité est de protéger le service et de collecter des faits. Connectez-vous avec un compte autorisé, en appliquant les principes de gestion des accès SSH sécurisée : authentification forte, traçabilité, droits limités et accès administrateur temporaire si nécessaire. Évitez de lancer des commandes destructrices sous pression. Un diagnostic de stockage fiable reste progressif, même lorsqu’un incident est en cours.

Repérer la partition saturée avec df -hT

Commencez par df -hT. Cette commande fournit une cartographie concise des systèmes de fichiers montés et de leur occupation. Repérez le taux élevé, le point de montage et le type de système de fichiers. Un tmpfs saturé n’implique pas les mêmes actions qu’un volume de données local ; un partage NFS peut nécessiter une vérification côté stockage ; un système overlay peut signaler une croissance liée aux conteneurs.

Examinez ensuite les inodes avec df -i. Si l’espace bloc est disponible mais que les inodes sont presque épuisés, cherchez des ensembles de petits fichiers plutôt qu’un gros fichier. Les répertoires de cache, les sessions, les files de messages, les traces de compilation et les répertoires temporaires sont alors des candidats plus probables que les sauvegardes volumineuses.

Pour réduire le bruit, ciblez un point de montage : df -hT /var ou df -hT /srv. Cette vérification est utile après une action de remédiation, car elle confirme si l’espace a réellement été rendu au système de fichiers attendu. Elle évite également de confondre un répertoire visible dans l’arborescence avec un volume monté séparément.

Identifier les répertoires les plus lourds avec du

Une fois la partition repérée, utilisez du sur le chemin correspondant. Pour obtenir une première vue des sous-répertoires immédiats, une commande telle que du -xh –max-depth=1 /var est souvent plus adaptée qu’un parcours intégral. L’option -h améliore la lecture, -x évite de franchir les systèmes de fichiers montés, et la profondeur limitée empêche une sortie trop détaillée.

Vous pouvez ensuite trier les résultats avec sort -h. Par exemple, du -xh –max-depth=1 /var | sort -h fait remonter progressivement les emplacements les plus lourds. Pour une lecture descendante, utilisez sort -hr. Cette méthode doit être répétée à l’intérieur du répertoire problématique, pas appliquée aveuglément à toute l’arborescence. Si /var/lib est responsable, analysez ensuite /var/lib, puis le sous-répertoire concerné.

La précision du périmètre est importante pour la disponibilité. Sur une machine chargée, un parcours massif peut mobiliser des entrées-sorties et ralentir d’autres traitements. Il est souvent préférable de commencer par une profondeur faible, de noter les résultats, puis de resserrer l’analyse. Sur un serveur très actif, exécutez si possible l’investigation en dehors d’un pic d’activité ou utilisez les métriques historiques déjà disponibles dans la supervision.

Trier les résultats et examiner les journaux, caches et volumes applicatifs

Les causes récurrentes se situent souvent dans /var/log, /var/cache, /tmp, /var/lib ou les répertoires de données applicatives. Des journaux qui augmentent rapidement peuvent révéler une boucle d’erreur, un niveau de verbosité inadapté ou une rotation défaillante. Un cache de paquets peut être nettoyable, mais seulement selon les procédures de la distribution et après validation de la politique de mise à jour.

Les environnements de conteneurs demandent une attention spécifique. Les conteneurs Docker en production bonnes pratiques imposent de connaître l’emplacement des volumes, des images, des couches et des journaux avant toute intervention. Un répertoire sous /var/lib/docker peut contenir des données persistantes essentielles. Une suppression improvisée peut rendre une application indisponible ou compromettre une restauration. Vérifiez l’inventaire des services, la politique de rétention, les sauvegardes et les volumes utilisés avant de retirer une ressource.

Le choix entre Kubernetes ou Docker Compose pour PME influence également l’emplacement et la gouvernance du stockage. Avec Docker Compose, les volumes et journaux peuvent être plus simples à relier à un service précis. Avec Kubernetes, les volumes persistants, les images de nœud et les journaux de pods nécessitent une lecture plus distribuée. Dans les deux cas, l’administration système Linux doit distinguer l’espace local du nœud de l’espace alloué aux applications et du stockage distant.

Éviter les conclusions hâtives sur Docker, les sauvegardes et les données supprimées

Ne supprimez pas directement un journal, une archive, un volume ou une sauvegarde parce qu’il apparaît volumineux. Commencez par déterminer son propriétaire, sa fonction, sa période de rétention et son lien éventuel avec un service actif. Une archive ancienne peut être la dernière copie récupérable d’une base de données. Un fichier log très grand peut être surveillé par une procédure de conformité. Un volume Docker peut contenir les données de production d’une application.

Un autre cas fréquent concerne les fichiers supprimés mais toujours ouverts par un processus. Ils peuvent ne plus apparaître dans un parcours du, tout en occupant encore de l’espace pour le système de fichiers. Si df indique une utilisation élevée alors que du ne retrouve pas la même quantité, recherchez les processus concernés avec les outils autorisés par votre procédure d’exploitation, puis planifiez une relance contrôlée du service. Redémarrer sans analyse peut aggraver un incident ou effacer des éléments nécessaires à sa compréhension.

Avant un nettoyage, formalisez l’action : élément concerné, taille attendue, propriétaire, sauvegarde disponible, commande prévue, fenêtre de changement et contrôle après intervention. Cette discipline facilite la protection des données et crée un historique utile lors d’un incident similaire. Elle est aussi compatible avec des pratiques d’automatisation, car une action manuelle bien documentée devient plus facile à transformer ensuite en contrôle fiable.

Automatiser la surveillance de l’espace disque dans une exploitation Linux fiable

Une surveillance efficace ne consiste pas à envoyer une alerte pour chaque variation. Elle doit produire une information actionnable, liée à une responsabilité et à une procédure claire. La routine peut débuter avec des commandes simples, des rapports réguliers et un historique léger. Les outils open source pour administrateur système sont utiles lorsqu’ils réduisent le délai entre le symptôme et la décision, sans multiplier les faux positifs.

Définir des seuils d’alerte cohérents par point de montage

Définissez les seuils selon le rôle du point de montage. Une partition qui reçoit des sauvegardes temporaires peut nécessiter une marge plus importante qu’un volume d’archives peu évolutif. Une base de données, un serveur de logs ou une plateforme de virtualisation exigent généralement une anticipation plus précoce, car une saturation peut empêcher les écritures critiques et ralentir la reprise.

Un premier seuil peut ouvrir une investigation : analyse de tendance, contrôle des inodes et identification du service à l’origine de la hausse. Un second seuil peut déclencher une escalade : création de capacité, rotation contrôlée, déplacement de données ou intervention planifiée. Le seuil final correspond au risque de rupture de service et doit être relié à une procédure d’urgence. Ce modèle est plus utile qu’un unique pourcentage appliqué indistinctement à tous les serveurs.

Surveillez aussi la vitesse de croissance. Une partition à 70 % qui gagne 10 % par jour est souvent plus préoccupante qu’une partition à 88 % stable depuis plusieurs mois. L’historique facilite cette lecture et permet de prévoir une capacité supplémentaire avant l’incident. Il contribue aussi à une meilleure gestion des changements lors d’un déploiement applicatif ou d’une évolution de l’infrastructure informatique.

Intégrer df et du à une routine de supervision

Commencez par automatiser la collecte et non la suppression. Un rapport quotidien ou plusieurs contrôles par jour peuvent exécuter df -hT et df -i, puis comparer les résultats aux seuils définis. Lorsque l’écart dépasse un niveau d’investigation, lancez un du ciblé sur le point de montage et conservez une synthèse, plutôt qu’un inventaire complet difficile à exploiter.

Cette approche s’intègre naturellement à une supervision serveur Linux open source. Le système de monitoring peut vérifier le pourcentage d’occupation, les inodes, l’évolution dans le temps et la disponibilité d’un point de montage. Le rapport de diagnostic doit fournir le serveur, la partition, le type de système de fichiers, le seuil atteint, l’horodatage et la prochaine action attendue. Une alerte dépourvue de contexte retarde généralement la résolution.

Lorsque les procédures sont stabilisées, vous pouvez automatiser l’administration avec Ansible pour déployer les scripts de contrôle, standardiser les seuils, distribuer les fichiers de configuration et vérifier que les tâches planifiées sont présentes. L’automatisation doit rester idempotente et ne pas supprimer automatiquement des données applicatives sans validation. Le bon objectif est de rendre les vérifications répétables, pas de masquer les décisions risquées derrière un script.

Produire un rapport exploitable pour l’administration système et réseau

Un rapport utile est court, comparatif et orienté action. Il doit indiquer ce qui est normal, ce qui évolue et ce qui exige une décision. Pour chaque point de montage suivi, conservez le pourcentage d’espace, le pourcentage d’inodes, la taille libre, la tendance, le propriétaire technique et le niveau d’escalade. Ajoutez, lorsqu’une investigation est ouverte, le répertoire principal identifié par du et l’application ou le service associé.

Cette formalisation aide les équipes d’administration système et réseau à éviter les interventions redondantes. Elle donne aussi un contexte aux personnes qui ne connaissent pas l’historique du serveur. Un tableau de bord peut signaler une hausse, mais le compte-rendu d’exploitation explique pourquoi elle est tolérée, surveillée ou traitée. Conservez les informations sensibles dans les espaces prévus à cet effet et limitez les accès aux rapports contenant des détails d’infrastructure.

Relier surveillance, protection des données et plan de reprise d’activité informatique

La surveillance de capacité soutient directement la protection des données sur serveur Linux. Une sauvegarde ne vaut que si elle peut s’exécuter, être contrôlée et restaurée dans des conditions réalistes. Une partition pleine peut faire échouer une sauvegarde locale, interrompre une rotation de journaux ou empêcher une base de données de terminer une opération. Les contrôles de stockage doivent donc couvrir les répertoires de sauvegarde, les volumes temporaires et les espaces nécessaires à la restauration.

Intégrez ces contrôles au plan de reprise d’activité informatique. Documentez les seuils minimums avant restauration, les volumes à vérifier, les répertoires temporaires requis et les responsabilités de validation. Lors d’un test de reprise, contrôlez l’espace libre et les inodes avant de démarrer les opérations lourdes. Cette précaution évite de découvrir trop tard qu’un serveur de secours ne possède pas la capacité nécessaire pour recevoir les données ou générer les journaux attendus.

Mettre en place dès maintenant une routine courte : df -hT et df -i pour la vue globale, puis du ciblé uniquement lorsqu’un seuil ou une alerte le justifie. Utilisez df pour établir une vue fiable des systèmes de fichiers et des inodes. Utilisez du pour localiser méthodiquement les répertoires responsables de la consommation. Documentez enfin les seuils, les contrôles et les actions de remédiation avant qu’un incident ne touche la production.

❓ FAQ

Quelle est la différence entre df et du sous Linux ?

df affiche l’espace total, utilisé et disponible par système de fichiers monté. du mesure l’espace occupé par les fichiers et répertoires d’un chemin donné. Utilisez donc df pour identifier une partition saturée, puis du pour localiser les répertoires responsables.

Quelle commande utiliser pour voir l’espace disque disponible de façon lisible ?

Utilisez df -h pour afficher les tailles dans un format lisible. La commande df -hT est souvent préférable en exploitation, car elle ajoute le type de système de fichiers et facilite l’interprétation des points de montage.

Comment trouver les répertoires les plus volumineux sur un serveur Linux ?

Analysez d’abord la partition concernée avec df -hT, puis lancez une commande ciblée comme du -xh –max-depth=1 /var | sort -hr. Répétez l’analyse dans le sous-répertoire le plus volumineux. Vérifiez le rôle des données avant toute suppression.

Pourquoi vérifier les inodes avec df -i ?

Un système de fichiers peut manquer d’inodes avant de manquer d’espace en blocs. Dans ce cas, il ne peut plus créer de nouveaux fichiers, même si df -h affiche encore de la capacité libre. df -i permet de détecter cette situation, fréquente lorsqu’un serveur contient énormément de petits fichiers.

Comment surveiller l’espace disque en production sans créer d’alertes inutiles ?

Définissez des seuils par point de montage, surveillez aussi les inodes et la vitesse de croissance, puis associez chaque niveau d’alerte à une action précise. Utilisez du seulement lorsqu’un seuil ou une tendance justifie une investigation ciblée. Conservez un historique et une procédure d’escalade claire.

Mathias

Ingénieur systèmes et architecte cloud pendant 8 ans chez un leader européen de l’hébergement, reconverti dans l’analyse tech et business. Passionné par l’intersection entre infrastructure IT, IA générative et transformation digitale des entreprises. J’aide les décideurs et les équipes techniques à naviguer dans l’écosystème tech sans bullshit marketing.