Surveiller la santé de ses disques sous Linux : le guide complet

HDD ou SSD, mécanique ou électronique, aucun support de stockage n’est éternel. Comprendre comment ils meurent, savoir lire les bons indicateurs et mettre en place une surveillance automatisée, c’est la différence entre une panne anticipée et une perte de données. Voici le guide complet, des notions théoriques aux scripts prêts à l’emploi.

Pourquoi un disque meurt-il ?

Avant de plonger dans les outils, il faut comprendre que HDD et SSD ne meurent pas pour les mêmes raisons. Cette différence conditionne tout : les indicateurs à surveiller, la façon de calculer l’espérance de vie restante, et même la manière dont on se rend compte qu’un disque est en train de lâcher.

Le HDD : la mécanique de précision

Un disque dur classique, c’est de la mécanique horlogère qui tourne à 5 400, 7 200 ou 10 000 tours par minute, avec des têtes de lecture flottant à quelques nanomètres au-dessus de plateaux magnétiques. Tout ce qui peut tuer un HDD est physique :

• Usure mécanique : les roulements, le moteur, les actionneurs des têtes finissent par fatiguer.
• Choc thermique ou physique : une tête qui touche un plateau (le fameux head crash) raye définitivement la surface.
• Démagnétisation locale : un secteur perd progressivement sa capacité à retenir l’information.
• Défaut électronique : la carte contrôleur peut lâcher avant les plateaux.

La mort d’un HDD est généralement progressive et bruyante : des secteurs deviennent illisibles un à un, puis se multiplient. Si on surveille les bons indicateurs, on a souvent plusieurs semaines pour réagir.

Le SSD : l’usure de la flash

Un SSD n’a aucune pièce mobile. Son point faible, c’est la mémoire NAND flash elle-même : chaque cellule ne peut supporter qu’un nombre limité de cycles d’écriture/effacement avant de devenir incapable de retenir une charge fiable.

• SLC (1 bit/cellule) : ~100 000 cycles, mais très cher, réservé à l’industriel.
• MLC (2 bits/cellule) : ~3 000 à 10 000 cycles.
• TLC (3 bits/cellule, dominant aujourd’hui) : ~500 à 3 000 cycles.
• QLC (4 bits/cellule, entrée de gamme moderne) : ~100 à 1 000 cycles.

Le contrôleur du SSD compense intelligemment via le wear leveling (répartition uniforme de l’usure sur toutes les cellules), la sur-provision (blocs de réserve invisibles à l’utilisateur) et la correction d’erreurs (ECC). Résultat : un SSD grand public moderne tient facilement 5 à 10 ans en usage normal.

La mort d’un SSD est plus traîtresse. Souvent, il fonctionne parfaitement... jusqu’au jour où il passe en lecture seule sans prévenir, voire devient totalement invisible. La surveillance est donc encore plus importante que sur un HDD.

SMART, la pierre angulaire du diagnostic

Depuis le milieu des années 1990, tous les disques durs et SSD intègrent SMART (Self-Monitoring, Analysis and Reporting Technology). C’est un système embarqué dans le firmware du disque qui surveille en permanence des dizaines de paramètres internes et les expose à l’OS.

Chaque attribut SMART possède en général quatre champs :

• VALUE : valeur normalisée actuelle (typiquement de 1 à 253, plus c’est haut, mieux c’est).
• WORST : la pire valeur jamais enregistrée pour cet attribut.
• THRESH : le seuil sous lequel le constructeur considère l’attribut comme critique.
• RAW_VALUE : la valeur brute, celle qui est réellement parlante.

💡 Piège classique : on regarde souvent la colonne VALUE alors que c’est la RAW_VALUE qui dit la vérité. Une VALUE à 100 peut masquer une RAW_VALUE qui commence à dériver.

Les outils sous Linux

smartmontools, l’incontournable

C’est l’outil de référence. Il interroge SMART et présente les résultats de manière exploitable.

# Installation
sudo apt install smartmontools          # Debian/Ubuntu
sudo dnf install smartmontools          # Fedora/RHEL
sudo pacman -S smartmontools            # Arch

Les commandes essentielles :

# Verdict global (PASSED ou FAILED)
sudo smartctl -H /dev/sda

# Rapport complet : attributs + identité + résultats de tests
sudo smartctl -a /dev/sda

# Pour un NVMe, la syntaxe est la même
sudo smartctl -a /dev/nvme0n1

# Identité du disque uniquement (modèle, série, firmware)
sudo smartctl -i /dev/sda

# Activer SMART s'il est désactivé
sudo smartctl -s on /dev/sda

Les autotests SMART

Le disque sait se tester lui-même. Trois niveaux :

# Test court (~2 minutes, vérifie l'électronique et un échantillon de surface)
sudo smartctl -t short /dev/sda

# Test long (plusieurs heures, lit toute la surface)
sudo smartctl -t long /dev/sda

# Test de transmission (vérifie le bus SATA/SAS)
sudo smartctl -t conveyance /dev/sda

# Voir le résultat des derniers tests
sudo smartctl -l selftest /dev/sda

# Voir la progression d'un test en cours
sudo smartctl -c /dev/sda

Les tests s’exécutent en tâche de fond dans le firmware du disque : tu peux continuer à l’utiliser pendant ce temps, c’est juste un peu plus lent.

nvme-cli, pour les SSD NVMe

smartctl gère les NVMe, mais nvme-cli expose des informations supplémentaires propres au protocole.

sudo apt install nvme-cli

# Lister les NVMe détectés
sudo nvme list

# Le log SMART NVMe, plus complet que via smartctl
sudo nvme smart-log /dev/nvme0n1

# Infos générales sur le contrôleur
sudo nvme id-ctrl /dev/nvme0n1

# Logs d'erreurs
sudo nvme error-log /dev/nvme0n1

badblocks, pour les recherches en profondeur

badblocks lit (ou écrit puis relit) chaque secteur du disque pour détecter les défauts. C’est lent mais sans concession.

# Mode lecture seule, sans danger (recommandé sur disque en service)
sudo badblocks -sv /dev/sda

# Mode destructif (efface tout, à utiliser uniquement sur un disque vide)
sudo badblocks -wsv /dev/sda

# Mode non-destructif (lit, écrit un motif, restaure ; lent mais exhaustif)
sudo badblocks -nsv /dev/sda

⚠️ Sur un SSD, badblocks est de moins en moins pertinent : la sur-provision masque les défauts au niveau bloc. Préfère les indicateurs SMART d’usure.

hdparm et les outils complémentaires

# Infos détaillées sur un HDD (mode DMA, cache, etc.)
sudo hdparm -I /dev/sda

# Tester les performances de lecture
sudo hdparm -tT /dev/sda

Côté graphique

Pour qui préfère le clic au shell :

• GNOME Disks (gnome-disks) — interface propre, affiche les attributs SMART en clair et permet de lancer des tests.
• KDE Partition Manager — équivalent côté KDE.
• GSmartControl — frontend graphique de smartmontools, plus technique mais très complet.

Les indicateurs à surveiller sur un HDD

Tous les attributs ne se valent pas. Voici ceux qui prédisent réellement les pannes, hiérarchisés par importance. Les études menées par Backblaze sur plus de 200 000 disques en production ont identifié cinq attributs comme les meilleurs prédicteurs de panne.

Les indicateurs critiques (doivent rester à 0)

Règle d’or : tant que ces cinq attributs sont à zéro, le disque est en bonne santé. Dès qu’un seul d’entre eux passe à 1, sauvegarde immédiatement et planifie le remplacement. Surveille ensuite l’évolution : une augmentation régulière annonce une panne imminente.

Les indicateurs contextuels

Exemple de lecture concrète

$ sudo smartctl -A /dev/sda

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always   0
  9 Power_On_Hours          0x0032   088   088   000    Old_age   Always   8743
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always   0
194 Temperature_Celsius     0x0022   118   100   000    Old_age   Always   32
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always   0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Always   0

Ce disque a 8 743 heures (presque un an en continu), tourne à 32°C, et tous les indicateurs critiques sont à zéro. Verdict : excellente santé.

Les indicateurs à surveiller sur un SSD

L’approche est fondamentalement différente : on ne cherche pas des secteurs morts, on cherche à savoir combien d’usure il reste à consommer.

SSD SATA

Les noms d’attributs varient selon les constructeurs (Samsung, Crucial, Kingston, etc. utilisent des dénominations légèrement différentes), mais les concepts sont communs :

SSD NVMe

NVMe a son propre vocabulaire, plus standardisé :

Exemple de lecture NVMe

$ sudo nvme smart-log /dev/nvme0n1

Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning                    : 0
temperature                         : 41 C
available_spare                     : 100%
available_spare_threshold           : 10%
percentage_used                     : 4%
data_units_read                     : 12,847,392
data_units_written                  : 8,234,156
host_read_commands                  : 184,729,381
host_write_commands                 : 92,847,193
controller_busy_time                : 287
power_cycles                        : 412
power_on_hours                      : 4,127
unsafe_shutdowns                    : 8
media_errors                        : 0
num_err_log_entries                 : 0

Lecture : 4 % d’usure consommée, 100 % de réserve disponible, 0 erreur média, 41°C. Disque en parfaite santé après 4 127 heures et environ 4,2 To écrits.

Calculer l’usure et l’espérance de vie

Côté HDD : il n’y a pas de formule

L’espérance de vie d’un HDD ne se calcule pas vraiment. Les constructeurs annoncent un MTBF (Mean Time Between Failures) de l’ordre du million d’heures, mais c’est une moyenne statistique sur une grande population, pas une prédiction individuelle. Les chiffres Backblaze montrent qu’environ 1 à 2 % des HDD meurent chaque année dans leurs datacenters, avec un pic les six premiers mois (mortalité infantile) puis un autre après 4-5 ans.

La règle pratique : tant que les compteurs d’erreurs critiques restent à zéro, le disque va bien. Dès qu’ils bougent, le compte à rebours commence.

Côté SSD : le calcul TBW

Tout SSD a une endurance annoncée en TBW (TeraBytes Written) ou DWPD (Drive Writes Per Day) dans sa fiche technique. Exemples typiques :

• SSD grand public 500 Go : 150 à 300 TBW.
• SSD haut de gamme 1 To : 600 à 1 200 TBW.
• SSD entreprise 1 To : 1 800 TBW et plus.

Calculer ce qu’on a écrit

Pour un SSD SATA, on lit Total_LBAs_Written (qui est en secteurs de 512 octets) :

Téraoctets écrits = (Total_LBAs_Written × 512) / 10¹²

Sur la plupart des SSD, smartctl le calcule directement, mais voici la commande manuelle :

LBA=$(sudo smartctl -A /dev/sda | awk '/Total_LBAs_Written/ {print $10}')
echo "scale=2; $LBA * 512 / 1000000000000" | bc

Pour un NVMe, c’est Data Units Written en unités de 512 000 octets :

Téraoctets écrits = (Data Units Written × 512000) / 10¹²
                  = Data Units Written × 0,000512

Estimer le temps restant

Une fois qu’on connaît le volume écrit et l’ancienneté du disque :

Écriture par jour = Téraoctets écrits / (Power_On_Hours / 24)
TBW restant = TBW_constructeur − Téraoctets écrits
Jours restants ≈ TBW restant / Écriture par jour

Exemple concret : un SSD Samsung 970 EVO 1 To (600 TBW annoncés) a écrit 47 To en 18 mois (~13 000 h) :

• Écriture moyenne : 47 / 540 ≈ 87 Go/jour.
• TBW restant : 600 − 47 = 553 To.
• Jours restants : 553 000 / 87 ≈ 6 350 jours = 17 ans à ce rythme.

Autant dire que l’électronique mourra avant la flash. C’est typique : pour un usage bureautique normal, l’endurance n’est jamais le facteur limitant. Elle ne le devient que dans des cas spécifiques : serveurs de bases de données, caches d’écriture intensive, logs très bavards.

Vérifier la cohérence

Le SSD lui-même tient un compteur d’usure, en pourcentage. Ce chiffre doit être cohérent avec ton calcul TBW. Si Percentage Used affiche 30 % mais que tu n’as utilisé que 10 % de tes TBW, soit le constructeur est conservateur (bon signe), soit tes écritures sont très fragmentées (mauvais signe : le facteur d’amplification d’écriture est élevé).

Mettre en place la surveillance automatique

Faire des smartctl -a à la main, c’est bien pour un diagnostic ponctuel. En production, on veut être prévenu avant la catastrophe. C’est le rôle de smartd.

Configurer smartd

Le démon smartd est installé avec smartmontools. Sa configuration se trouve dans /etc/smartd.conf. Voici une config robuste :

# /etc/smartd.conf

# Surveiller tous les disques détectés automatiquement
# -a : tous les attributs et autotests
# -o on : active la collecte automatique
# -S on : active la sauvegarde automatique des attributs
# -n standby,q : ne pas réveiller le disque s'il est en veille
# -s : planning des autotests
#   S/../.././02 = test court tous les jours à 2h
#   L/../../6/03 = test long le samedi à 3h
# -W 4,45,55 : alerte si température varie de 4°C, ou dépasse 45°C, ou dépasse 55°C
# -m : destinataire des alertes mail
# -M exec : script à exécuter en plus du mail

DEVICESCAN -a -o on -S on -n standby,q \
  -s (S/../.././02|L/../../6/03) \
  -W 4,45,55 \
  -m admin@exemple.fr \
  -M exec /usr/local/bin/smart-alert.sh

Puis on active et démarre le service :

sudo systemctl enable --now smartd
sudo systemctl status smartd

Un script d’alerte simple

#!/bin/bash
# /usr/local/bin/smart-alert.sh

DEVICE="$SMARTD_DEVICE"
MESSAGE="$SMARTD_MESSAGE"
FAILTYPE="$SMARTD_FAILTYPE"

# Log local
logger -t smartd-alert "ALERTE sur $DEVICE : $FAILTYPE - $MESSAGE"

# Notification desktop si session graphique active
for user in $(who | awk '{print $1}' | sort -u); do
    uid=$(id -u "$user")
    sudo -u "$user" DISPLAY=:0 DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/$uid/bus" \
        notify-send -u critical "Disque en danger" "$DEVICE : $MESSAGE"
done

# Webhook vers Slack/Discord/Teams (optionnel)
# curl -X POST -H 'Content-Type: application/json' \
#   -d "{\"text\":\"🚨 Disque $DEVICE : $MESSAGE\"}" \
#   "$WEBHOOK_URL"

Un check rapide en cron

Pour un dashboard simple, un script qui synthétise l’état de tous les disques :

#!/bin/bash
# /usr/local/bin/disk-health-check.sh

REPORT="/var/log/disk-health.log"
echo "=== Check du $(date) ===" >> "$REPORT"

for disk in /dev/sd? /dev/nvme?n?; do
    [ -e "$disk" ] || continue

    health=$(sudo smartctl -H "$disk" 2>/dev/null | grep -E "(PASSED|FAILED|OK)")
    model=$(sudo smartctl -i "$disk" 2>/dev/null | grep "Device Model\|Model Number" | head -1 | cut -d: -f2)

    echo "$disk -$model : $health" >> "$REPORT"

    if echo "$health" | grep -q FAILED; then
        echo "ALERTE $disk" | mail -s "Disque défaillant : $disk" admin@exemple.fr
    fi
done

À planifier dans crontab :

0 8 * * * /usr/local/bin/disk-health-check.sh

Cas pratiques et bonnes pratiques

Que faire quand un attribut critique passe à 1 ?

1. Sauvegarder immédiatement toutes les données importantes vers un autre support.
2. Lancer un test long pour confirmer (smartctl -t long).
3. Vérifier l’évolution sur quelques jours : un secteur isolé peut être un incident, une croissance régulière annonce la fin.
4. Commander le disque de remplacement sans attendre.
5. Si le disque est sous garantie, le RMA est généralement accepté dès qu’un attribut SMART critique est non nul.

Les pièges classiques

• Croire le verdict “PASSED” : smartctl -H ne renvoie FAILED que quand un attribut a dépassé son seuil constructeur, et certains constructeurs sont très laxistes. Un disque peut être en train de mourir tout en affichant PASSED. Toujours regarder les attributs détaillés.
• Ignorer les UDMA_CRC_Error_Count : ces erreurs viennent du câble, pas du disque. Avant d’accuser un HDD, change la nappe SATA.
• Surveiller un SSD comme un HDD : chercher des secteurs réalloués sur un SSD n’a pas de sens. C’est l’usure flash et les erreurs média qui comptent.
• Oublier le RAID : sur un RAID, smartctl doit utiliser -d pour adresser chaque disque physique (-d megaraid,0, -d sat+megaraid,0, etc. selon le contrôleur).
• Stresser inutilement les SSD : les benchmarks d’écriture répétés consomment de l’endurance. Ne les lance pas en boucle pour “vérifier”.

Cas du RAID matériel

Sur un contrôleur RAID hardware, les disques ne sont pas vus directement par l’OS. La syntaxe devient :

# MegaRAID/PERC : disque 0 du contrôleur
sudo smartctl -a -d megaraid,0 /dev/sda

# 3ware/LSI : tw_cli ou directement
sudo smartctl -a -d 3ware,0 /dev/twa0

# Adaptec via arcconf
sudo arcconf getsmartstats 1

Cas du chiffrement

LUKS et autres couches de chiffrement n’interfèrent pas avec SMART : on interroge toujours le device physique (/dev/sda), pas le mapping déchiffré (/dev/mapper/...).

Pour aller plus loin

Pour comprendre ce qui prédit vraiment une panne, les rapports trimestriels de Backblaze sur leurs 250 000+ disques en production restent la référence empirique mondiale. Ils publient les taux de panne par modèle, par âge, et identifient les attributs SMART réellement prédictifs.

Côté outils, netdata et Prometheus + smartctl_exporter permettent de remonter les attributs SMART dans une métrologie globale, avec graphes historiques et alerting. Pour un homelab ou une petite infra, c’est l’étape suivante naturelle après smartd.

Enfin, garde toujours en tête le principe fondamental : SMART n’est pas une garantie. Environ 30 à 40 % des disques meurent sans qu’aucun attribut SMART n’ait jamais signalé d’anomalie. La surveillance réduit le risque, elle ne l’élimine pas. La seule vraie protection reste, et restera, la sauvegarde.