Réparer les erreurs de disque au démarrage : que faire avant que cela n’empire

Ce que signifie réellement « Réparation des erreurs du disque » (et ce que ça ne veut pas dire)

Ce message au démarrage est généralement l’un des trois cas suivants :

• Un contrôle de cohérence du système de fichiers est en cours (Windows: CHKDSK; Linux: fsck; macOS: fsck_apfs). Cela peut être routinier après un arrêt non propre, ou déclenché parce qu’une corruption a été détectée.
• Le système rejoue un journal (commun sur ext4, XFS, NTFS). Les systèmes de fichiers journalisés essaient de restaurer la cohérence après un crash. La plupart des rejets de journal sont rapides. S’ils sont lents, c’est un indice.
• La couche de stockage est malheureuse : le disque renvoie des erreurs de lecture/écriture, met trop de temps à répondre, ou le contrôleur se réinitialise. Dans ce cas, « réparer » signifie que l’OS tente de lire des métadonnées et de réécrire des structures pendant que le disque échoue de façon intermittente.

Voici ce que cela ne signifie pas : ce n’est pas une garantie que l’OS corrige quoi que ce soit en toute sécurité, et ce n’est pas une promesse que vos données seront intactes ensuite. Les outils de réparation de système de fichiers sont conçus pour restaurer la cohérence, pas pour préserver chaque fichier. Sur un disque sain, ce compromis est acceptable. Sur un disque en fin de vie, c’est jouer aux fléchettes à l’aveugle.

État d’esprit actionnable : considérez les réparations au démarrage comme un symptôme, pas une solution. Votre objectif est de déterminer si vous faites face à (a) un arrêt sale ponctuel, (b) une corruption récurrente due à un logiciel/firmware/alimentation, ou (c) une défaillance imminente du disque.

Une idée paraphrasée, parce que c’est l’état d’esprit adapté à cette situation : tout finit par tomber en panne (esprit de fiabilité) : conceptez et opérez comme si c’était garanti.

Petite blague #1 : Un outil de réparation de système de fichiers, c’est comme un dentiste — utile, mais vous ne voulez pas qu’il improvise pendant que le fauteuil est en feu.

Mode opératoire de diagnostic rapide (premiers/deuxièmes/troisièmes contrôles)

Si vous êtes sur la console et que le système « répare » ou bloque, vous avez besoin d’une boucle serrée : observer → classer → décider. Voici la version que vous pouvez exécuter à 2h du matin sans créer de nouveaux problèmes.

Premier : déterminer si le disque tombe en panne physiquement

• Si vous pouvez accéder à un shell ou à un environnement de récupération, récupérez les indicateurs SMART/NVMe et les journaux noyau.
• Recherchez : secteurs réalloués, secteurs en attente, erreurs irrécupérables, erreurs CRC, erreurs media NVMe, réinitialisations de contrôleur, timeouts I/O.
• Décision : si ces éléments sont présents ou augmentent, arrêtez de « réparer » et commencez à « copier ». Clonez / imagez d’abord.

Second : déterminer si le système de fichiers est corrompu mais le matériel est OK

• Vérifiez les erreurs de montage, les boucles de rejeu du journal, et si fsck/chkdsk signale un nombre stable de corrections.
• Décision : si SMART paraît propre et que les erreurs correspondent à des pertes de courant ou des réinitialisations forcées, vous pouvez procéder à une réparation hors ligne — après avoir effectué des sauvegardes.

Troisième : déterminer si vous êtes bloqué par autre chose (pas le disque)

• UEFI/BIOS qui détecte mal l’ordre de démarrage, contrôleur RAID en état dégradé, câble SATA défaillant, backplane instable, initramfs cassé, ou pilote noyau peuvent se faire passer pour des « erreurs disque ».
• Décision : si les journaux montrent un I/O propre mais que le démarrage échoue au montage du root, concentrez-vous sur le bootloader/initramfs et les changements de nommage des périphériques.

Règle opérationnelle : plus le système « se bloque », plus vous devez suspecter des timeouts et des tentatives de reprise. Les réparations saines ont tendance à être bruyantes et rapides. Les disques malades sont silencieux et lents.

Faits et contexte historique intéressants (pourquoi cela revient)

• Fait 1 : CHKDSK remonte aux premiers outils disques de l’époque DOS ; ses formes modernes héritent encore de la même mission : rendre le système de fichiers cohérent, même si cela implique de supprimer des entrées douteuses.
• Fait 2 : Les systèmes de fichiers journalisés (comme ext3/ext4, NTFS, XFS) sont devenus courants en partie parce que réparer des systèmes non journalisés après un crash pouvait prendre des heures — ou nécessiter des scans complets — sur de gros disques.
• Fait 3 : Le passage des disques tournants aux SSD a réduit certaines pannes mécaniques mais introduit de nouvelles : bugs de firmware, usure entraînant des read disturb, et comportements de « mode lecture seule » soudain sur certains appareils.
• Fait 4 : Les erreurs de lien SATA (erreurs CRC) sont souvent causées par des câbles/backplanes, pas par le média du disque. Elles paraissent terrifiantes dans les journaux mais se règlent fréquemment avec un câble à 6 € et un meilleur routage.
• Fait 5 : Les « mauvais secteurs » ne sont pas toujours permanents. Les disques peuvent remapper des secteurs, et parfois une erreur de lecture transitoire redevient lisible — juste avant de retomber en panne. C’est pourquoi « ça a marché une fois » est un piège.
• Fait 6 : Les systèmes de fichiers ne sont pas des bases de données. Ils ne suivent pas les invariants métier, et les outils de réparation ne peuvent pas deviner vos intentions ; ils ne font que restaurer l’intégrité interne.
• Fait 7 : Le RAID n’a jamais été une sauvegarde, et l’industrie répète cette phrase depuis que le RAID est devenu populaire dans les serveurs. C’est toujours vrai.
• Fait 8 : Les vérifications au démarrage étaient autrefois programmées plus agressivement (par ex. les contrôles par nombre de montages sur ext2/ext3). Les systèmes modernes réduisent souvent ces vérifications pour accélérer le boot — parfois au prix d’une corruption lente passée sous silence.

La première règle : protéger les données avant de « réparer » quoi que ce soit

S’il y a la moindre chance que le disque soit en train de faillir, votre priorité est de capturer les données avec le moins de stress supplémentaire sur le disque. Les outils de réparation peuvent marteler les métadonnées et déclencher beaucoup d’I/O aléatoire — exactement ce que déteste un média faible.

Ce que « protéger les données » signifie en pratique :

• Si le système démarre encore : copiez d’abord les données les plus précieuses (bases de données, répertoires utilisateur, configurations, clés). Ne commencez pas par lancer des vérifications du disque complètes.
• Si ça ne démarre pas : utilisez un environnement live pour monter en lecture seule, ou imagez le disque.
• Si c’est un serveur avec redondance (RAID/ZFS/Ceph) : concentrez-vous sur le remplacement du composant défaillant et la reconstruction sécurisée. Ne lancez pas de vérifications destructrices sur un ensemble dégradé à moins de savoir exactement ce qu’elles touchent.

Petite blague #2 : La seule chose plus optimiste que « ça va probablement démarrer » est « je vais lancer fsck en production à l’heure du déjeuner ».

Tâches pratiques avec commandes : sorties, signification et décisions

Ces tâches supposent Linux parce que c’est là que vous verrez les signaux les plus directs, mais la logique se transpose à Windows/macOS : observer la santé, capturer les données, réparer hors ligne, vérifier, puis prévenir la récurrence.

Task 1: Identify what block device your root filesystem is on

cr0x@server:~$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
NAME   TYPE  SIZE FSTYPE MOUNTPOINTS MODEL            SERIAL
sda    disk  1.8T        ST2000DM008  ZFL123AB
├─sda1 part  512M vfat   /boot/efi
├─sda2 part    2G ext4   /boot
└─sda3 part  1.8T ext4   /

Ce que cela signifie : Vous savez maintenant quel disque est impliqué (sda) et quelles partitions importent (sda3 est root). Si vous voyez LVM, mdraid, dm-crypt ou ZFS, votre « disque » est une pile — ne sautez pas les couches inférieures.

Décision : Si root est sur une pile complexe, vous devez collecter les données de santé à la fois au niveau physique et au niveau logique (mdadm, LVM, ZFS).

Task 2: Check recent kernel messages for disk I/O errors and resets

cr0x@server:~$ sudo dmesg -T | egrep -i "error|fail|reset|timeout|I/O|ata|nvme" | tail -n 30
[Mon Feb  5 09:11:22 2026] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Mon Feb  5 09:11:22 2026] ata1.00: failed command: READ DMA EXT
[Mon Feb  5 09:11:22 2026] blk_update_request: I/O error, dev sda, sector 1953525160 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[Mon Feb  5 09:11:23 2026] ata1: soft resetting link
[Mon Feb  5 09:11:28 2026] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)

Ce que cela signifie : Des erreurs I/O réelles au niveau bloc. L’OS a tenté de lire un secteur et le disque/contrôleur n’a pas pu fournir. La réinitialisation du lien suggère que le disque ou le chemin est instable.

Décision : Traitez cela comme un problème matériel ou de connectivité jusqu’à preuve du contraire. Passez aux contrôles SMART et câble/backplane ; priorisez l’imagerie/sauvegarde.

Task 3: Pull SMART health for SATA/SAS disks

cr0x@server:~$ sudo smartctl -a /dev/sda
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   097   097   010    Pre-fail  Always       -       24
197 Current_Pending_Sector  0x0012   098   098   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   098   098   000    Old_age   Offline      -       8
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Ce que cela signifie : « PASSED » n’est pas une assurance ; cela signifie juste que le disque n’a pas franchi un seuil constructeur. Les secteurs en attente et les irrécupérables sont de mauvaises nouvelles : le disque ne peut pas lire de manière fiable certaines zones. Les secteurs réalloués indiquent qu’il a déjà dû remapper des zones endommagées.

Décision : Si 197/198 sont non nuls et instables, remplacez le disque. Avant le remplacement, imagez-le si vous avez besoin des données. Si 199 est élevé, suspectez d’abord câble/backplane.

Task 4: Pull NVMe health (media errors, percentage used)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning                    : 0x00
temperature                         : 44 C
available_spare                     : 100%
percentage_used                     : 62%
media_errors                        : 12
num_err_log_entries                 : 98

Ce que cela signifie : Un media_errors non nul est l’équivalent NVMe d’« le dispositif n’a pas réussi à lire/écrire correctement des données ». Ce n’est pas un indicateur cosmétique.

Décision : Si les media errors augmentent, planifiez un remplacement. Si le système boucle au démarrage en réparant, passez directement à l’imagerie et à la migration.

Task 5: Check filesystem state and last fsck results (ext4 example)

cr0x@server:~$ sudo tune2fs -l /dev/sda3 | egrep -i "Filesystem state|Errors behavior|Last checked|Last mount time|Mount count|Check interval"
Filesystem state:         clean
Errors behavior:          Continue
Last mount time:          Mon Feb  5 09:02:10 2026
Last checked:             Mon Feb  5 09:01:55 2026
Mount count:              34
Check interval:           0 (<none>)

Ce que cela signifie : ext4 pense être propre maintenant, mais ça ne veut pas dire que le disque est sain. Aussi, « Errors behavior: Continue » est un piège sur des systèmes critiques ; il peut continuer en corrompant silencieusement.

Décision : Si vous avez vu des réparations au démarrage de façon répétée, changez le comportement d’erreur en « remount-ro » après stabilisation, et corrigez la cause sous-jacente (alimentation, disque, contrôleur).

Task 6: Run a non-destructive filesystem check (read-only) from a live environment

cr0x@server:~$ sudo fsck.ext4 -n /dev/sda3
e2fsck 1.46.5 (30-Dec-2021)
/dev/sda3: clean, 412156/117440512 files, 98123456/469760000 blocks

Ce que cela signifie : -n ne modifie pas le système de fichiers. « clean » suggère que le système de fichiers est cohérent.

Décision : Si le système de fichiers est propre mais que le démarrage déclenche encore des réparations, suspectez des timeouts I/O matériels ou des réinitialisations de contrôleur. Si fsck signale des erreurs même après un arrêt propre, suspectez des pilotes de corruption sous-jacents (disque, RAM, contrôleur, alimentation).

Task 7: Run an offline repair (only when the disk path looks stable)

cr0x@server:~$ sudo fsck.ext4 -f -y /dev/sda3
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Inode 924844 has invalid mode.  Clear? yes
Pass 2: Checking directory structure
Entry 'cache.tmp' in /var/tmp (924900) has deleted/unused inode 924844.  Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda3: 412155/117440512 files, 98123450/469760000 blocks

Ce que cela signifie : L’outil a fait des modifications. Cela peut être acceptable. Cela peut aussi signifier que vous venez de perdre des métadonnées pour des fichiers importants. Si cela se répète, ce n’est pas de la malchance.

Décision : Si c’était un cas isolé après un crash et que SMART est propre, poursuivez. Si les réparations continuent, arrêtez et diagnostiquez le matériel et la stabilité de l’alimentation.

Task 8: Verify the disk path is not lying (SATA CRC errors and link stability)

cr0x@server:~$ sudo smartctl -a /dev/sda | egrep -i "UDMA_CRC_Error_Count|SATA Version|Error"
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       214

Ce que cela signifie : Les erreurs CRC signifient généralement une corruption des données sur le câble, pas à l’intérieur du disque. Pensez câble, connecteur, backplane, vibration ou bruit d’alimentation.

Décision : Resserrez/remplacez le câble, changez d’emplacement dans les baies, vérifiez le backplane. Après correction du chemin physique, observez si les CRC cessent d’augmenter. Si ça continue, considérez tout le chemin comme suspect.

Task 9: Check systemd boot failures for mount issues (common on Linux servers)

cr0x@server:~$ systemctl --failed
  UNIT                          LOAD   ACTIVE SUB    DESCRIPTION
● boot.mount                    loaded failed failed /boot
● local-fs.target               loaded failed failed Local File Systems

Ce que cela signifie : Le démarrage échoue au montage des systèmes de fichiers. Cela peut être une corruption, un périphérique manquant, un UUID erroné, ou un RAID dégradé qui ne s’assemble pas.

Décision : Contrôle suivant : journaux pour comprendre pourquoi le montage a échoué, puis vérification des UUID et de la présence du périphérique bloc.

Task 10: Inspect journal logs for “superblock” and “wrong fs type” errors

cr0x@server:~$ sudo journalctl -b -p err --no-pager | tail -n 30
Feb 05 09:01:44 server kernel: EXT4-fs (sda3): bad geometry: block count 469760000 exceeds size of device (0)
Feb 05 09:01:44 server systemd[1]: Failed to mount /.
Feb 05 09:01:44 server systemd[1]: Dependency failed for Local File Systems.

Ce que cela signifie : Les métadonnées du système de fichiers ne correspondent pas à ce que le noyau pense être la taille du périphérique. Cela peut arriver avec des dispositifs défaillants, des contrôleurs cassés, ou un RAID/LVM mal assemblé qui présente un périphérique plus petit.

Décision : Arrêtez de tenter de réparer tant que vous n’avez pas confirmé que le périphérique bloc sous-jacent est correctement détecté (capacité, modèle, lectures stables). Vérifiez les couches RAID/LVM et les journaux du contrôleur.

Task 11: Confirm the device capacity is stable and not “shrinking”

cr0x@server:~$ sudo blockdev --getsize64 /dev/sda
2000398934016

Ce que cela signifie : Taille en octets. Si cela change entre deux démarrages ou après des réinitialisations, vous avez un problème de contrôleur/firmware/chemin.

Décision : Si la taille est incohérente, traitez le sous-système disque comme instable. Changez de port/contrôleur si possible, puis imagez via le chemin le plus stable.

Task 12: Assemble and check mdraid state (if applicable)

cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda1[0]
      976630336 blocks super 1.2 [2/1] [U_]
      [==============>......]  recovery = 72.3% (706000000/976630336) finish=45.0min speed=100000K/sec

Ce que cela signifie : RAID1 est dégradé : un côté manquant ([U_]). La reconstruction est en cours, ce qui génère beaucoup d’I/O.

Décision : Si vos réparations au démarrage ont commencé pendant la reconstruction, envisagez de suspendre la reconstruction intensive pour stabiliser et capturer les données. Remplacez le membre défaillant et assurez-vous que le disque survivant est sain avant de forcer une reconstruction complète.

Task 13: Check ZFS pool health and scrub status (if applicable)

cr0x@server:~$ sudo zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device and run 'zpool clear'.
  scan: scrub repaired 0B in 00:12:31 with 3 errors on Mon Feb  5 08:40:22 2026
config:

        NAME        STATE     READ WRITE CKSUM
        tank        DEGRADED     0     0     0
          mirror-0  DEGRADED     0     0     0
            sda     ONLINE       0     0     0
            sdb     FAULTED     12     0     3  too many errors

Ce que cela signifie : ZFS vous dit qu’il a vu des erreurs et mentionne même la corruption. C’est un moment « arrêtez et corrigez le matériel », pas un moment « scrubez plus fort ».

Décision : Remplacez le périphérique fautif, puis relancez le scrub. Vérifiez aussi les câbles/le firmware HBA ; ZFS expose souvent les problèmes en amont avant d’autres piles.

Task 14: Image a failing disk with minimal retries (ddrescue)

cr0x@server:~$ sudo ddrescue -f -n /dev/sda /mnt/recovery/sda.img /mnt/recovery/sda.map
GNU ddrescue 1.26
Press Ctrl-C to interrupt
rescued:   1999 GB,  errsize:   1024 kB,  current rate:   120 MB/s
ipos:   2000 GB,  errors:      12,  average rate:   118 MB/s
opos:   2000 GB,  time from start:   04:45:12
Finished

Ce que cela signifie : Vous avez récupéré presque tout ; le fichier map enregistre ce qui a échoué. -n fait une première passe sans grattage agressif — moins de stress. Les erreurs restantes peuvent être récupérables avec une seconde passe, ou perdues à jamais.

Décision : Si l’image est majoritairement complète, travaillez depuis l’image (montez en loopback, lancez fsck contre une copie). Ne continuez pas à frapper le disque original sauf si les secteurs manquants contiennent des données critiques et que vous acceptez le risque d’une panne totale.

Task 15: Mount a filesystem read-only to grab data safely

cr0x@server:~$ sudo mount -o ro,norecovery /dev/sda3 /mnt
cr0x@server:~$ ls -lah /mnt | head
total 96K
drwxr-xr-x  24 root root 4.0K Feb  5 09:02 .
drwxr-xr-x   3 root root 4.0K Feb  5 08:59 ..
drwxr-xr-x   2 root root 4.0K Jan 20 11:10 bin
drwxr-xr-x   4 root root 4.0K Feb  4 18:12 boot

Ce que cela signifie : Le montage en lecture seule réduit les écritures. norecovery (lorsque pris en charge) évite de rejouer les journaux au montage, ce qui peut écrire sur le disque.

Décision : Si cela fonctionne, copiez immédiatement les données les plus précieuses. Si cela échoue, retournez à l’imagerie et à une récupération plus approfondie.

Task 16: Find which files are on bad blocks (ext filesystems)

cr0x@server:~$ sudo badblocks -sv /dev/sda3
Checking blocks 0 to 469760000
Checking for bad blocks (read-only test): done
Pass completed, 12 bad blocks found. (12/0/0 errors)

Ce que cela signifie : Des blocs défectueux existent. Sur un disque tournant, cela corrèle souvent avec une défaillance croissante. Sur les SSD, les « bad blocks » sont plus complexes à interpréter en raison du remapping, mais les irrécupérables restent importants.

Décision : Ne vous contentez pas de « les marquer et continuer » à moins d’être prêt à travailler sur un périphérique compromis (vous ne devriez pas l’être pour quelque chose d’important). Remplacez le disque.

Task 17: Verify RAM isn’t the silent accomplice (because corruption is not always the disk)

cr0x@server:~$ sudo journalctl -k --no-pager | egrep -i "mce|machine check|EDAC|memory error" | tail -n 20
Feb 05 08:58:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Ce que cela signifie : Les erreurs ECC correctibles sont des avertissements. Si elles augmentent, elles peuvent corrompre des données en mémoire avant qu’elles ne soient écrites sur disque. Cela ressemble ensuite à des « erreurs disque ».

Décision : Si vous voyez des erreurs ECC, planifiez le remplacement des DIMM et exécutez des tests mémoire. Ne blâmez pas le système de fichiers pour ce que le sous-système mémoire a cassé.

Trois mini-histoires d’entreprise issues du terrain

1) L’incident causé par une mauvaise hypothèse : « PASSED signifie sain »

Une entreprise de taille moyenne avait une flotte de serveurs de build sur site. L’un d’eux a commencé à afficher « Réparation des erreurs du disque » au démarrage, mais il finissait par démarrer. L’astreignant a vérifié SMART, a vu « PASSED » et est passé à autre chose — parce que la pipeline était rouge et tout le monde voulait des graphiques verts avant le standup du matin.

La machine a traîné pendant une semaine. Les builds sont devenus plus lents, puis intermittents. Chaque redémarrage déclenchait un nouveau cycle de réparation. L’hypothèse de travail est devenue : « c’est juste du churn de système de fichiers après des événements d’alimentation. » Sauf que le serveur n’avait pas d’événements d’alimentation. Il avait des reprises de lecture, des timeouts et un tas croissant de secteurs en attente que personne n’a regardés parce que la ligne de synthèse paraissait correcte.

Puis est arrivé le jour où il n’est plus revenu. Le disque a finalement rendu l’âme en plein milieu du démarrage, au moment où l’outil système de fichiers écrivait des métadonnées. Le plus douloureux n’a pas été l’interruption ; c’était l’ambiguïté. Le cache du dépôt était-il corrompu ? Les artefacts étaient-ils corrompus ? Quels builds sont suspects ? Personne n’aime expliquer à la direction que « les données pourraient être erronées ».

Résultat du postmortem : ils ont arrêté de traiter SMART « PASSED » comme un verdict. Ils ont commencé à alerter sur des attributs spécifiques (pending/uncorrectable sectors, NVMe media errors, link CRC errors), et ils ont ajouté une ligne au runbook : « Si la réparation au démarrage se répète, imagez d’abord. » Pas glamour. Très efficace.

2) L’optimisation qui a mal tourné : « Ignorer les contrôles pour démarrer plus vite »

Une autre organisation exécutait des services sensibles à la latence sur bare metal. La vitesse de démarrage comptait parce que les redémarrages progressifs faisaient partie de leur rythme de patch. Quelqu’un a ajusté ext4 pour minimiser les contrôles programmés et a défini des options de montage pour maintenir le mouvement. C’était le classique « optimiser l’état stable ».

Des mois plus tard, un petit bug noyau plus quelques redémarrages watchdog brusques ont causé des incohérences de métadonnées. Les systèmes démarraient encore, pour la plupart. Mais ils démarrent de plus en plus souvent en « réparation des erreurs du disque », et la fenêtre de réparation s’allongeait à chaque fois. Personne n’a corrélé parce que les contrôles étaient rares et la flotte large. Les pannes lentes étaient diffuses — parfaites pour être ignorées.

Puis un nœud a échoué de façon particulièrement inopportune : il est resté bloqué en réparation durant une fenêtre de maintenance automatisée. Il a manqué le créneau, est revenu en retard et a déclenché des basculements en cascade parce que la planification de capacité supposait que le nœud reviendrait rapidement. Un ajustement « démarrage rapide » avait transformé silencieusement un cas récupérable en un motif d’indisponibilité prévisible.

Ils ont rétabli les réglages les plus agressifs, introduit des scrubs/offline checks périodiques pendant des fenêtres à faible trafic, et — c’est la clé — ont fait en sorte que chaque événement « réparation au démarrage » génère un ticket. Pas une tempête d’alertes. Un ticket avec un propriétaire humain. Les optimisations sont bien ; cacher les preuves, non.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : restaurations testées et remplacement échelonné

Une entreprise proche de la finance (réglementée, allergique aux surprises) faisait tourner ses systèmes centraux sur du stockage en miroir avec une discipline opérationnelle stricte. Un matin, un hôte de base de données a démarré sur un écran de réparation. L’astreignant n’a pas essayé d’être un héros. Ils ont suivi le runbook : capturer les logs, vérifier la santé des disques, retirer le nœud de la rotation et basculer.

SMART montrait des irrécupérables croissants sur un disque et une poignée d’erreurs CRC sur un autre. L’équipe n’a pas débattu sur quel indicateur « comptait le plus ». Ils ont remplacé le câble, remplacé le disque et planifié une reconstruction contrôlée. Pendant la reconstruction, ils ont gardé le nœud hors du trafic critique.

Voici la partie qui semble ennuyeuse jusqu’à ce que vous en ayez besoin : ils avaient testé les restaurations. Quand quelqu’un a demandé, « Et si la reconstruction du miroir corrompt la base de données ? » la réponse n’était pas une réunion. La réponse était : « Nous pouvons restaurer le snapshot de la nuit dernière sur un hôte propre ; nous l’avons répété le mois dernier. »

L’incident a été une non-événement. Un échange matériel, une validation et un ticket clos. Personne n’a reçu de médaille. Voilà à quoi ressemble le succès en opérations : calme et légèrement ennuyeux.

Erreurs courantes : symptôme → cause racine → correction

1) La réparation se lance à chaque démarrage, mais « ça finit par fonctionner »

Symptôme : La réparation au démarrage prend de plus en plus de temps ; gels occasionnels ; plantages applicatifs aléatoires.

Cause racine : Le disque accumule des secteurs illisibles ou le contrôleur se réinitialise sous charge.

Correction : Vérifiez SMART/NVMe et dmesg. Si des pending/uncorrectable/media errors existent, imagez le disque et remplacez-le. Si des erreurs CRC dominent, remplacez câble/backplane et retestez.

2) « mauvais type de fs » ou « superblock corrompu » après une mise à jour

Symptôme : systemd bascule en mode d’urgence ; le montage échoue ; l’outil de réparation prétend ne pas trouver de système de fichiers.

Cause racine : Changement de nommage de périphérique (mismatch d’UUID), RAID/LVM non assemblé, ou initramfs sans le bon pilote.

Correction : Vérifiez les UUID dans /etc/fstab avec blkid. Confirmez l’activation mdraid/LVM dans initramfs. Ne lancez pas fsck à l’aveugle sur le mauvais nœud de périphérique.

3) CHKDSK/fsck « répare » mais des fichiers disparaissent

Symptôme : Après la réparation, des répertoires contiennent des fragments lost+found ou des fichiers manquent.

Cause racine : La corruption des métadonnées a forcé l’outil à détacher des inodes/orphelins. C’est un comportement attendu en cas de dégâts.

Correction : Restaurer à partir d’une sauvegarde/snapshot si possible. Sinon, récupérer depuis une image avec des outils forensiques. Arrêtez les réparations répétées sur des disques défaillants ; cela augmente les dégâts.

4) La réparation est « bloquée » à un certain pourcentage

Symptôme : La progression stagne ; LED du disque allumée fixe ; ventilateurs normaux ; pas d’erreurs visibles.

Cause racine : L’outil retente de lire une région difficile, parfois pendant des heures. L’interface ne montre pas les tentatives.

Correction : Vérifiez les journaux noyau pour des timeouts I/O. Si présents, interrompez et imagez avec ddrescue. Si pas d’erreurs I/O et CPU saturé, il peut s’agir d’un scan massif d’annuaire — laissez tourner mais surveillez.

5) La reconstruction RAID démarre puis le système commence à « réparer les erreurs du disque »

Symptôme : Après remplacement d’un disque, la reconstruction de l’ensemble provoque des vérifications au démarrage, des ralentissements et des erreurs de lecture sporadiques.

Cause racine : Le disque survivant était déjà affaibli ; la charge de reconstruction l’expose. Ou le contrôleur/backplane est marginal.

Correction : Validez les disques restants avant la reconstruction. Si des erreurs apparaissent, arrêtez la reconstruction, imagez les données et planifiez une migration plus sûre. Remplacez d’abord les composants douteux.

6) Le SSD devient subitement en lecture seule ou disparaît pendant la réparation

Symptôme : Montage bascule en lecture seule ; NVMe se réinitialise ; boucles de démarrage.

Cause racine : Mode de protection firmware du SSD, problèmes d’alimentation tampon, ou défaillance du contrôleur. Parfois déclenché par des événements thermiques/power.

Correction : Récupérez les logs SMART/NVMe. Assurez-vous d’un refroidissement et d’une alimentation stables. Remplacez le périphérique ; ne lui faites pas confiance à nouveau pour des charges d’écriture importantes.

Listes de contrôle / plan étape par étape (faire ceci, puis cela)

Scénario A : Un portable/desktop affiche « Réparation des erreurs du disque » une seule fois

1. Laissez-le finir une fois. S’il termine rapidement et démarre normalement, consignez-le comme un avertissement quand même.
2. Après le démarrage, collectez les signaux de santé : SMART/NVMe, journaux d’événements OS, et récents événements d’alimentation.
3. Sauvegardez immédiatement. Pas plus tard.
4. Si SMART/NVMe montre des pending/uncorrectable/media errors, remplacez le disque.
5. Si des erreurs CRC/link apparaissent, resserrez/remplacez les câbles (desktop) ou inspectez les connecteurs.

Scénario B : Ça se répète à chaque démarrage ou ça se bloque

1. Arrêtez de redémarrer sans cesse. Les redémarrages ne sont pas des diagnostics ; ce sont des tests de stress.
2. Démarrez un environnement live (ou mode recovery) et collectez dmesg plus SMART/NVMe.
3. Si des erreurs matérielles apparaissent : imagez avec ddrescue, puis travaillez depuis l’image.
4. Si le matériel semble propre : lancez d’abord un fsck en lecture seule ; puis une réparation hors ligne si nécessaire.
5. Après réparation, validez : vérifications d’intégrité des fichiers, contrôles applicatifs et revue des logs.

Scénario C : Serveur avec RAID/ZFS et impact en production

1. Basculez ou videz le trafic si possible. Ne déboguez pas sous charge à moins d’aimer les regrets.
2. Vérifiez d’abord l’état de l’ensemble/pool (mdadm/zpool). Un ensemble dégradé change chaque calcul de risque.
3. Identifiez le composant défaillant : disque vs câble vs HBA vs backplane.
4. Remplacez le matériel suspect, puis rebuild/resilver avec surveillance.
5. Exécutez un scrub/check après la reconstruction et confirmez qu’aucune erreur silencieuse ne subsiste.

Scénario D : Vous avez besoin des données et le disque est clairement en train de mourir

1. Priorisez l’imagerie plutôt que la réparation. L’imagerie préserve les options.
2. Utilisez ddrescue avec un mapfile ; faites une première passe à faible stress.
3. Travaillez sur la copie image : essayez de monter en lecture seule ; lancez des vérifications sur une image dupliquée, pas sur la seule copie.
4. N’essayez les lectures agressives sur l’original que si les données manquantes valent le risque d’une panne totale.

FAQ

1) Est-ce que « Réparation des erreurs du disque » est toujours un signe que mon disque est en train de mourir ?

Non. Cela peut être une réaction normale à un arrêt non propre. Mais si ça se répète, ralentit, ou coïncide avec des erreurs I/O dans les journaux, supposez un risque matériel jusqu’à preuve du contraire.

2) Dois‑je interrompre le processus de réparation ?

Si vous suspectez une défaillance physique du disque (erreurs I/O, réinitialisations, secteurs en attente, media errors NVMe), oui — car la réparation écrit et peut aggraver la perte. Si c’est un unique rejeu de journal sur du matériel sain, laissez finir.

3) Pourquoi SMART affiche « PASSED » alors que le disque est manifestement en train de faillir ?

Le « overall health » SMART se base sur des seuils et varie selon les vendeurs. Des attributs comme pending sectors, uncorrectables et media errors sont souvent plus exploitables que la ligne de synthèse.

4) Quelle est la différence entre corruption de système de fichiers et mauvais secteurs ?

La corruption de système de fichiers concerne des métadonnées/structures brisées (souvent suite à des crashes, bugs ou écritures incorrectes). Les mauvais secteurs/media errors indiquent que le disque n’arrive pas à stocker ou lire des données de façon fiable. La corruption peut être réparée ; le média défaillant tend à s’étendre.

5) Est‑ce que lancer fsck/chkdsk va réparer un disque en train de faillir ?

Non. Cela peut rendre le système de fichiers cohérent au‑dessus d’un disque défaillant, mais ne répare pas le matériel. Sur un disque mourant, cela peut accélérer la panne en provoquant beaucoup d’I/O aléatoire.

6) Si je remplace le disque, puis‑je faire confiance à la copie réparée du système de fichiers ?

Parfois. Si vous avez réparé après imagerie et vérifié l’intégrité au niveau applicatif, vous pouvez être raisonnablement confiant. Si le disque renvoyait des corruptions silencieuses (rare mais réel), vous aurez besoin de sommes de contrôle et d’une validation de niveau supérieur.

7) Le RAID empêche‑t‑il cette situation de réparation au démarrage ?

Il réduit le temps d’arrêt pour des défaillances mono‑disque, mais n’empêche pas les vérifications de système de fichiers, les problèmes de contrôleur, les mauvais câbles, les bugs de firmware ou les pannes corrélées multi‑disques. De plus : une reconstruction RAID peut être le moment où le second disque rend l’âme.

8) Quelle est la manière la plus sûre de récupérer des données d’un disque défaillant ?

Imagez-le avec un outil conçu pour les médias défaillants (ddrescue) en utilisant un mapfile, puis effectuez la récupération depuis l’image. Les montages en lecture seule et les tentatives avec un minimum de reprises sont vos alliés.

9) Pourquoi la réparation prend‑elle une éternité sur de gros disques ?

Certaines vérifications sont essentiellement des scans complets des métadonnées. Si le disque est lent à cause de reprises, de timeouts ou du comportement SMR sous lectures aléatoires, cela peut s’étirer considérablement. Les journaux indiqueront lequel de ces cas vous avez.

10) Si je vois des erreurs CRC, dois‑je quand même remplacer le disque ?

Pas immédiatement. Les erreurs CRC impliquent souvent le câble/backplane. Corrigez le chemin, puis observez si le compteur CRC cesse d’augmenter. Si vous voyez aussi des pending/uncorrectable errors, remplacez le disque quoi qu’il en soit.

Prochaines étapes que vous pouvez entreprendre aujourd’hui

Si votre système affiche « Réparation des erreurs du disque » au démarrage, ne le traitez pas comme un bulletin météo. C’est un système d’alerte précoce facile à ignorer jusqu’à ce qu’il ne le soit plus.

1. Obtenez les signaux : récupérez dmesg/journalctl ainsi que les états SMART/NVMe des périphériques sous-jacents.
2. Prenez la décision : si vous voyez des media/pending/uncorrectable errors ou des réinitialisations/timeouts répétés, imagez d’abord et remplacez le matériel.
3. Réparez intelligemment : lancez des vérifications en lecture seule avant les réparations hors ligne ; ne répétez pas les « corrections » sur un disque défaillant.
4. Vérifiez : confirmez les montages, exécutez des contrôles applicatifs, passez en revue les journaux et surveillez la récurrence des erreurs pendant les jours suivants.
5. Prévoyez la prévention : corrigez la stabilité d’alimentation, les câbles/backplanes, le firmware du contrôleur, et alertez sur des attributs de santé significatifs — pas seulement « PASSED ».

Réalité opérationnelle : le disque se fiche de votre échéance. Votre meilleur mouvement est d’agir avant qu’il ne vous force la main.