Vérifier l'état de santé des disques d'un serveur dédié Linux avec SMART

Un disque dur ou un SSD ne tombe presque jamais en panne sans prévenir. Il émet des signaux pendant des semaines : secteurs réalloués, secteurs en attente de relecture, températures hors plage, tests internes qui échouent. Sur un serveur dédié, personne ne regarde ces signaux à votre place : c'est à vous de surveiller vos disques.

Ce tutoriel explique comment lire l'état de santé d'un disque avec SMART sur Linux, quels attributs regarder en priorité, comment lancer un autotest, comment automatiser l'alerte avec le démon smartd, et comment sortir les informations d'un disque caché derrière un contrôleur RAID.

SMART, ce que c'est et ce que ça dit vraiment

SMART, pour Self-Monitoring, Analysis and Reporting Technology, est un système intégré à la plupart des disques durs et SSD ATA/SATA, SCSI/SAS et NVMe. Sa raison d'être est double : surveiller la fiabilité du disque et anticiper les pannes, et exécuter différents types d'autotests internes. L'outil de référence sous Linux est smartctl, fourni par le paquet smartmontools, qui fonctionne aussi bien sur un serveur dédié que sur une machine de bureau.

Deux précisions qui évitent bien des malentendus. D'abord, SMART n'est pas une garantie : un disque peut passer tous ses tests et mourir d'un coup, et un disque qui affiche un ou deux secteurs réalloués peut tenir des années. Ensuite, SMART ne remplace jamais une sauvegarde : il sert à remplacer un disque avant la panne, pas à vous dispenser de copies de secours.

Disque physique, disque virtuel : la distinction qui décide de tout

Sur un serveur physique, smartctl interroge directement le disque branché au contrôleur. Sur les serveurs virtuels, en revanche, le disque visible depuis le système d'exploitation est un volume présenté par l'hyperviseur, par exemple KVM ou VMware : les compteurs SMART du matériel hôte ne sont, en général, pas accessibles depuis les machines virtuelles invitées. Vous pouvez donc installer les outils, mais ils n'auront rien à lire.

Conséquence pratique : la surveillance SMART telle que décrite ici vise les serveurs physiques, pas les machines issues d'une virtualisation. Cela dit, l'intérêt reste entier sur un serveur virtuel pour la partie applicative, et c'est souvent là que travaillent les administrateurs au quotidien : un disque qui sature, des bases de données qui grossissent trop vite, une mémoire ou des processeurs en tension se voient depuis l'intérieur de la machine, même si les compteurs du disque physique restent invisibles. La règle générale tient en une phrase : surveillez ce que vous pouvez voir, et laissez à votre hébergeur ce qui lui appartient.

Installer smartmontools et identifier ses disques

Les commandes de ce guide supposent un accès SSH à l'adresse IP de la machine, avec un compte disposant des droits root, directement ou via sudo. La première étape tient en une commande, le paquet est disponible dans tous les dépôts classiques :

sudo apt install smartmontools
smartctl --scan

Sur les distributions de la famille Red Hat, comme CentOS, Rocky Linux ou AlmaLinux, remplacez la première ligne par sudo dnf install smartmontools. La suite du guide ne change pas.

La sortie de --scan liste chaque disque avec son nom de périphérique et son protocole, ce qui évite de deviner. Sur une machine classique, vous verrez des noms de la forme /dev/sda pour un disque ATA/SATA ou SCSI/SAS, et /dev/nvme0 ou /dev/nvme0n1 pour un disque NVMe. Variante utile pour préparer une configuration de démon : smartctl --scan-open tente en plus d'ouvrir chaque disque, ce qui confirme qu'il est bien accessible avant d'écrire quoi que ce soit. Le paquet existe aussi pour les serveurs sous Windows, où le fichier de configuration du démon se trouve dans le répertoire d'installation plutôt que dans /etc.

Lire l'état de santé en une commande

Pour un contrôle rapide, trois niveaux de détail suffisent :

sudo smartctl -H /dev/sda
sudo smartctl -i /dev/sda
sudo smartctl -x /dev/sda

-H affiche le verdict de santé du disque, -i les informations d'identification et l'état d'activation de SMART, et -x imprime toutes les informations SMART et non SMART disponibles, attributs compris. Une option mérite d'être connue : -a, longtemps le réflexe de tout le monde, n'est plus recommandée sur les disques ATA, car elle n'active pas les options SMART qui nécessitent le support des commandes ATA 48 bits. Utilisez -x.

Si vous alimentez un outil de supervision ou un script, demandez directement du JSON plutôt que de parser du texte : smartctl -j -x /dev/sda renvoie une structure exploitable, et -q errorsonly réduit la sortie aux problèmes détectés. Avec -q silent, smartctl n'imprime plus rien du tout : le code de sortie devient la seule information disponible, ce qui est pratique dans une tâche planifiée mais inutilisable à la main. Dernier détail si vous administrez un serveur de jeu Windows : le même outil sert, seule la syntaxe des chemins change.

Comprendre la table des attributs

La partie la plus utile, et la plus mal lue, est la table des attributs. Chaque ligne décrit une mesure du disque, avec plusieurs colonnes :

• La valeur normalisée et la pire valeur enregistrée depuis l'activation de SMART, sur une échelle interne au fabricant.
• Le seuil déterminé par le fabricant. Un attribut est considéré comme en échec lorsque sa valeur normalisée devient inférieure ou égale au seuil.
• Le type : un attribut de pré-panne indique une défaillance imminente s'il passe sous son seuil, un attribut d'usure indique une fin de vie normale du produit.
• La colonne d'échec : FAILING_NOW si l'attribut est sous son seuil maintenant, In_the_past s'il y est passé un jour, et aucun marqueur s'il n'a jamais échoué.
• La valeur brute, celle qui porte souvent l'interprétation physique, par exemple une température en degrés Celsius ou un compteur de cycles. Les conventions varient d'un fabricant à l'autre, et sur un SSD certains attributs changent de signification.

Retenez la règle qui évite les fausses alertes : le fait qu'un attribut soit de type pré-panne ne signifie pas que votre disque va tomber. Il n'a ce sens que si la valeur normalisée est inférieure ou égale au seuil, ou si la colonne d'échec indique une défaillance. Un disque sain affiche typiquement une longue liste d'attributs de pré-panne parfaitement normaux.

Les attributs à surveiller en priorité

Sur un disque mécanique classique, la surveillance utile tient à quelques identifiants :

• Attribut 5, secteurs réalloués : des secteurs défectueux ont été remplacés par des secteurs de réserve. Quelques unités stables ne sont pas dramatiques, une progression régulière annonce une surface qui se dégrade.
• Attribut 197, secteurs en attente : des secteurs n'ont pas pu être lus et attendent d'être relus ou réalloués. C'est le signal le plus parlant à court terme.
• Attribut 198, secteurs non corrigeables hors ligne : des lectures ont échoué lors des tests automatiques. Là encore, la tendance compte plus que la valeur absolue.
• Attribut 9, heures de fonctionnement : utile pour situer l'âge du disque, même si l'unité affichée varie selon le fabricant.
• Attributs 194 et 231, température : à surveiller surtout pour les dérives, un disque trop chaud en baie mal ventilée vieillit plus vite.

Sur un SSD NVMe, les attributs sont issus du journal SMART/Health Information et parlent un autre langage : octet d'avertissement critique, spare disponible, pourcentage d'usure et compteurs d'erreurs d'intégrité. Le démon smartd sait d'ailleurs s'appuyer dessus : ses directives récentes alertent si le pourcentage d'usure dépasse un seuil ou si des erreurs d'intégrité apparaissent.

Lancer un autotest et lire le journal

Un autotest interne vérifie réellement la surface du disque, ce que la simple lecture des compteurs ne fait pas. Deux variantes existent :

sudo smartctl -t short /dev/sda
sudo smartctl -t long /dev/sda
sudo smartctl -l selftest /dev/sda

Le test court dure généralement quelques minutes, le test long parcourt toute la surface et occupe donc des heures. Sur un disque en production, lancez-les en période creuse : un test long consomme de la bande passante disque et peut ralentir les entrées et sorties applicatives, ce qui n'a rien à voir avec un problème de santé mais se remarque côté service. Le résultat se lit avec -l selftest, et un échec de test répété est un signal à prendre au sérieux même si le verdict de santé reste bon.

Automatiser la surveillance avec smartd

Regarder les disques à la main ne tient pas dans le temps. Le paquet smartmontools fournit smartd, un démon qui interroge les disques toutes les 30 minutes par défaut, journalise les erreurs et les changements d'attributs via syslog, et peut envoyer des avertissements par e-mail. Sur Debian et Ubuntu, il lit sa configuration dans /etc/smartd.conf.

# /etc/smartd.conf
DEFAULT -a -m [email protected] -s (S/../.././02|L/../../7/03)
DEVICESCAN

Les directives qui comptent dans ce fichier :

• -a active l'ensemble des contrôles SMART pour ce disque, c'est la valeur par défaut si vous n'indiquez rien.
• DEVICESCAN demande au démon de détecter lui-même les disques et d'appliquer les directives associées, ce qui évite de figer des noms de périphériques qui changent.
• -m définit l'adresse de destination des alertes, -M exec exécute un script à la place d'un envoi de courrier, ce qui permet de brancher la supervision existante.
• -s planifie les autotests, avec le format type/mois/jour/jour de semaine/heure. Dans l'exemple ci-dessus, un test court est lancé chaque nuit entre 2 h et 3 h, et un test long le dimanche entre 3 h et 4 h.
• -n standby évite de réveiller un disque en veille pour le tester, utile sur les machines où les disques tournent peu.
• -I 194 ignore les variations de l'attribut de température pour ne pas être noyé sous les notifications, et -R 5! au contraire déclenche une alerte critique dès qu'un nouveau secteur est réalloué.
• -H ne surveille que le verdict de santé, si vous préférez une surveillance minimale à un flux de messages.

Après modification du fichier, inutile de redémarrer la machine : un signal HUP suffit, par exemple avec killall -HUP smartd. Les messages arrivent dans le journal système habituel, souvent /var/log/syslog ou /var/log/messages. Pour écrire une configuration propre sur une machine existante, vous pouvez même la générer : smartctl --scan-open -- -a -m [email protected] > smartd.conf produit une ligne par disque détecté.

Si vous branchez vos propres scripts sur ces alertes, sachez qu'un script appelé par smartd reçoit des variables d'environnement décrivant le problème, dont un type d'échec qui distingue une défaillance de santé, un secteur en attente, un secteur non corrigeable, un test raté, une erreur du journal ou une température hors plage. C'est le bon endroit pour ouvrir automatiquement un ticket, ou pour pousser une notification là où votre équipe regarde réellement, que vous gériez une seule machine ou plusieurs serveurs depuis un panneau de contrôle.

Les disques derrière un contrôleur RAID

Sur un serveur dédié avec contrôleur RAID matériel, le système ne voit qu'un volume logique. Interroger ce volume ne dit rien de l'état des disques physiques, et c'est précisément le cas où l'on veut éviter la double panne. smartctl sait traverser certains contrôleurs en précisant le type et le numéro du disque :

sudo smartctl -a -d megaraid,0 /dev/sda
sudo smartctl -a -d megaraid,2 /dev/sda

Le principe est identique pour les autres familles de contrôleurs, avec d'autres valeurs de type et parfois un autre nœud de périphérique. Attention à un point : il faut viser le nœud du contrôleur et non celui du volume logique, sinon smartctl interroge la grappe et non le disque. La liste exacte des types pris en charge, avec la syntaxe propre à chaque contrôleur, est documentée dans la page de manuel de smartctl ; c'est le genre de paramètre qu'on copie depuis la documentation officielle plutôt que de mémoire.

Ce que vous surveillez, ce que gère l'hébergeur

Sur un serveur dédié, la frontière entre votre périmètre et celui de l'hébergeur mérite d'être claire, parce qu'elle détermine qui agit quand un disque faiblit :

• Côté hébergeur : le matériel, l'alimentation, le réseau, la baie, ainsi que le remplacement du disque défectueux. Selon le niveau d'infogérance de votre offre, la surveillance du matériel peut aussi être assurée de son côté, mais elle ne dispense pas de la vôtre : un disque peut dégrader votre service sans que son verdict de santé bascule.
• Côté vous : le système d'exploitation, les logiciels, la configuration, les données, la surveillance applicative, les sauvegardes et la décision de réagir à une alerte.

Gérer un serveur dédié, c'est aussi accepter cette répartition : vous ne remplacerez pas le disque vous-même, mais vous êtes celui qui constate le problème en premier. C'est précisément pour cela qu'un relevé SMART régulier a de la valeur même quand l'hébergeur surveille ses machines : vous voyez la conséquence côté service, et vous êtes celui qui peut dire, preuve à l'appui, qu'il faut intervenir.

Au-delà des disques : les autres éléments à surveiller

Un serveur ne meurt pas seulement de ses disques. Une fois la routine SMART en place, étendez la surveillance à ce qui casse aussi souvent, et qui se voit depuis l'intérieur de la machine :

• La mémoire vive et sa variante de serveur, avec ou sans correction d'erreur : une barrette défectueuse provoque des erreurs aléatoires, des compilations qui échouent et des bases de données corrompues. Les compteurs d'erreurs corrigeables du noyau et un test mémoire hors production valent le détour.
• Le processeur et la température : une charge anormale, des processeurs qui saturent ou une température qui monte traduisent souvent un ventilateur fatigué ou une pâte thermique sèche, deux causes classiques de ralentissement progressif sur un serveur qui tourne des mois sans interruption.
• Le pare-feu : une règle oubliée après une mise à jour explique autant de coupures qu'une panne matérielle, et un accès administrateur verrouillé se diagnostique plus vite quand la configuration est documentée.
• Les applications et les sites que vous hébergez : un serveur web qui ne répond plus, une base de données qui refuse les connexions, un certificat expiré. Ce sont les incidents les plus fréquents, et ils n'ont rien à voir avec SMART.
• Les sauvegardes : le meilleur indicateur de santé d'un serveur reste la date de la dernière sauvegarde restaurée avec succès, pas la date de la dernière sauvegarde créée.

Vue d'ensemble : le disque est le composant dont la panne coûte le plus cher en données, c'est donc celui qui mérite la surveillance la plus fine, mais un serveur se juge sur l'ensemble de ses organes.

Interpréter et agir

Un verdict de santé dégradé, un attribut passé en dessous de son seuil ou un autotest raté signifient la même chose en pratique : il faut planifier le remplacement du disque. Quelques réflexes rendent cette étape beaucoup moins stressante :

• Vérifiez d'abord que la sauvegarde la plus récente est exploitable, avant de toucher au matériel. C'est le moment où l'on découvre qu'une copie de la veille n'était pas complète, d'où l'intérêt d'une stratégie de sauvegarde éprouvée sur serveur dédié.
• Traitez différemment une valeur stable et une valeur qui monte : deux secteurs en attente depuis six mois n'ont pas la même urgence que cinquante nouveaux en une semaine.
• Surveillez aussi la capacité et la performance, pas seulement la santé brute. Un disque qui se remplit ou dont les entrées et sorties se dégradent mérite un diagnostic avant d'en arriver aux secteurs défectueux.
• Documentez le numéro de série du disque concerné et l'identifiant de la machine : sur un serveur dédié, c'est cette information que vous donnerez au support, et elle évite des allers-retours.
• Gardez une copie de vos sauvegardes en dehors de la machine, sur un support distant ou sur un espace de stockage réseau, pour ne pas dépendre du disque que vous êtes en train de remplacer.

Deux guides complémentaires prolongent ce diagnostic : l'analyse des entrées et sorties disque permet de distinguer une saturation liée à la charge d'un début de défaillance matérielle, et la surveillance de l'espace disque évite de confondre un problème de capacité avec un problème de santé.

Les erreurs fréquentes

• Se contenter du verdict -H. Un disque peut afficher un verdict sain avec des secteurs en attente qui augmentent : le verdict est un résumé, pas un diagnostic.
• Lire la valeur normalisée sans la colonne d'échec. Une valeur normalisée basse mais stable, au-dessus du seuil, n'est pas une alerte en soi.
• Confondre type pré-panne et panne imminente. La quasi-totalité des disques sains affichent des attributs de pré-panne dans la norme.
• Ne jamais lancer d'autotest. Les compteurs d'attributs ne voient pas tout, un test long révèle parfois des secteurs illisibles qu'aucun compteur n'annonçait.
• Lancer les tests longs en pleine charge. Le test occupe le disque pendant des heures, ce qui se traduit par une dégradation visible côté application.
• Interroger le volume RAID au lieu du disque physique. Vous surveillez alors la grappe, pas les disques qui la composent.
• Chercher des compteurs SMART dans une machine virtuelle. Le volume présenté par l'hyperviseur ne les expose pas ; surveillez la performance applicative à la place.
• Croire que SMART remplace une sauvegarde. Aucun attribut ne vous rendra vos données, et un disque surveillé qui meurt reste un disque mort.
• Ignorer les alertes par e-mail. Une boîte de réception non lue transforme un démon de surveillance en décoration. Branchez les alertes là où votre équipe regarde vraiment.

En résumé : la routine en cinq points

1. Installer smartmontools et lister les disques avec smartctl --scan.
2. Relever l'état avec smartctl -x, en gardant un œil sur les attributs 5, 197 et 198.
3. Planifier un test court quotidien et un test long hebdomadaire en période creuse.
4. Automatiser avec smartd, avec une alerte e-mail ou un script qui atterrit dans votre supervision.
5. Sur contrôleur RAID matériel, interroger chaque disque physique et non le volume logique.

Sur un serveur dédié, cette routine prend quelques minutes à configurer et vous fait gagner la seule chose qu'aucun redémarrage ne rend : le temps de remplacer un disque avant qu'il ne tombe. Si vous hébergez des serveurs de jeu, gardez aussi un œil sur le service lui-même, par exemple avec la détection automatique d'un serveur hors service : un disque qui part en vrille est souvent diagnostiqué trop tard, après la corruption de la base et la colère des joueurs. Notez au passage le numéro de série de vos disques, il vous servira au premier incident.