Un disque tombe en panne dans votre grappe RAID 5 ou RAID 6. Le contrôleur bascule en mode dégradé et propose de lancer la reconstruction (rebuild) pour recalculer les données manquantes à partir de la parité. C’est à ce moment précis, avant même de valider le lancement, que se joue le sort de vos données : un rebuild mal engagé transforme une panne parfaitement récupérable en perte totale du volume.

Ce qui se passe réellement pendant une reconstruction

En RAID à parité (5 ou 6), la défaillance d’un disque fait basculer la grappe en mode dégradé : le contrôleur recalcule à la volée la contribution du disque manquant à partir de la parité stockée sur les autres disques, mais sans aucune marge de tolérance supplémentaire. Le rebuild, lui, va plus loin : il lit l’intégralité des secteurs de chaque disque survivant pour reconstituer les données du disque de remplacement.

Un ordre de grandeur suffit à comprendre l’enjeu : sur une grappe RAID 5 de 4 disques de 16 To, une reconstruction implique environ 48 To de lectures séquentielles réparties sur les 3 disques restants. Ce volume massif, combiné à un stress mécanique prolongé et à une redondance tombée à zéro, fait du rebuild la fenêtre la plus dangereuse du cycle de vie d’une grappe RAID.

Le rebuild RAID en 4 chiffres : 48 To de lectures sur un RAID 5 de 4x16 To, 3 à 4% de risque d'URE fatale, x13 à 16 plus long sur SMR, 2 à 7 jours de durée typique

Pourquoi un rebuild peut échouer

Plusieurs facteurs se combinent et expliquent pourquoi tant de reconstructions tournent mal :

  • Les erreurs de lecture irrécupérables (URE). En RAID 5 dégradé, une seule URE sur un disque survivant suffit à perdre définitivement les données correspondantes, sans deuxième chance. En croisant le taux d’erreur de lecture irrécupérable publié par les fabricants (de l’ordre d’une erreur pour 1014 bits lus sur un disque grand public) avec le volume à relire pendant un rebuild, le risque tombe autour de 3 à 4 % sur une grappe RAID 5 de disques de 6 To — et chute à une fraction de pourcent en RAID 6, grâce à la double parité.
  • Le stress mécanique prolongé, qui peut s’étendre sur des heures voire des jours, sollicite en continu tous les disques survivants.
  • L’usure homogène de la grappe : les disques d’une même baie partagent souvent le même modèle, le même firmware et le même nombre d’heures de fonctionnement. Quand l’un cède, les autres ne sont généralement pas loin derrière. En laboratoire, un deuxième disque qui lâche pendant ou juste après le rebuild n’a rien d’exceptionnel.

Les 5 erreurs qui transforment une panne récupérable en perte totale

La plupart des pertes de données définitives observées après un rebuild ne viennent pas de la panne initiale, mais de la façon dont la reconstruction a été menée.

  1. Lancer le rebuild sans avoir cloné les disques au préalable. C’est l’erreur la plus répandue et la plus lourde de conséquences : si la reconstruction échoue en cours de route, les données d’origine sont altérées de façon définitive, sans copie de secours sur laquelle revenir.
  2. Forcer la remise en ligne d’un disque déclaré défaillant. Un disque marqué « hors service » a parfois simplement un problème de câblage. Le forcer pousse le contrôleur à recalculer la parité à partir de données obsolètes, ce qui provoque une corruption silencieuse, sans aucun message d’erreur visible à l’écran.
  3. Se tromper dans l’ordre physique des disques après un démontage de la baie. La reconstruction s’engage alors sur des données désordonnées et écrase à la fois les données utilisateur et la parité d’origine.
  4. Reconstruire avec des paramètres incorrects : taille de bande, algorithme de parité ou décalage d’origine erronés. La structure logique du volume en ressort corrompue de manière irrémédiable.
  5. Lancer CHKDSK ou FSCK sur un volume RAID dégradé. Ces outils modifient les métadonnées pour rétablir une cohérence de système de fichiers. Face à une corruption au niveau RAID, ils peuvent détruire les dernières traces exploitables pour une récupération professionnelle.
3 erreurs qui transforment une panne récupérable en perte totale : rebuild sans clone préalable, forcer un disque déclaré hors service, mauvais ordre physique des disques

Combien de temps dure un rebuild, et le piège des disques SMR

Sur des disques de 16 à 20 To en environnement de production, comptez généralement 2 à 7 jours, parfois plus d’une semaine sous forte charge applicative. Un paramètre technique aggrave souvent la situation sans que l’utilisateur en soit conscient : les disques SMR (Shingled Magnetic Recording), utilisés pour leur coût réduit, peuvent multiplier la durée de reconstruction par un facteur de 13 à 16 par rapport à des disques CMR équivalents. Sur une grappe déjà dégradée, cette durée à rallonge prolonge d’autant l’exposition au risque et peut s’avérer fatale.

Le disque de réserve (hot spare) n’est pas une solution miracle

Un hot spare raccourcit certes le temps passé en mode dégradé, puisque le rebuild démarre automatiquement dès qu’une panne est détectée. Mais cet automatisme a un revers : la reconstruction s’enclenche sans diagnostic préalable, sans vérification de l’état réel des disques survivants ni de la présence d’une sauvegarde exploitable. En cas de défaillance logique (ransomware, suppression accidentelle, corruption applicative plutôt que panne matérielle), ce rebuild automatique ne corrige rien : il se contente de propager le problème sur le disque neuf.

Les niveaux RAID face au rebuild, en un coup d’œil

NiveauTolérance aux pannesRisque au rebuildDurée typique
RAID 0AucunePerte totale immédiateN/A
RAID 11 disqueTrès faibleQuelques heures
RAID 51 disqueÉlevé sur grande capacité2 à 7 jours
RAID 62 disquesFaible à modéré2 à 7 jours
RAID 101 par paireTrès faibleQuelques heures

La marche à suivre avant de relancer quoi que ce soit

Face à une grappe en mode dégradé, la prudence prime sur la vitesse. Voici l’ordre d’actions à respecter :

  1. Documentez l’état exact de la grappe : logs du contrôleur, ordre physique des disques, niveau RAID, taille de bande.
  2. Lancez une sauvegarde immédiate si la grappe reste accessible en lecture.
  3. Clonez chaque disque survivant au niveau secteur avant tout rebuild, dès que l’enjeu des données le justifie.
  4. Vérifiez l’état SMART des disques restants avant de vous engager plus loin.
  5. Choisissez un disque de remplacement adapté : même interface, capacité identique ou supérieure, gestion TLER/ERC compatible avec votre contrôleur.
  6. Réduisez au maximum la charge applicative pendant toute la durée du rebuild.

Quand passer par un laboratoire plutôt que retenter soi-même

Certaines situations ne pardonnent pas l’improvisation, même avec les meilleures intentions :

  • Deux disques ou plus sont défaillants : la grappe RAID 5 est perdue, une RAID 6 dispose d’un peu plus de marge mais reste critique.
  • Une première reconstruction a déjà échoué. Un rebuild partiel aggrave presque toujours la situation initiale.
  • Le contrôleur RAID lui-même semble défectueux, avec un risque réel d’écraser des métadonnées encore valides.
  • La panne est de nature logique (ransomware, suppression) : dans ce cas, le rebuild ne fait que propager l’état corrompu au lieu de le corriger.

Dans ces configurations, chaque tentative supplémentaire réduit les chances de récupération. Un laboratoire spécialisé travaille sur des copies au niveau secteur, hors ligne, avec un diagnostic préalable qui manque justement à un rebuild automatique.

Le RAID n’est pas une sauvegarde

C’est le message qui mérite d’être répété : un rebuild réussi ne protège ni contre une suppression accidentelle, ni contre un ransomware, ni contre un sinistre qui toucherait l’ensemble de la baie. Le RAID assure la disponibilité face à une panne matérielle isolée, rien de plus. Rien ne remplace une véritable stratégie de sauvegarde 3-2-1, testée régulièrement, pour couvrir les scénarios que la redondance seule ne peut pas gérer.

Si votre grappe est en mode dégradé, qu’un rebuild a déjà tourné court ou que vous hésitez avant de lancer la reconstruction, un avis technique avant toute manipulation supplémentaire peut faire la différence entre une panne récupérable et une perte définitive.