Avertissements SMART sous Debian 13 : quels attributs prédisent vraiment une panne (et que faire)

octobre 7, 2025 • février 3, 2026 • Lecture : 32 min • Views: 5

Cet article vous a aidé ?

Vous recevez l’alerte à 02:17. « SMART Usage Attribute: 0xC5 Current_Pending_Sector changed from 0 to 1. »
Vous la regardez comme si c’était votre horoscope. Le disque est-il en train de mourir, ou a-t-il juste passé une mauvaise nuit ?

Sur Debian 13, les avertissements SMART sont soit prématurés, bruyants et déroutants — soit tardifs, discrets et coûteux.
L’astuce consiste à savoir quels attributs sont réellement prédictifs, lesquels sont des artifices constructeurs, et quelle
doit être la prochaine action opérationnelle quand un nombre bouge.

SMART en clair : ce qu’il peut et ne peut pas vous dire

SMART, c’est le disque qui vous dit ce qu’il pense de lui-même. C’est à la fois utile et sujet à caution, comme un CV.
Il expose des compteurs et des seuils partiellement standardisés, partiellement spécifiques au constructeur, et toujours façonnés
par des décisions de firmware que vous ne pouvez pas auditer.

Deux vérités importantes vous maintiendront lucide :

SMART confirme mieux une panne qu’il ne la prédit — mais quelques attributs corrèlent fortement avec des pannes réelles.
SMART ne remplace pas la redondance, les sauvegardes et les scrubs. Si vous n’avez pas ces protections, SMART est un détecteur de fumée dans une maison en plein carburant.

Sous Debian 13, l’outillage est mature : smartmontools (smartctl + smartd), signaux du journal kernel,
pages de log NVMe, et retours de la pile de stockage depuis mdadm, LVM, ZFS, btrfs et votre hyperviseur.
L’intérêt est de combiner ces signaux pour décider : ignorer, observer, tester ou remplacer.

Faits et contexte qui rendent SMART compréhensible

Quelques points de contexte qui changent la manière de lire les alertes :

SMART a commencé comme spécifique aux constructeurs dans les années 1990 ; les attributs « standard » sont encore interprétés différemment selon les fabricants.
Les valeurs normalisées (VALUE/WORST/THRESH) sont une échelle constructeur, pas de la physique. RAW est plus proche de la réalité, mais peut lui aussi être encodé.
Les seuils SMART sont souvent réglés pour éviter les RMA, pas pour protéger vos données. « PASSED » ne veut pas dire « sain ».
La reallocation existe parce que les disques sont livrés avec des secteurs de réserve. Les disques modernes remappent constamment — un certain remappage est attendu, mais les tendances comptent.
Les SSD ont introduit l’usure comme mode de défaillance majeur. SMART pour SSD inclut des indicateurs d’usure, mais tous ne sont pas comparables entre modèles.
NVMe a défini des logs de santé plus cohérents que SMART SATA/ATA, mais les fabricants diffèrent encore sur les détails et seuils.
Les auto-tests ne sont pas la même chose que les scrubs. Les tests SMART sont internes au périphérique ; les scrubs valident au niveau système de fichiers/RAID l’intégrité réelle de vos données.
SMART ne peut pas voir directement les problèmes de câblage. Les erreurs UDMA CRC sont un indice, mais beaucoup de problèmes de lien apparaissent d’abord dans les logs du kernel.
Certaines pannes sont de type « mort subite ». Bugs de firmware, pannes de contrôleur ou événements d’alimentation peuvent rendre un disque inutilisable malgré un historique SMART propre.

Les attributs qui prédisent réellement une panne (et pourquoi)

Si vous ne retenez qu’une chose : les erreurs média valent mieux que le « statut de santé » à elles seules.
Un disque qui commence à avoir des difficultés à lire/écrire des secteurs réels est un disque que vous devez considérer coupable jusqu’à preuve du contraire.

1) Secteurs réalloués : `Reallocated_Sector_Ct` (05)

C’est le classique : des secteurs jugés défectueux et remappés vers des secteurs de réserve. Un nombre non nul n’est pas une condamnation immédiate,
mais c’est l’un des signaux les plus clairs que la surface se dégrade sur les disques optiques et certains firmwares de SSD SATA.

Signification opérationnelle : Le disque a déjà échoué à stocker des données de façon fiable au moins une fois.

Ce qui prédit une panne :

Le taux de croissance compte plus que le nombre absolu.
De nouvelles réallocations lors de lectures intensives (scrub/sauvegarde) sont particulièrement compromettantes.
Réallocations plus secteurs pendants/uncorrectable forment une combinaison « programmer le remplacement ».

2) Secteurs en attente : `Current_Pending_Sector` (C5)

Les secteurs pendants signifient que le disque dit : « J’ai essayé de lire ce secteur et je n’ai pas pu le corriger. Si vous le réécrivez
avec succès, je l’effacerai ; si la réécriture échoue, je le remapperai. »

Les secteurs pendants sont plus exploitables que les secteurs réalloués parce qu’ils corrèlent avec des
échecs de lecture qui peuvent se manifester comme des erreurs I/O maintenant, pas seulement « quelque chose s’est mal passé un jour ».

Décisions :

Tout secteur pendant non nul sur un disque contenant des données importantes est un déclencheur pour lancer des tests contrôlés et planifier un remplacement.
Si le compteur redescend à zéro après réécriture (ou après un scrub forçant des lectures), considérez-le comme un avertissement.
Si les secteurs pendants persistent ou augmentent, remplacez. Ne négociez pas avec l’entropie.

3) Erreurs non récupérables hors ligne : `Offline_Uncorrectable` (C6)

Cela compte les erreurs non récupérables trouvées lors des scans hors ligne ou des auto-tests. Cela correspond généralement à « vous ne pourrez pas lire certaines données sans redondance ».

Décisions :

Un C6 non nul sur un disque de données signifie que vous devez considérer que vous avez des blocks illisibles jusqu’à preuve du contraire.
Combinez avec vérifications du système de fichiers, scrubs RAID et lectures ciblées des zones importantes (images VM, bases de données).

4) Erreurs de lecture non récupérables (variantes constructeur)

Dans les tableaux SMART SATA/ATA, vous verrez des attributs comme Raw_Read_Error_Rate (01) et
Seek_Error_Rate (07). Les valeurs normalisées sont souvent inutiles (surtout chez Seagate).
Mais certains disques exposent des compteurs additionnels pour les erreurs non récupérables.

L’important n’est pas le nom « rate ». L’important est : le disque renvoie-t-il des erreurs de lecture non récupérables à l’hôte ?
Cela se voit plus fiablement dans :

entrées du journal d’erreurs SMART
échecs de logs d’auto-test
messages d’erreur I/O dans le kernel
erreurs de checksum RAID/ZFS

5) Échecs de log d’auto-test SMART (pas un attribut, mais un verdict)

Si un auto-test long se termine par « Completed: read failure » ou « Completed: unknown failure », c’est le disque
qui avoue qu’il ne peut pas lire sa propre surface de façon fiable.

Décision : Si le disque contient quelque chose d’important, le remplacement est par défaut la décision.

6) NVMe « critical warning » et erreurs média

Le reporting santé NVMe est différent. Deux champs NVMe importent beaucoup :

Critical Warning (bitmask) : s’il est défini, le périphérique lève la main pour attirer l’attention.
Media and Data Integrity Errors : compte les échecs que le contrôleur n’a pas pu récupérer.

Surveillez aussi Percentage Used (usure). Ce n’est pas un prédicteur de panne à lui seul, mais une usure élevée
combinée à des erreurs média est une mauvaise combinaison.

7) Erreurs au niveau de l’interface : `UDMA_CRC_Error_Count` (C7)

Celle-ci ne prédit pas la panne du disque. Elle prédit une instabilité de câblage, de backplane ou de contrôleur.
Si C7 augmente, vous corrompez votre journée avec des erreurs de lien.

Décision : Remplacez/remettez en place le câble, vérifiez le backplane, contrôlez l’alimentation, et arrêtez d’accuser la surface disque.

Une citation qui circule dans les équipes ops depuis des décennies :
« L’espoir n’est pas une stratégie. » — James Cameron

Blague n°1 : « SMART “PASSED” » est comme un bambin qui dit « Je ne l’ai pas cassé. » Donnée intéressante, pas une certification.

Les attributs qui vous font perdre du temps (la plupart du temps)

Certains attributs SMART sont célèbres surtout parce qu’ils apparaissent dans chaque sortie smartctl,
pas parce qu’ils prédisent votre incident.

`Raw_Read_Error_Rate` (01) et `Seek_Error_Rate` (07)

Chez beaucoup de constructeurs ces valeurs RAW sont d’énormes compteurs qui augmentent constamment et ne signifient rien sans
le contexte propriétaire. Les gens paniquent parce que le chiffre a l’air effrayant. C’est compréhensible : c’est énorme, c’est étiqueté « error », et les humains cherchent des motifs.

Quand ils comptent : quand le log d’auto-test du disque, le journal d’erreurs SMART, ou les logs kernel montrent aussi de réelles erreurs de lecture.

`Power_On_Hours` (09) et `Start_Stop_Count` (04)

Utile pour la planification de cycle de vie et les arguments de garantie. Faible comme prédicteurs immédiats de panne.
Les disques peuvent mourir jeunes ; les disques peuvent tourner des années et rester stoïques.

`Temperature_Celsius` (194/190)

La température importe, mais c’est un amplificateur de risque, pas un détecteur de fumée. Si vous tournez chaud,
vous verrez plus d’erreurs et une durée de vie réduite. Mais un pic de température isolé n’est pas une raison de remplacer un disque.

Heures de vol de la tête, cycles de charge, compteurs de vibration

Ils peuvent être significatifs dans de grandes flottes quand vous les corrélez. Dans un serveur seul, ils vous disent surtout :
« Ce châssis se trouve dans un placard avec une ventilation médiocre et un talent pour faire hurler les ventilateurs. »

« Résultat d’auto-évaluation globale : PASSED »

Traitez-le comme le voyant « check engine » d’une voiture éteint. Agréable, mais pas rassurant si le moteur fait déjà des bruits métalliques.

NVMe vs SATA : télémétrie différente, pièges différents

Debian 13 facilite l’exécution à la fois des SMART ATA et des logs NVMe, mais le modèle mental diffère :

SMART SATA/ATA expose beaucoup d’attributs ; l’interprétation est en partie folklore, en partie expérience, en partie documents constructeurs que vous n’avez pas.
NVMe expose un journal de santé plus structuré avec des compteurs plus clairs : erreurs média, arrêts non sûrs, pourcentage d’usure et événements de température.

Le piège avec NVMe est de supposer qu’il est toujours « meilleur ». Les NVMe peuvent échouer brutalement (bugs firmware/contrôleur),
et « Percentage Used » peut bercer les gens dans l’idée : « Seulement 12% utilisés, donc tout va bien. » Les erreurs média s’en fichent de votre optimisme.

Le piège avec SATA est l’inverse : supposer que chaque attribut est interprétable. Beaucoup ne le sont pas. Vous feriez mieux
de vous concentrer sur le petit ensemble qui se mappe fiablement aux pannes : réallocations, pending, uncorrectable, échecs d’auto-test,
et vrais logs d’erreurs.

Mode d’emploi diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Quand un avertissement SMART arrive, vous voulez répondre rapidement à deux questions :
Les données sont-elles en risque maintenant ? et le problème vient-il du disque ou du chemin vers le disque ?

Premier : confirmer que le symptôme n’est pas une hallucination de monitoring

Vérifiez les logs kernel pour les erreurs I/O et les réinitialisations de lien.
Vérifiez les valeurs actuelles avec smartctl et les logs d’erreurs/auto-tests.
Vérifiez si l’attribut a changé une fois ou s’il est en tendance.

Second : classifier le mode de défaillance

Dégradation média : pending/reallocated/uncorrectable, échecs de lecture d’auto-test.
Interface/chemin : erreurs CRC, réinitialisations de lien SATA, timeouts, problèmes HBA, alimentation/backplane.
Induit par la charge : erreurs qui apparaissent seulement sous fortes lectures ou seulement sur des LBAs spécifiques (région défectueuse).
Santé contrôleur NVMe : critical warning défini, erreurs média qui augmentent, throttling thermique, nombreux arrêts non sûrs.

Troisième : décider vite — remplacer maintenant, tester maintenant, ou surveiller

Remplacer maintenant : tout C5/C6 non nul persistant, échecs d’auto-test, erreurs média sur NVMe, ou erreurs I/O kernel sur des disques de données importants.
Tester maintenant : un secteur pending unique qui s’efface, une réallocation isolée sans tendance, ou compteurs suspects mais non fatals (lancer test long + scrub).
Surveiller : erreurs CRC sans erreurs média après correction du câblage ; problèmes de température après correction du flux d’air ; « PASSED » sans autre anomalie.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les tâches que j’exécute réellement sur Debian quand apparaissent des alertes SMART. Chacune inclut :
commande, sortie d’exemple, ce que cela signifie, et la décision à prendre.

Task 1: Identify the disk and its path (don’t guess)

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,SIZE,TYPE,TRAN,ROTA,MOUNTPOINTS
NAME   MODEL              SERIAL          SIZE TYPE TRAN ROTA MOUNTPOINTS
sda    ST8000NM000A-2KE1  ZR123ABC        7.3T disk sata    1
├─sda1                     512M part           1 /boot/efi
└─sda2                     7.3T part           1
nvme0n1 Samsung SSD 990    S7KX...         1.8T disk nvme    0
└─nvme0n1p1                               1.8T part           0 /

Ce que cela signifie : Confirmez quel périphérique est rotatif (ROTA=1) vs SSD (ROTA=0), et cartographiez les points de montage.

Décision : Utilisez le bon chemin d’outil (/dev/sda vs /dev/nvme0 ou /dev/nvme0n1) et ne remplacez pas le mauvais disque.

Task 2: Get the SMART summary for SATA/ATA disks

cr0x@server:~$ sudo smartctl -a /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Model Family:     Seagate Exos 7E8
Device Model:     ST8000NM000A-2KE1
Serial Number:    ZR123ABC
User Capacity:    8,001,563,222,016 bytes [8.00 TB]
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       8
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       8
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Ce que cela signifie : « PASSED » est sans importance ici ; C5=1 et C6=1 sont des risques actifs. Reallocated=8 montre des remappings antérieurs.

Décision : Lancez immédiatement un test long et programmez le remplacement. Si les données sont critiques, commencez l’évacuation maintenant.

Task 3: Pull NVMe SMART/health log the right way

cr0x@server:~$ sudo smartctl -a /dev/nvme0
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Model Number:                       Samsung SSD 990 PRO 2TB
Serial Number:                      S7KX...
Firmware Version:                   5B2QJXD7
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Total NVM Capacity:                 2,000,398,934,016 [2.00 TB]

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        45 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    6%
Data Units Read:                    18,345,112
Data Units Written:                 11,902,771
Host Read Commands:                 247,110,004
Host Write Commands:                183,991,201
Controller Busy Time:               2,401
Media and Data Integrity Errors:    0
Unsafe Shutdowns:                   7

Ce que cela signifie : NVMe sain : pas d’avertissement critique, pas d’erreurs média, usure faible. Les arrêts non sûrs peuvent être une histoire d’alimentation/installation.

Décision : Si vous avez eu un incident, cherchez ailleurs (alimentation, kernel, système de fichiers). Corrigez quand même les arrêts non sûrs car ils corrèlent avec des comportements étranges futurs.

Task 4: Check SMART error log (ATA) to see real failures, not just counters

cr0x@server:~$ sudo smartctl -l error /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
SMART Error Log Version: 1
ATA Error Count: 2
  CR = Command Register [HEX]
  FR = Features Register [HEX]
  SC = Sector Count Register [HEX]
  SN = Sector Number Register [HEX]
  CL = Cylinder Low Register [HEX]
  CH = Cylinder High Register [HEX]
  DH = Device/Head Register [HEX]
  DC = Device Command Register [HEX]
  ER = Error register [HEX]
  ST = Status register [HEX]
Error 2 occurred at disk power-on lifetime: 28421 hours (1184 days + 5 hours)
  When the command that caused the error occurred, the device was active or idle.
  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 00 00 00 40  Error: UNC at LBA = 0x00a1b2c3 = 10629827

Ce que cela signifie : UNC = non récupérable. Le disque a renvoyé une lecture irrécupérable à un LBA précis.

Décision : Considérez cela comme une défaillance média. Si vous avez de la redondance, lancez un scrub/resilver ; sinon, priorisez la sauvegarde et le remplacement.

Task 5: Check SMART self-test log (the drive’s confession booth)

cr0x@server:~$ sudo smartctl -l selftest /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed: read failure       90%     28422         10629827
# 2  Short offline       Completed without error       00%     28420         -

Ce que cela signifie : Le test court est passé ; le test long a trouvé une lecture défaillante à un LBA. C’est courant : les tests courts ne couvrent pas assez de surface.

Décision : Remplacez le disque. Lancez aussi des vérifications de niveau supérieur (scrub) pour s’assurer que la redondance a corrigé les données.

Task 6: Start a short SMART test (quick triage)

cr0x@server:~$ sudo smartctl -t short /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Testing has begun.
Please wait 2 minutes for test to complete.
Test will complete after Tue Dec 29 03:14:12 2025

Ce que cela signifie : Le disque a accepté la demande de test. Cela ne prouve pas la santé ; il vérifie les bases.

Décision : Si le test court échoue, c’est un signal de remplacement immédiat. S’il passe mais que vous avez des pending/uncorrectable, lancez un test long.

Task 7: Start a long SMART test (surface coverage)

cr0x@server:~$ sudo smartctl -t long /dev/sda
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Testing has begun.
Please wait 822 minutes for test to complete.
Test will complete after Tue Dec 29 17:02:41 2025

Ce que cela signifie : Le temps du test long est réaliste pour de grands HDD. Il forcera des lectures sur toute la surface.

Décision : Planifiez en fonction de la charge. Sur des arrays occupés, programmez hors-peak, mais ne repoussez pas d’une semaine « parce que c’est gênant ».

Task 8: Watch for kernel-level I/O errors and link resets

cr0x@server:~$ sudo journalctl -k -S -2h | egrep -i 'ata[0-9]|i/o error|reset|nvme|blk_update_request|medium error' | tail -n 30
Dec 29 01:42:18 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 29 01:42:18 server kernel: ata3.00: failed command: READ FPDMA QUEUED
Dec 29 01:42:18 server kernel: blk_update_request: I/O error, dev sda, sector 10629827 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Dec 29 01:42:19 server kernel: ata3: hard resetting link
Dec 29 01:42:24 server kernel: ata3: link is slow to respond, please be patient (ready=0)
Dec 29 01:42:29 server kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Ce que cela signifie : Erreur I/O sur un secteur alignée avec l’erreur LBA SMART : problème média. Les réinitialisations de lien peuvent être secondaires (disque en difficulté) ou liées au câblage/backplane.

Décision : Si vous voyez des medium errors, remplacez. Si vous ne voyez que des resets et que les CRC augmentent, concentrez-vous sur le câblage/HBA.

Task 9: Check UDMA CRC error growth (path trouble)

cr0x@server:~$ sudo smartctl -A /dev/sda | egrep 'UDMA_CRC_Error_Count|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       8
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       1
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       1
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       12

Ce que cela signifie : Les erreurs CRC sont de la corruption au niveau du lien. Elles ne devraient pas augmenter. Les erreurs média sont aussi présentes ici, donc vous avez probablement les deux : un disque malade et un chemin douteux.

Décision : Remplacez le disque (média). En même temps, remettez en place/remplacez le câble ou vérifiez le backplane pour éviter que le disque suivant n’hérite de la même histoire CRC.

Task 10: Run a RAID scrub/check (mdadm) and interpret the result

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5]
md0 : active raid1 sda2[0] sdb2[1]
      7813772288 blocks super 1.2 [2/2] [UU]
      [==>..................]  check = 12.4% (970000000/7813772288) finish=420.0min speed=270000K/sec

unused devices: <none>

Ce que cela signifie : Un check est en cours. Si la vérification rencontre des blocks illisibles sur un membre, md s’appuiera sur l’autre (si intact).

Décision : Laissez-le finir et surveillez les logs kernel. Si des erreurs apparaissent, accélérez le remplacement et vérifiez que le miroir est vraiment propre.

Task 11: For ZFS, scrub and check for checksum/read errors

cr0x@server:~$ sudo zpool status -v
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device or restore the affected file(s) from backup.
  scan: scrub repaired 0B in 01:12:33 with 0 errors on Tue Dec 29 02:10:01 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sda     DEGRADED     5     0     2
            sdb     ONLINE       0     0     0

errors: Permanent errors have been detected in the following files:
        tank/vmstore:vm-102-disk-0

Ce que cela signifie : ZFS vous dit la vérité inconfortable : il y a eu des erreurs de lecture/checksum, et un fichier est impacté.

Décision : Remplacez sda, puis restaurez l’ensemble de données/fichier affecté depuis la sauvegarde ou une réplique. Scrubpez de nouveau après resilver.

Task 12: For btrfs, check device stats (it’s not SMART, but it’s reality)

cr0x@server:~$ sudo btrfs device stats /mnt/data
[/dev/sda2].write_io_errs    0
[/dev/sda2].read_io_errs     3
[/dev/sda2].flush_io_errs    0
[/dev/sda2].corruption_errs  2
[/dev/sda2].generation_errs  0

Ce que cela signifie : Le système de fichiers a observé des erreurs de lecture et des corruptions. C’est au-delà du « peut-être ».

Décision : Remplacez le périphérique sous-jacent et lancez un scrub. Confirmez que la redondance/réparation a fonctionné ; sinon, restaurez depuis la sauvegarde.

Task 13: Enable and configure smartd for actionable alerts

cr0x@server:~$ sudo apt update
...
cr0x@server:~$ sudo apt install -y smartmontools
...
cr0x@server:~$ sudo systemctl enable --now smartd
Created symlink /etc/systemd/system/multi-user.target.wants/smartd.service → /lib/systemd/system/smartd.service.

Ce que cela signifie : smartd tourne maintenant et peut surveiller périodiquement les périphériques.

Décision : Ne vous arrêtez pas là. Vous devez ajuster /etc/smartd.conf pour surveiller les bons périphériques (surtout derrière les HBAs) et lancer des tests.

Task 14: Validate that smartd is watching the disks you think it is

cr0x@server:~$ sudo smartd -q showtests
smartd 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
Device: /dev/sda, will do test schedule 'S/../.././02|L/../../6/03'
Device: /dev/nvme0, will do test schedule 'S/../.././02|L/../../6/03'

Ce que cela signifie : smartd a interprété vos plannings : il lancera des tests courts quotidiennement à 02:00 et des tests longs le samedi à 03:00.

Décision : Si vos disques critiques sont absents, corrigez la découverte (pass-through SATA, megaraid, mappage SCSI) avant de faire confiance aux alertes.

Task 15: Inspect Debian 13’s log messages from smartd

cr0x@server:~$ sudo journalctl -u smartd -S -24h | tail -n 40
Dec 29 02:00:01 server smartd[1321]: Device: /dev/sda, starting scheduled Short self-test.
Dec 29 02:02:15 server smartd[1321]: Device: /dev/sda, SMART Self-test log error count increased from 0 to 1
Dec 29 02:02:15 server smartd[1321]: Device: /dev/sda, SMART Prefailure Attribute: 5 Reallocated_Sector_Ct changed from 7 to 8

Ce que cela signifie : smartd fait son travail : il a lancé le test, vu un nouvel échec d’auto-test, et observé une croissance d’attribut.

Décision : C’est territoire remplacement. Capturez aussi la sortie complète de smartctl -a pour le ticket et le postmortem.

Task 16: If the disk is behind a HBA/RAID controller, address it explicitly

cr0x@server:~$ sudo smartctl -a -d sat /dev/sdb
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.12.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     WDC WD80EFAX-68KNBN0
Serial Number:    7SG...
...
197 Current_Pending_Sector  0x0012   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   200   200   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       34

Ce que cela signifie : Le média a l’air correct ; les erreurs CRC sont élevées. Cela pointe loin de la platine et vers des problèmes de chemin.

Décision : Remettez en place/remplacez le câble SATA/backplane, vérifiez le firmware HBA, et surveillez si C7 continue d’augmenter ensuite.

Blague n°2 : Si votre stratégie de stockage est « on saura que c’est mauvais quand ça arrêtera de marcher », félicitations pour votre carrière palpitante en intervention d’urgence.

Trois mini-récits d’entreprise des tranchées SMART

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne gérait une flotte de serveurs Debian avec des SSD locaux pour une couche cache et des HDD pour les données en masse.
Le monitoring a alerté sur Reallocated_Sector_Ct pour quelques HDD. L’ingénieur d’astreinte a jeté un coup d’œil à
« SMART overall-health: PASSED », puis a clôturé l’alerte comme du bruit. L’hypothèse était simple : « Si SMART dit passed, tout va bien. »

Deux jours plus tard, un job analytics nocturne a commencé à échouer. Pas catastrophiquement — juste assez pour relancer et encombrer la file.
La latence des tableaux de bord clients a augmenté. Les graphiques de stockage étaient confus : pics d’iowait, puis calme ; un motif qui
ressemblait à « système occupé » plutôt qu’à « disque en train de mourir ».

Quand ils ont finalement lancé smartctl -l selftest, le test long avait déjà rapporté un échec de lecture sur un LBA constant.
ZFS (présent dans un cluster) l’aurait signalé bruyamment, mais ce dataset particulier était sur ext4 sur mdadm,
et les erreurs sont apparues comme des erreurs I/O intermittentes dans le kernel que personne n’avait corrélées à l’alerte SMART.

La correction a été ennuyeuse : remplacer le disque, reconstruire le miroir, relancer le job. Le postmortem fut cependant instructif.
Ils ont changé la politique : tout secteur pending/uncorrectable sur des disques de données déclenche une planification de remplacement, indépendamment de « PASSED ».
Ils ont aussi formé l’équipe à consulter le log d’erreurs SMART et le log d’auto-test, pas seulement la ligne de synthèse.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Dans une autre organisation, quelqu’un a essayé de réduire les fenêtres de maintenance en déplaçant les tests SMART longs « seulement trimestriellement », parce que
« le test long est perturbateur et nous avons RAID de toute façon ». Ils ont aussi désactivé les scrubs RAID pour éviter les impacts de performance en heures ouvrées.
L’optimisation avait l’air bonne sur le papier : moins de lectures en arrière-plan, moins de plaintes de latence.

Quelques mois plus tard, un disque a commencé à augmenter son Current_Pending_Sector. Personne ne l’a remarqué parce que smartd ne faisait que des tests courts,
et les secteurs pendants étaient dans une région « froide » rarement lue. La production semblait saine. Les sauvegardes « réussissaient » parce qu’elles étaient
incrémentales et ne touchaient pas les blocks défaillants.

Puis est venu l’événement double : un second disque du même groupe RAID est tombé en panne nette (le contrôleur l’a lâché).
La reconstruction a martelé le disque survivant, forçant des lectures sur toute la surface. C’est là que les secteurs pendants sont devenus non récupérables.
L’array n’a pas pu reconstruire quelques blocks. Pas tout le dataset. Juste assez pour corrompre plusieurs images VM.

La cause racine n’était pas « RAID est inutile ». La cause racine était la suppression des seuls mécanismes qui auraient forcé les erreurs latentes à apparaître
tant que la redondance était intacte : scrubs réguliers et tests longs. Ils ont réintroduit des scrubs mensuels et des tests longs hebdomadaires pour les HDD,
puis les ont limités en débit et planifiés hors-peak. Les plaintes de latence ont diminué après qu’ils aient arrêté de les lancer à midi.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une entreprise avec un contrôle de changement strict exécutait Debian 13 sur des serveurs de bases de données avec NVMe en miroir.
Ils avaient une politique qui paraissait fastidieuse : chaque ticket de remplacement de disque devait inclure smartctl -a,
les 24 dernières heures de logs kernel pour le périphérique, et la sortie d’un contrôle de redondance (mdadm check ou ZFS scrub).

Une semaine, une alerte de monitoring a déclenché : les « Unsafe Shutdowns » NVMe ont augmenté. Personne n’a paniqué. Le disque était « PASSED », pas d’erreurs média, pas d’avertissement critique.
Mais la politique exigeait de rassembler les preuves, alors l’astreinte a aussi extrait les derniers logs kernel et a remarqué de brefs événements de perte d’alimentation sur le bus PCIe.

Ils ont traîné la piste jusqu’à une connexion d’alimentation légèrement desserrée dans un PDU de rack (pas dramatique, juste un peu délogée après une visite de maintenance).
S’ils avaient remplacé le NVMe, cela n’aurait « rien résolu » et aurait caché le problème d’infrastructure. Au lieu de cela, ils ont stabilisé l’alimentation, puis surveillé les compteurs.
Aucun nouvel arrêt non sûr. Aucune corruption.

La pratique ennuyeuse — collecter plusieurs signaux avant d’agir — a évité un cycle de remplacements rituels et a attrapé le vrai risque systémique.
Parfois, la décision d’ingénierie la plus fiable est de la paperasserie avec des dents.

Erreurs courantes : symptôme → cause racine → correction

Voici des modes de défaillance que j’ai vus de manière répétée, mappés à ce que vous devez réellement faire à leur sujet.
Cette section est volontairement spécifique ; les conseils génériques sont la nourriture des incidents.

1) « SMART PASSED mais les logs applicatifs montrent des erreurs I/O »

Symptôme : Base de données ou hôte VM voit des erreurs de lecture sporadiques ; SMART overall-health dit PASSED.

Cause racine : Les seuils constructeurs sont laxistes ; la synthèse de santé ne déclenche qu’à la fin. Les erreurs média apparaissent d’abord dans les logs/auto-tests.

Correction : Vérifiez le log d’erreurs SMART et le log d’auto-test ; lancez un auto-test long ; si des échecs de lecture existent, remplacez le disque et vérifiez l’intégrité des données via scrub.

2) « UDMA_CRC_Error_Count augmente ; remplacer les disques n’a pas aidé »

Symptôme : Les erreurs CRC augmentent sur plusieurs disques dans la même baie/chemin de câble.

Cause racine : Câble SATA/connecteur backplane défectueux, port HBA marginal, ou bruit d’alimentation provoquant de la corruption du lien.

Correction : Remplacez/remettez en place les câbles ; déplacez le disque dans une baie différente ; mettez à jour le firmware HBA ; inspectez l’alimentation/backplane ; confirmez que le compteur CRC cesse d’augmenter.

3) « Current_Pending_Sector vaut 1 puis est revenu à 0, donc tout va bien »

Symptôme : C5 clignote puis s’efface après un test.

Cause racine : Un secteur faible a été réécrit/remappé ; cela peut être un signe précoce de dégradation de surface.

Correction : Lancez un test long et un scrub système de fichiers/RAID ; surveillez la tendance chaque semaine. Si de nouveaux secteurs pendants apparaissent, remplacez.

4) « Les tests SMART longs diminuent beaucoup les performances, donc on les a désactivés »

Symptôme : Plaintes utilisateur pendant les tests ; tâches en arrière-plan supprimées.

Cause racine : Tests planifiés en période de pointe, pas de limitation d’I/O, pas de coordination avec la charge.

Correction : Planifiez hors-peak ; étalez les disques ; limitez le débit des scrubs/check ; acceptez un coût de maintenance pour éviter les surprises en reconstruction.

5) « NVMe Percentage Used est bas ; pourtant on a des erreurs média »

Symptôme : L’usure semble correcte ; les erreurs media/data integrity augmentent.

Cause racine : Problèmes de contrôleur ou NAND sans lien avec l’usure, bugs firmware, ou instabilité thermique/alim.

Correction : Traitez les erreurs média comme réelles ; mettez à jour le firmware si la politique le permet ; vérifiez températures et événements d’alimentation ; remplacez si les erreurs persistent.

6) « On a lancé un test SMART ; il est passé ; la corruption existe toujours »

Symptôme : Les tests SMART montrent « Completed without error », mais ZFS/btrfs rapporte de la corruption.

Cause racine : Les tests SMART ne valident pas l’intégrité bout en bout ; ils peuvent ne pas toucher les blocks exacts ou ne pas détecter des problèmes transitoires de chemin.

Correction : Faites davantage confiance aux checksums des systèmes de fichiers qu’à SMART. Scrub, localisez les fichiers affectés, restaurez depuis la sauvegarde, et enquêtez sur le contrôleur/câblage.

7) « smartd tourne mais on ne reçoit jamais d’alertes »

Symptôme : smartd actif ; pas de notifications même quand un disque est clairement en panne.

Cause racine : smartd non configuré pour surveiller tous les périphériques, surtout derrière des HBAs ; ou chemin d’alerte email/notification cassé.

Correction : Validez les périphériques monitorés avec smartd -q showtests ; testez le canal d’alerte ; configurez explicitement les périphériques avec les bons types -d.

Listes de contrôle / plan pas à pas

Checklist A: When you see pending/uncorrectable sectors (C5/C6) on SATA HDD

Capturez les preuves : smartctl -a, -l error, -l selftest, et les logs kernel récents pour le périphérique.
Lancez un auto-test long (smartctl -t long) si le système peut tolérer la charge de lecture.
Exécutez votre validation de redondance (mdadm check / ZFS scrub / btrfs scrub) tant que la redondance est intacte.
Si le test long échoue ou si C5/C6 augmente : planifiez le remplacement immédiatement.
Après remplacement : rebuild/resilver, puis scrubpez de nouveau pour confirmer l’absence d’erreurs résiduelles.

Checklist B: When you see only CRC errors (C7) and no media errors

Confirmez que C5/C6 sont zéro et que les auto-tests sont propres.
Remettez en place/remplacez le câble SATA, ou déplacez vers une baie/slot différent.
Vérifiez les logs kernel pour réinitialisations/timeouts de lien.
Surveillez C7 pendant 24–72 heures. Il devrait cesser d’augmenter.
Si C7 continue d’augmenter sur plusieurs disques, escaladez vers HBA/backplane/alimentation.

Checklist C: NVMe warning signals

Collectez la sortie smartctl -a /dev/nvmeX (critical warning, media errors, température, percentage used).
Vérifiez les logs kernel pour PCIe AER, réinitialisations NVMe, ou timeouts.
Si le critical warning est défini ou si les media errors augmentent : remplacez le disque (et conservez les preuves pour le RMA).
Si seulement les unsafe shutdowns augmentent : enquêtez sur l’alimentation/PSU/PDU et les réinitialisations abruptes avant d’accuser le SSD.

Checklist D: Make smartd actually useful (not just installed)

Inventoriez les périphériques : SATA, SAS, NVMe, ponts USB, HBAs.
Configurez /etc/smartd.conf avec les bons types de périphériques et les plannings.
Vérifiez le parsing et les plannings : smartd -q showtests.
Vérifiez l’alerte : simulez une notification ou validez l’ingestion journald dans votre monitoring.
Revue hebdomadaire : toute croissance des realloc/pending/uncorrectable déclenche un ticket avec tendance et plan.

FAQ

1) Quels attributs SMART doivent vraiment me réveiller la nuit ?

Les secteurs pendants (C5), les non récupérables hors ligne (C6), les réallocations en hausse (05),
les entrées du journal d’erreurs SMART indiquant UNC, et les échecs d’auto-test. Pour NVMe : critical warning et media/data integrity errors.

2) Un Reallocated_Sector_Ct non nul implique-t-il toujours un remplacement immédiat ?

Pas toujours. Un petit compteur stable sur un HDD ancien peut continuer à fonctionner. Mais la croissance — surtout pendant des scrubs/tests — est un motif de remplacement.
Si vous avez aussi C5/C6 ou des échecs d’auto-test, arrêtez les débats et remplacez.

3) Pourquoi Current_Pending_Sector est-il revenu à zéro ?

Parce que le secteur a été réécrit ou remappé avec succès. Cela efface la liste des pendings. Cela n’annule pas le fait que
le disque a rencontré une lecture qu’il n’a pas pu corriger. Traitez-le comme un avertissement précoce et cherchez une récidive.

4) SMART peut-il prédire une mort soudaine d’un SSD due à un bug firmware ?

Parfois vous verrez des réinitialisations, des critical warnings ou des compteurs d’erreurs en hausse. Souvent non. Les pannes firmware/contrôleur peuvent être abruptes.
C’est pourquoi existent la redondance et les sauvegardes : pour gérer les pannes qui ne préviennent pas.

5) Dois-je faire confiance aux valeurs RAW ou normalisées SMART ?

Préférez RAW pour des compteurs comme reallocations/pending/uncorrectables/CRC. Les valeurs normalisées sont des échelles constructeurs et peuvent induire en erreur.
Mais n’ignorez pas les dépassements de seuil normalisés — ils signifient généralement que le constructeur admet finalement que le disque est défunt.

6) Les tests courts valent-ils la peine ?

Oui, comme vérification rapide et pour l’automatisation. Non, ils ne suffisent pas pour valider la surface.
Si vous enquêtez sur un avertissement, le test long (plus un scrub/check) est le geste adulte.

7) SMART dit que le disque est ok, mais ZFS montre des erreurs de checksum — que faire ?

Croyez ZFS. Les checksums des systèmes de fichiers détectent la corruption bout en bout que SMART peut manquer. Scrubpez, identifiez les fichiers affectés,
remplacez le matériel suspect (disque, câble, HBA), et restaurez depuis la sauvegarde si nécessaire.

8) À quelle fréquence dois-je lancer des tests SMART longs sur des HDD ?

Hebdomadaire est courant pour des flottes importantes, mensuel pour des environnements plus calmes. La bonne cadence est celle que vous exécutez réellement
sans provoquer d’incidents de performance. Échelonnez les disques et évitez les heures de pointe.

9) Les erreurs CRC signifient-elles que mes données sont corrompues ?

Les erreurs CRC indiquent des problèmes de transmission au niveau du lien ; le protocole détecte et relance. Habituellement vous obtenez des relances et de la latence,
pas de la corruption silencieuse. Pourtant, des erreurs de lien fréquentes peuvent provoquer des timeouts et des défaillances de niveau supérieur, donc réparez le chemin.

10) Quelle est la chose la plus utile à stocker dans un ticket quand SMART alerte ?

Une sortie complète de smartctl -a plus le journal d’erreurs SMART et le log d’auto-test, et les derniers logs kernel pertinents.
Les données de tendance (ce qui a changé depuis la semaine précédente) valent mieux qu’un simple instantané.

Conclusion : prochaines étapes réalisables aujourd’hui

Les avertissements SMART ne sont pas un débat philosophique. Ce sont des entrées pour une décision sous incertitude.
Votre travail sur Debian 13 est de prendre cette décision rapidement, avec les bons signaux, et sans superstition.

Concentrez-vous sur les signaux prédictifs : pending (C5), uncorrectable (C6), réallocations en hausse (05), échecs d’auto-test, entrées UNC du journal d’erreurs SMART, avertissements critiques NVMe et erreurs média.
Différenciez média et chemin : C7 et réinitialisations de lien sont souvent câbles/backplanes/HBAs, pas la surface du disque.
Combinez les couches : SMART + logs kernel + résultats de scrub/check. Les systèmes de fichiers avec checksum (ZFS/btrfs) sont impitoyablement honnêtes — utilisez-les.
Rendez smartd vraiment utile : configurez les plannings, validez les périphériques surveillés, vérifiez la livraison des alertes, et capturez des preuves dans les tickets.
En cas de doute et si les données comptent : évacuez, remplacez, et post-validez avec un scrub. Les disques coûtent moins cher que les appels d’incident.