Surveiller l'état de santé des disques d'un serveur dédié Linux avec smartmontools

Perdre les données d'un serveur dédié à cause d'un disque non surveillé est l'une des pannes les plus évitables. smartmontools (paquet disponible dans les dépôts officiels Debian/Ubuntu) expose l'interface SMART intégrée aux disques ATA/SATA, SCSI/SAS et NVMe pour détecter une dégradation physique bien avant la panne. Ce guide explique comment installer, interroger et automatiser la surveillance du stockage avec smartctl et le daemon smartd sur un serveur dédié Linux. Vous apprendrez à identifier les attributs critiques, planifier des auto-tests et recevoir des alertes avant de perdre un disque.

Pourquoi surveiller les disques d'un serveur dédié

Sur un serveur physique bare-metal, contrairement à un serveur VPS virtualisé, les administrateurs ont un accès direct aux registres SMART de chaque disque dur ou SSD. Cette visibilité est précieuse : les données SMART permettent d'anticiper une panne en observant l'évolution des attributs critiques sur des semaines ou des mois, bien avant que le système d'exploitation ne signale un problème.

Les disques durs rotatifs et les SSD vieillissent différemment. Un HDD signale sa dégradation via des secteurs réaffectés et des erreurs de lecture. Un SSD NVMe expose son usure via des compteurs de cellules épuisées et un espace de réserve décroissant. Sans surveillance SMART, une panne disque sur un serveur de production peut provoquer une perte de données totale si les sauvegardes ne sont pas à jour.

Installation de smartmontools

Le paquet smartmontools est disponible dans les dépôts officiels de toutes les distributions Linux courantes. Installez-le avec les droits root sur votre serveur dédié ou serveur VPS Linux :

apt install smartmontools   # Debian / Ubuntu
dnf install smartmontools   # AlmaLinux / Rocky Linux

Pour lister tous les disques détectés par smartctl :

smartctl --scan

La commande retourne une ligne par disque : par exemple /dev/sda -d scsi pour un HDD SATA ou /dev/nvme0 -d nvme pour un SSD NVMe. Sur un serveur physique, vous pouvez avoir plusieurs disques en baie de stockage indépendante ou configurés en RAID logiciel avec mdadm.

Interroger l'état SMART d'un disque

La commande de base pour afficher l'intégralité des informations SMART d'un disque ATA/SATA est :

smartctl -a /dev/sda

Pour un SSD NVMe :

smartctl -a /dev/nvme0

L'option -a affiche le bilan de santé, les informations du firmware, les capacités SMART, les attributs normalisés, le journal des erreurs et le journal des auto-tests. Accédez à votre serveur via SSH en tant qu'administrateur root pour lancer ces commandes. La sortie contient deux sections critiques :

• SMART overall-health self-assessment : si la valeur est PASSED, le disque ne prédit pas de panne imminente. Si elle est FAILED, sauvegardez immédiatement et remplacez le disque.
• SMART Attributes : tableau des attributs normalisés (VALUE, WORST, THRESH) et bruts (RAW_VALUE). Un attribut passe en état critique quand sa valeur normalisée descend sous le seuil THRESH.

Attributs SMART critiques à surveiller

Les attributs suivants, documentés dans la FAQ officielle de smartmontools et les spécifications ATA, signalent une dégradation physique réelle :

• ID 5 (Reallocated_Sector_Ct) : nombre de secteurs réaffectés vers la zone de réserve du disque dur. Un RAW_VALUE non nul indique des secteurs physiquement défectueux. Toute augmentation impose une sauvegarde immédiate (backup) et la planification d'un remplacement de disque.
• ID 197 (Current_Pending_Sector) : secteurs en attente de vérification car leur lecture a échoué. Un RAW_VALUE non nul signifie que le disque a du mal à lire certaines zones de l'espace disque disponible.
• ID 198 (Offline_Uncorrectable) : secteurs irrécupérables détectés lors des tests hors ligne. Combiné avec ID 197, un RAW_VALUE élevé précède souvent une panne complète du disque dur.
• ID 187 (Reported_Uncorrect) : erreurs non corrigées signalées au système d'exploitation ; à surveiller sur les disques SATA grand public.
• ID 190 / 194 (Temperature) : température en degrés Celsius. Au-delà de 50 degrés en continu, les performances et la durée de vie du disque diminuent significativement. Vérifiez la ventilation de la baie du serveur dédié.

Pour afficher uniquement le tableau des attributs :

smartctl -A /dev/sda

Un attribut avec VALUE inférieur ou égal à THRESH et un flag FAIL est un disque en état de pré-panne : vérifiez vos sauvegardes (backups) et planifiez un remplacement immédiat.

Lancer les auto-tests SMART

SMART intègre deux types de tests exécutés en arrière-plan par le disque sans interrompre les I/O du serveur :

smartctl -t short /dev/sda    # ~2 min : zones critiques et electrique
smartctl -t long  /dev/sda    # surface complete, ~1h par 500 Go

Le test court vérifie les zones électriques et mécaniques essentielles en moins de deux minutes. Le test long parcourt la totalité de la surface et détecte les secteurs défectueux que le test court peut manquer. Sur un serveur de production, planifiez le test long la nuit pour éviter d'impacter les performances. Consultez les résultats avec :

smartctl -l selftest /dev/sda

Une entrée Completed without error indique un test réussi. Une entrée read failure ou completed: servo/seek failure confirme une dégradation physique et impose une sauvegarde d'urgence et un remplacement du disque dur.

Automatiser la surveillance avec le daemon smartd

Interroger manuellement chaque disque n'est pas praticable sur un serveur physique avec plusieurs disques. Le daemon smartd, inclus dans smartmontools, surveille en continu et envoie des alertes par e-mail ou syslog dès qu'un attribut critique évolue. Activez-le via systemd :

systemctl enable --now smartd

Sa configuration se trouve dans /etc/smartd.conf. Exemple pour un serveur dédié avec deux disques SATA et un SSD NVMe, avec alerte e-mail et tests courts planifiés :

/dev/sda -a -m [email protected] -s S/../.././02
/dev/sdb -a -m [email protected] -s S/../.././02
/dev/nvme0 -a -m [email protected] -s S/../.././03

Détail des directives :

• -a : active toute la surveillance (santé, attributs, journal d'erreurs, journal des tests, contrôle des secteurs pendants ID 197 et des secteurs non corrigibles ID 198).
• -m [email protected] : adresse e-mail pour les alertes critiques. Nécessite un agent SMTP configuré sur le serveur (postfix, ssmtp, msmtp) avec accès au port 25 ou 587. Vérifiez que votre pare-feu (firewall) autorise les connexions SMTP sortantes.
• -s S/../.././02 : planifie un test court (S) tous les jours à 02h00. Format : TYPE/MOIS/JOUR/JOURDESEMAINE/HEURE ; .. signifie « tous ». Remplacez S par L pour un test long hebdomadaire.

Après modification, rechargez la configuration sans redémarrer le daemon :

systemctl reload smartd

Par défaut, smartd interroge les disques toutes les 30 minutes. Les alertes sont consignées dans syslog et dans les journaux systemd. Consultez-les via SSH avec :

journalctl -u smartd -n 50

Configurez la rotation des journaux pour éviter que les logs systemd n'occupent trop d'espace disque.

Cas particulier : SSD NVMe

Les SSD NVMe n'utilisent pas les attributs ATA numérotés. Leur rapport SMART se présente sous forme de compteurs nommés définis par la spécification NVMe. Interrogez un SSD NVMe avec :

smartctl -a /dev/nvme0

Portez une attention particulière à ces trois compteurs critiques :

• Critical Warning : tout octet non nul indique un problème critique (surchauffe, espace de réserve épuisé, erreurs médias). Agissez immédiatement : sauvegarde (backup) et remplacement.
• Available Spare : pourcentage d'espace de réserve restant dans le SSD. En dessous de 10 %, planifiez le remplacement avant saturation complète.
• Percentage Used : usure cumulée estimée par le contrôleur NVMe. Au-delà de 80 %, la durée de vie restante du SSD est limitée.

Smartmontools supporte l'interface NVMe depuis la version 6.5, disponible dans toutes les distributions LTS actuelles (Debian 11+, Ubuntu 20.04+). Pour les SSD SATA, activez aussi le TRIM pour préserver les performances.

Configuration réseau pour les alertes smartd

Pour que les alertes e-mail de smartd puissent être envoyées depuis votre serveur dédié, assurez-vous que :

• Un agent de messagerie est installé et configuré : postfix est le choix standard pour un serveur Linux. Configurez-le en mode satellite pour relayer vers votre serveur SMTP habituel.
• Le pare-feu (firewall) du serveur autorise les connexions TCP sortantes sur le port SMTP (25, 465 ou 587 selon votre configuration).
• L'adresse IP du serveur n'est pas bloquée par les listes de spam si vous utilisez le port 25 directement. Préférez un relais SMTP authentifié sur le port 587.

Testez l'envoi d'une alerte smartd manuellement :

smartctl --test=short /dev/sda
echo "test smartd" | mail -s "Test alerte SMART" [email protected]

Intégration dans un système de monitoring centralisé

Pour les administrateurs gérant plusieurs serveurs dédiés, combinez smartd avec une solution de supervision :

• Grafana et Prometheus : le collecteur node_exporter expose les métriques SMART, la RAM et l'utilisation processeur sous forme de compteurs Prometheus visualisables dans Grafana avec des alertes configurables.
• Alertes de monitoring VPS Linux : scripts d'alerte espace disque, mémoire et CPU extensibles aux compteurs SMART via smartctl.
• Uptime Kuma : surveillance de disponibilité à coupler avec des checks shell qui interrogent smartctl sur chaque serveur physique.

Complétez la protection du stockage sur votre serveur dédié avec nos guides sur la gestion des volumes LVM et les sauvegardes haute disponibilité.

Ce qu'il faut retenir

• Installez smartmontools dès la livraison de votre serveur dédié et lancez un premier test long pour établir un état de référence de chaque disque dur ou SSD.
• Surveillez en priorité les attributs 5, 197 et 198 : tout RAW_VALUE non nul mérite une investigation immédiate et une vérification des sauvegardes (backups).
• Activez smartd avec systemctl enable --now smartd et configurez /etc/smartd.conf avec alertes e-mail et tests courts quotidiens à heure creuse.
• Pour les SSD NVMe, contrôlez le Critical Warning byte et l'Available Spare plutôt que les attributs ATA numérotés.
• Combinez smartmontools avec Prometheus et Grafana pour une visibilité centralisée sur tous vos serveurs physiques.