Un disque plein peut arrêter votre activité : les alertes utiles

Un disque plein peut empêcher une commande d’être enregistrée, un document d’être déposé ou une sauvegarde de se terminer. Le serveur reste parfois accessible, mais les opérations utiles échouent. Pour une petite entreprise, surveiller le stockage consiste donc à protéger la continuité du service, pas simplement à afficher un pourcentage dans un tableau technique.

Identifier les espaces réellement critiques

Un serveur peut disposer de plusieurs volumes : système, base de données, fichiers clients et sauvegardes. De l’espace libre sur l’un ne compense pas forcément la saturation d’un autre. Commencez par associer chaque stockage aux services qui en dépendent.

Listez également ce qui grossit : journaux, pièces jointes, exports, copies temporaires ou historiques d’exécution. Un incident applicatif peut produire beaucoup de logs en peu de temps. Ajouter de la capacité sans comprendre la croissance peut seulement repousser le même incident.

Regarder la vitesse de remplissage

Un seuil unique ne raconte pas toute l’histoire. Dans un exemple fictif, dix gigaoctets libres peuvent offrir plusieurs mois de marge à un petit site, mais seulement quelques heures à un traitement vidéo. La capacité restante doit être rapprochée du rythme de consommation et du délai nécessaire pour intervenir.

Surveillez aussi les ressources qui limitent la création de fichiers, notamment les inodes sur les systèmes concernés. Une accumulation de très petits fichiers peut bloquer de nouvelles écritures même si des octets restent disponibles. L’alerte doit aider à comprendre quelle limite approche, pas seulement annoncer que « le disque va mal ».

Encadrer les journaux et les fichiers temporaires

Définissez une politique de conservation adaptée aux besoins de diagnostic et aux obligations applicables. Pour les systèmes utilisant journald, la documentation systemd décrit des limites d’occupation et d’espace à conserver libre. Les paramètres effectifs sont à vérifier sur la version installée ; ils ne couvrent pas automatiquement les journaux propres à toutes les applications.

Évitez le nettoyage aveugle. Un volume présenté comme inutilisé peut contenir des données nécessaires à une restauration. Avant suppression, identifiez son propriétaire, son usage et la possibilité de récupération. Des règles de rotation maîtrisées sont préférables à une commande d’urgence copiée sans contexte.

Faire arriver l’alerte à quelqu’un qui peut agir

Une notification utile précise le serveur, le volume, la marge restante et les services menacés. Elle renvoie vers une procédure courte : vérifier la croissance, identifier la cause et choisir une action réversible. Désignez aussi une personne de secours si le responsable habituel est absent.

Le canal d’alerte ne devrait pas dépendre uniquement du serveur surveillé. Si sa messagerie ou son automatisation tombe avec lui, le silence donne une fausse impression de calme. Cette approche complète la surveillance des outils métier, qui part des conséquences visibles pour l’activité.

Vérifier la reprise, pas seulement la place libérée

Après intervention, contrôlez qu’une opération métier fonctionne à nouveau : écriture dans la base, dépôt de fichier ou génération de document. Certains services restent en erreur après avoir retrouvé de l’espace. Le retour à un pourcentage rassurant ne prouve pas leur rétablissement.

Recherchez ensuite pourquoi la situation s’est produite et ajustez la capacité ou la conservation. Une infrastructure Linux maîtrisée repose sur ces détails peu spectaculaires : de la marge, des alertes actionnables et une procédure comprise. C’est souvent là que se joue la différence entre un incident bref et une journée de travail perdue.