Quand un RAID, un NAS ou un serveur tombe en panne, le bon réflexe est de tout éteindre et de ne rien reconstruire : dans la majorité des cas, ce n'est pas la panne initiale qui fait perdre les données, mais la tentative de réparation qui suit : un rebuild lancé sur un système déjà fragile, un RAID supprimé puis recréé, des disques manipulés encore et encore. Un RAID dégradé peut souvent être récupéré intégralement à condition qu'on n'aggrave pas la situation. Concrètement : coupez le système, ne retentez aucune reconstruction, et confiez uniquement les disques durs à un laboratoire (le serveur ne sert à rien).

La suite explique pourquoi ces gestes comptent, et où se cachent les pièges, avec deux histoires vécues qui ont failli tout emporter.

Le RAID en trois minutes

Un RAID (Redundant Array of Independent Disks) est un assemblage de plusieurs disques vus par le système comme un seul volume, conçu pour apporter de la redondance : la capacité à survivre à la panne d'un ou plusieurs disques. Encore faut-il savoir de quelle redondance on parle, car tous les niveaux ne se valent pas.

Le RAID miroir (RAID 1) duplique automatiquement le contenu d'un disque sur un autre. Il tolère la perte d'un disque du couple, mais coûte cher en capacité : la moitié du volume total sert à la copie.

Le striping (RAID 0) fait l'inverse. Il n'y a aucune redondance, et le mot « RAID » est ici presque abusif. Le fichier est découpé en petits morceaux répartis sur plusieurs disques écrits simultanément. Le découpage se fait au niveau logiciel, très rapidement, et l'écriture en parallèle fait gagner beaucoup de vitesse. Le revers est brutal : un seul disque qui tombe, et tout est perdu. Sur trois disques en RAID 0, le risque de perte est considérable.

Le RAID 5 et le RAID 6 cherchent l'équilibre entre vitesse et sécurité. Le fichier est réparti comme en striping, mais on calcule en plus une parité (un XOR) déposée sur un disque selon un cycle, de sorte que ce n'est jamais toujours le même disque qui la reçoit. Ce calcul rend l'écriture un peu plus lente que le striping pur. En contrepartie, le RAID 5 tolère la panne d'un disque (et sacrifie l'équivalent d'un disque en volume) ; le RAID 6 tolère deux disques (et sacrifie deux disques en volume). Il faut au minimum trois disques pour un RAID 5.

Le RAID 0+1 ou 1+0 combine miroir et striping, dans un sens ou dans l'autre selon la construction, pour cumuler vitesse et redondance.

Niveau	Redondance	Disques mini	Tolérance de panne	Coût en capacité
RAID 0 (striping)	Aucune	2	0 disque (perte totale si 1 lâche)	0 %
RAID 1 (miroir)	Duplication	2	1 disque du couple	50 %
RAID 5	Parité	3	1 disque	1 disque
RAID 6	Double parité	4	2 disques	2 disques
RAID 1+0	Miroir + striping	4	1 disque par miroir	50 %

Un point mérite d'être posé d'emblée, parce qu'il est à l'origine de bien des drames : un RAID n'est pas une sauvegarde. Il protège de la panne matérielle d'un disque, rien de plus. Il ne vous sauvera ni d'une suppression accidentelle, ni d'un ransomware, ni d'un incendie, ni d'une erreur de configuration. Pour cela, il faut une vraie stratégie de sauvegarde, distincte du RAID.

Comment un RAID tombe

Les pannes que nous voyons au laboratoire suivent quelques scénarios récurrents.

La perte de la configuration. Un RAID n'existe que grâce à sa configuration : l'information qui décrit comment les disques s'assemblent en un volume. Cette configuration se trouve soit sur une carte contrôleur physique, soit inscrite sur les disques eux-mêmes, généralement en plusieurs exemplaires. Si la carte contrôleur est défectueuse, le RAID virtuel disparaît. Et même quand la configuration est répliquée sur les disques, un problème peut se propager à toutes les copies et faire perdre l'assemblage.

Le mode dégradé. Quand un disque tombe, le système le détecte et bascule en mode dégradé : plus rien n'est stocké sur le disque défaillant, et l'ensemble continue de tourner avec un disque en moins. C'est le filet de sécurité du RAID, mais un filet à usage unique. Sur un RAID 5 en mode dégradé, si un second disque lâche, la totalité des données est perdue. D'où l'importance de réagir vite, encore faut-il que les alertes du système aient bien été configurées et reçues. Beaucoup de RAID tournent en mode dégradé pendant des semaines sans que personne ne le sache.

Le rebuild : le piège que presque tout le monde sous-estime

Un rebuild est la reconstruction automatique du contenu d'un disque remplacé, à partir des données et de la parité présentes sur les autres disques du RAID. Sur le papier, c'est la procédure normale. En pratique, c'est le moment le plus dangereux de toute la vie d'un RAID.

Voici pourquoi. Les disques d'un même serveur sont presque toujours identiques : même capacité, même modèle, sortis de la même usine à la même période, du même fabricant. Ils ont ensuite tourné exactement le même nombre d'heures, dans les mêmes conditions. Ils ont donc, à peu de choses près, le même âge et la même fatigue.

Or un rebuild n'est pas une opération anodine : il lit l'intégralité des secteurs, du premier au dernier, de tous les disques restants. C'est la sollicitation la plus intense qu'un disque puisse subir. Et il arrive très régulièrement qu'un deuxième disque, aussi fatigué que celui qui vient de lâcher, choisisse précisément ce moment pour flancher. Sur un RAID 5, le système se retrouve alors incapable de reconstruire quoi que ce soit : deux disques manquants, aucune parité suffisante, données perdues.

C'est le paradoxe cruel du RAID : la procédure censée réparer la panne est aussi celle qui la transforme en catastrophe.

Les erreurs qui tuent

Au-delà du rebuild, certaines réactions humaines aggravent presque toujours la situation.

Supprimer et recréer le RAID. C'est l'erreur la plus destructrice. Face à un système qui ne monte plus, on croit bien faire en supprimant la configuration du RAID pour en recréer une neuve. Mais si l'on ne connaît pas exactement comment le RAID avait été construit (l'ordre précis des disques, la taille des blocs), on écrit par-dessus la structure existante une structure fausse, et l'on brouille les pistes qui auraient permis de tout reconstruire.

Nous nous sommes retrouvés un jour face à un cas d'école. Un informaticien gérait un système RAID de trois disques, dans un serveur qui en contenait quatre ou cinq. À la suite d'un problème, il a tout effacé et reconstruit un RAID en utilisant les cinq disques d'un coup. Le résultat était un vrai casse-tête, mais à force de travail, nous avons quand même pu récupérer les données.

Multiplier les manipulations. Le principe général à retenir : plus on travaille avec le logiciel de gestion du RAID, plus on lance de restaurations, de rebuilds, de commandes en ligne de commande, plus on prend de risque. Chaque manipulation fait tourner des disques qui sont peut-être déjà endommagés, et chaque rotation supplémentaire d'un disque mourant peut être la dernière.

Le bon geste, et ce qu'un laboratoire fait à votre place

La bonne réaction est donc contre-intuitive : ne rien faire de plus. Éteindre le système, et apporter les disques durs à un laboratoire, uniquement les disques, le serveur ou le NAS ne sont pas nécessaires.

Ce que nous faisons alors est à l'opposé du rebuild à chaud. La première étape est une copie bit à bit de chaque disque : nous figeons l'état de chacun, comme une photographie, et nous protégeons les unités d'origine. À partir de là, nous ne travaillons plus jamais sur les disques originaux, mais sur leurs copies.

Vient ensuite la reconstruction virtuelle du RAID. En analysant les copies, nous déterminons l'ordre exact des disques, la taille des blocs, le schéma de parité, et nous réassemblons le volume à la volée pour en extraire les données. Les disques d'origine, eux, ne tournent plus : ils sont à l'abri.

Une précision importante : chez nous, rien de tout cela ne comporte le risque de destruction d'un rebuild classique. Nos copies bit à bit sont elles-mêmes conservées en lecture seule, nous ne relançons jamais le logiciel des cartes RAID ni aucune reconstruction à chaud, et nous réassemblons le RAID virtuellement, à la volée. Notre procédé n'écrit rien sur vos données. La seule vraie limite est l'état physique des disques : ce qui est réellement illisible sur un plateau le reste, mais jamais du fait de la manipulation.

Pour les très gros volumes (plusieurs téraoctets, parfois 60, 70 ou 80 To répartis sur seize disques ou plus), la démarche est la même à plus grande échelle : copies bit à bit de sécurité de tous les disques, puis extraction des données vers un NAS neuf que le client met à disposition. Une fois l'opération terminée, il repart avec son nouveau NAS, données déjà restructurées comme elles l'étaient, prêt à l'emploi.

Deux conseils qui vont à contre-courant

Notre expérience nous a amenés à recommander deux choses que la logique courante déconseille.

Mélangez les marques de vos disques. Tout le monde préconise des disques identiques (même modèle, même product number) pour un système homogène qui tourne à la même vitesse. C'est juste sur le plan des performances. Mais c'est aussi la garantie que tous vos disques auront le même âge, la même usure et la même sensibilité aux pannes, d'où les défaillances en cascade pendant un rebuild. Nous préconisons plutôt des disques aux performances identiques ou très proches, mais de marques ou de séries différentes. Sur un RAID 1+0, par exemple, on peut monter le RAID 0 avec une marque et son miroir avec une autre : le jour où un défaut de série frappe une marque, l'autre tient bon.

Une histoire illustre parfaitement ce risque. Nous avons été appelés sur un NAS entièrement équipé de SSD. Tous ces SSD partageaient un défaut de firmware : une valeur interne, en mémoire, dépassait un seuil après un certain temps de fonctionnement, de l'ordre de deux à trois ans. Passé ce seuil, le firmware buguait, le SSD refusait de s'initialiser et n'était plus détecté. Le client, sur un RAID 5, a rencontré un premier problème, éteint le serveur, redémarré, inséré un SSD neuf, redémarré encore. Mais ce redémarrage a relancé tous les SSD en même temps, qui ont tous atteint la valeur fatidique simultanément. D'un coup, plus aucun disque ne fonctionnait. Avec des marques différentes, ce défaut commun n'aurait pas frappé tous les disques au même instant.

Fuyez les RAID hybrides propriétaires. Certaines marques proposent des systèmes RAID hybrides maison, qui créent par exemple des volumes virtuels à partir de plusieurs éléments assemblés d'une façon spécifique au fabricant. Sur le papier, c'est pratique. En cas de panne, de bug ou de corruption de la configuration, c'est un cauchemar : ces assemblages sont difficiles à comprendre quand rien n'a été documenté ni protocolé par les techniciens qui les ont mis en place. Un RAID standard, bien documenté, se récupère toujours mieux qu'un système propriétaire opaque.

Questions fréquentes

Que faire quand un RAID ou un NAS tombe en panne ?

Éteignez immédiatement le système et ne tentez aucune reconstruction. N'effacez pas le RAID, ne lancez pas de rebuild, ne remettez pas de disque. Retirez les disques durs (en notant leur ordre si possible) et confiez-les à un laboratoire spécialisé : c'est la manipulation, pas la panne, qui fait le plus souvent perdre les données.

Pourquoi un rebuild de RAID est-il dangereux ?

Parce qu'il lit l'intégralité des secteurs de tous les disques restants, qui ont le même âge et la même usure que celui qui vient de lâcher. Cette sollicitation intense fait souvent tomber un second disque pendant l'opération. Sur un RAID 5, la perte d'un second disque pendant le rebuild entraîne la perte totale des données.

Un RAID est-il une sauvegarde ?

Non. Un RAID protège uniquement de la panne matérielle d'un ou deux disques selon le niveau. Il ne protège ni d'une suppression accidentelle, ni d'un ransomware, ni d'un incendie, ni d'une erreur de configuration. Une vraie sauvegarde, distincte et idéalement délocalisée, reste indispensable.

Peut-on récupérer les données d'un RAID 5 dont deux disques sont tombés ?

Souvent, oui, si l'on n'a pas aggravé la situation. En laboratoire, on réalise une copie bit à bit de chaque disque, puis on reconstruit le RAID virtuellement à partir des copies pour extraire les données. Les disques d'origine ne sont plus sollicités, ce qui protège ce qui peut encore l'être.

Faut-il apporter le serveur complet au laboratoire ?

Non, les disques durs suffisent. La configuration se reconstruit à partir des disques eux-mêmes. Apporter uniquement les disques simplifie la logistique et évite de manipuler inutilement le matériel.

Faut-il utiliser des disques identiques dans un RAID ?

C'est l'usage courant, mais il a un défaut : des disques identiques vieillissent et faiblissent au même rythme, d'où des pannes en cascade lors d'un rebuild. Nous recommandons plutôt des disques aux performances proches mais de marques ou séries différentes, afin qu'un défaut commun ne les frappe pas tous en même temps.