L'utilisation de ce site, notamment notre base de connaissances, est soumise à l'acceptation de nos « conditions générales d'utilisation ». BSC DataRecovery ne pourra être tenue responsable des conséquences éventuelles relatives à l'application des conseils de cet article. Pour toute question concernant la récupération de vos données, n'hésitez pas à nous contacter via notre page « contact ».
Un RAID 5 dégradé, c'est un disque manquant et zéro tolérance restante : les données sont encore là, mais le prochain incident les rend inaccessibles. Dans l'ordre, et sans en sauter :
1. Ne redémarrez pas, ne retirez aucun disque.
2. Sauvegardez maintenant, tant que le volume monte encore.
3. Relevez le SMART de tous les disques restants, c'est lui qui décide si un rebuild est raisonnable ou suicidaire.
4. Puis seulement : remplacez le disque (CMR, gamme NAS, capacité ≥) et reconstruisez, onduleur branché.
5. Ne jetez jamais le disque sorti de la grappe.
Sauvegarder → vérifier → reconstruire. Cet ordre n'est pas négociable, et c'est précisément lui qui n'est pas respecté dans la majorité des sinistres que nous recevons au laboratoire.
Une LED orange sur la baie, un mail « Volume dégradé » du NAS, un contrôleur qui annonce Degraded au démarrage du serveur : un disque de votre RAID 5 vient d'être éjecté de la grappe. Le partage réseau répond encore, les utilisateurs travaillent, tout semble normal. C'est précisément ce qui rend cette situation dangereuse.
Un RAID 5 dégradé, ce n'est pas une panne : c'est la dernière alerte avant la panne. Vos données sont toujours là, mais la sécurité qui les protégeait a été consommée. À partir de cet instant, le moindre incident sur un des disques restants, un secteur illisible, un disque qui prend deux secondes de trop pour répondre, une coupure pendant la reconstruction, fait basculer l'ensemble du volume dans l'inaccessible.
Et c'est là que la plupart des sinistres que nous recevons au laboratoire se jouent. Dans la grande majorité des cas, le RAID n'a pas été perdu par la panne du premier disque, mais par ce qui a été fait ensuite : un rebuild lancé sans sauvegarde, un « initialize » cliqué à la place d'un « rebuild », un disque remplacé par un modèle inadapté, un volume recréé « pour réparer ». La fenêtre pour bien faire est ouverte, mais elle est étroite.
Ce guide vous donne l'ordre exact des opérations: ce qu'il faut faire dans l'heure, ce qu'il ne faut surtout pas toucher, comment décider si votre grappe peut supporter un rebuild, et quoi faire si elle ne le supporte pas.
Dégradé = un disque manquant, zéro tolérance restante. Les données sont accessibles, mais un deuxième incident les rend inaccessibles
Sauvegardez d'abord, reconstruisez ensuite. Jamais l'inverse. Tant que le volume monte encore, chaque heure passée à copier est une heure gagnée
Le rebuild est le moment le plus dangereux de la vie d'un RAID: il lit l'intégralité de tous les disques survivants, d'un seul trait, pendant des heures - exactement le stress qui achève un disque déjà fatigué
Vérifiez le SMART des disques restants avant de reconstruire. Un survivant avec des secteurs en attente = rebuild à haut risque
Ne jetez JAMAIS le disque sorti de la grappe. En cas de manipulation malheureuse, c'est souvent lui qui porte la seule copie exploitable des données
Ne remplacez jamais un disque de NAS/RAID par un disque SMR : il fera échouer le rebuild et sera éjecté à son tour
Un deuxième disque est déjà tombé ? Arrêtez tout, n'insistez pas sur le rebuild : chaque tentative supplémentaire réduit les chances de récupération
Si vous n'avez le temps de lire qu'une seule section, c'est celle-ci. Dans l'ordre, sans en sauter :
1. Ne redémarrez pas le serveur ou le NAS.
Un redémarrage peut déclencher une resynchronisation automatique, ou faire tomber un deuxième disque au moment du démarrage des moteurs (le pic de courant du spin-up est le moment le plus dur pour un disque usé).
2. Ne retirez aucun disque de la baie, même celui qui est annoncé défaillant, tant que vous n'avez pas terminé les étapes 3 et 4.
3. Photographiez la façade et l'arrière de la baie, en identifiant clairement l'ordre des emplacements. Notez le numéro de série de chaque disque et sa position. Cette photo vaut de l'or si le contrôleur perd sa configuration.
4. Copiez immédiatement les données critiques sur un support externe. Le volume est encore monté: profitez-en. Priorisez, comptabilité, dossiers clients, projets en cours, plutôt que de lancer une copie intégrale qui n'aboutira peut-être pas.
5. Relevez le SMART de tous les disques restants (voir plus bas). C'est ce relevé qui déterminera si vous pouvez tenter un rebuild ou non.
6. Réduisez la charge du volume : suspendez les sauvegardes automatiques, les indexations, les antivirus programmés, les tâches de synchronisation cloud, les machines virtuelles non essentielles. Chaque lecture inutile est un risque supplémentaire.
7. Ne lancez aucun outil de « réparation », ni
Un RAID 5 en mode dégradé (degraded), c'est l'état dans lequel un des disques membres a été retiré de la grappe, parce qu'il est tombé en panne, ou parce que le contrôleur a décidé qu'il ne répondait plus assez vite, et où le volume continue à fonctionner grâce à la parité.
Concrètement, le RAID 5 répartit les données sur au moins trois disques, et calcule pour chaque bande (stripe) un bloc de parité stocké en alternance sur les différents membres. Ce bloc est le résultat d'un XOR des blocs de données de la même rangée : il permet de recalculer mathématiquement n'importe quel bloc manquant à partir de tous les autres. C'est ce calcul qui, en mode dégradé, reconstitue à la volée les données du disque absent à chaque lecture.
Bonne nouvelle : rien n'est perdu, le serveur tourne, les utilisateurs ne voient (presque) rien.
Mauvaise nouvelle : chaque lecture coûte désormais un calcul de parité, les performances s'effondrent, en particulier en écriture, et surtout, votre unique disque de tolérance a été consommé.
Le point à retenir : un RAID 5 ne tolère qu'une seule défaillance. Ce n'est ni un bug ni un défaut de conception, c'est sa définition. Et cette tolérance n'est pas renouvelable tant que la reconstruction n'est pas terminée avec succès.
Le mot « dégradé » n'est pas réservé au RAID 5. Sur tout niveau redondant, il désigne le même état : un membre manque, le volume fonctionne encore, la marge de sécurité a été entamée. Ce qui change d'un niveau à l'autre, c'est ce qui reste de cette marge, donc l'urgence réelle.
Dans tous les cas, l'ordre des opérations de ce guide reste valable : sauvegarder, relever le SMART des survivants, puis seulement reconstruire. Les erreurs qui coûtent un volume (initialisation à la place d'un rebuild, disque retiré jeté, rebuild forcé après un deuxième disque) sont exactement les mêmes.
Les interfaces parlent rarement français, et rarement la même langue entre elles. Un même état porte quatre noms selon le constructeur, et certains messages qui font peur sont bénins, quand d'autres, anodins, annoncent une catastrophe. Voici la traduction.
Le piège de vocabulaire le plus coûteux est celui qui sépare rebuild et initialize: ces deux mots voisins dans le même menu désignent l'un une reconstruction non destructive, l'autre une réécriture de la parité qui rendra vos fichiers illisibles. Nous y revenons en détail plus bas, c'est l'erreur n°2, et c'est la plus fréquente.
Avant toute décision, il faut savoir exactement ce que voit le système : quel disque manque, depuis quand, et dans quel état sont les autres. Le voyant de façade ne suffit pas.
Dans DSM → Gestionnaire de stockage, l'onglet Groupe de stockage affiche l'état (
DSM propose un bouton « Réparer » dès qu'un disque de remplacement est inséré. Ce bouton lance un vrai rebuild md, il est légitime,mais ne le cliquez pas avant d'avoir sauvegardé et relevé le SMART des autres disques. C'est un aller sans retour : une fois lancé, la lecture intégrale des survivants commence.
En SSH, la source de vérité reste la couche Linux sous-jacente :
Storage & Snapshots → Storage/Snapshots, puis le détail du pool. Les journaux (System Logs) permettent de retrouver le moment exact où le disque a été éjecté et le message associé (erreur de lecture, timeout, disque retiré à chaud). C'est une information de diagnostic à part entière : un disque éjecté sur timeout et un disque éjecté sur erreur média n'appellent pas la même conduite.
Passez par l'utilitaire du constructeur plutôt que par le BIOS de la carte :
L'hyperviseur masque souvent l'état du RAID matériel : le datastore paraît sain alors que la grappe est dégradée depuis des semaines. Interrogez le contrôleur directement (agent constructeur, iDRAC/iLO, ou
C'est ce relevé qui va vous dire si la grappe peut supporter une reconstruction. Sur chaque disque restant :
Autrement dit : si un seul des disques survivants affiche des
Pour comprendre en détail ces valeurs, voir notre guide complet : SMART disque dur : lire les attributs et anticiper la panne.
C'est une nuance capitale, et elle change la stratégie. Un contrôleur RAID ne fait pas de diagnostic: il applique une règle brutale,si un disque ne répond pas dans le délai imparti, il est sorti de la grappe. Les causes possibles, par ordre de fréquence :
1. Le disque a réellement une panne mécanique ou électronique.
Cliquetis, disque qui ne démarre plus, carte électronique grillée. C'est le cas « propre » : le disque est mort, la grappe est dégradée, la procédure normale s'applique. Voir disque dur qui fait du bruit, disque dur qui ne s'allume plus et disque dur qui démarre puis s'arrête. Un bruit inhabituel n'est pas toujours une panne : disque dur qui fait du bruit, normal ou panne ?
2. Le disque a mis trop de temps à récupérer une erreur de lecture (problème de TLER).
Un disque de bureau, face à un secteur difficile, peut passer 30 secondes à deux minutes à réessayer avant d'abandonner. Un contrôleur RAID, lui, attend en général 7 à 8 secondes. Passé ce délai, il éjecte le disque, qui est pourtant en parfait état de marche. C'est la fonction TLER (Western Digital), ERC (Seagate) ou CCTL (autres) qui limite ce temps de retry sur les disques conçus pour le NAS : elle indique au disque d'abandonner vite et de laisser le RAID recalculer le bloc par parité. Un disque de bureau dans un RAID finit statistiquement toujours par être éjecté. Le même mécanisme de retry explique, hors RAID, un disque détecté mais très lent, copie bloquée.
3. Le disque est un SMR.
Les disques à enregistrement en tuiles (Shingled Magnetic Recording) réorganisent leurs pistes en arrière-plan. Sous écritures soutenues, exactement le profil d'un rebuild, leur cache sature, le débit s'effondre à quelques Mo/s, le contrôleur dépasse son timeout et éjecte le disque. C'est une cause majeure et totalement silencieuse de rebuilds ratés. Le sujet mérite à lui seul un article : CMR ou SMR : quel disque choisir pour un NAS ou un RAID.
4. Le problème n'est pas le disque du tout.
Câble SATA/SAS défectueux, connecteur de fond de panier oxydé, alimentation sous-dimensionnée qui fléchit quand tous les disques sollicitent en même temps, contrôleur en surchauffe. L'attribut
Pourquoi c'est important pour vous ? Parce que dans les cas 2, 3 et 4, le disque éjecté est intact et contient des données valides. C'est une ressource précieuse : en cas de manipulation malheureuse par la suite, c'est lui qui permettra la récupération. Raison de plus pour ne jamais le jeter, l'effacer, ou le réutiliser ailleurs.
Une situation intermédiaire, très fréquente, et curieusement peu traitée : le disque n'est pas encore tombé, mais le système l'a mis en garde. Selon l'interface, cela s'affiche en Predictive Failure, Warning, SMART Status: Failing, « État anormal » ou « Avertissement » dans DSM.
Vous n'êtes alors pas encore en RAID dégradé, vous êtes à quelques heures ou quelques semaines de l'être. C'est la meilleure position possible : vous avez encore votre tolérance de panne intacte, et le temps de bien faire.
Ce qu'il faut faire, dans cet ordre :
1. Sauvegardez. Vous avez la redondance de votre côté et un volume rapide : c'est le moment idéal, pas quand la grappe sera dégradée.
2. Vérifiez le SMART de tous les membres, pas seulement du disque signalé. Une alerte sur un membre d'un lot acheté ensemble annonce souvent les suivantes.
3. Commandez le disque de remplacement (voir les critères plus bas) et attendez-le sans rien faire.
4. Remplacez le disque de façon planifiée, en période creuse, onduleur branché - un rebuild lancé sur une grappe encore complète et à froid est infiniment plus sûr qu'un rebuild d'urgence.
Ce qu'il ne faut surtout pas faire : retirer le disque signalé « pour voir », ou le remplacer dans la précipitation sans sauvegarde préalable. Un disque en predictive failure participe toujours à la redondance : tant qu'il est là, la grappe est complète.
La question revient systématiquement, et la réponse dépend d'une seule chose : avez-vous une sauvegarde à jour ?
Le réflexe de « redémarrer pour voir » est le plus coûteux de tous. Sur une grappe fatiguée, un cycle d'arrêt/démarrage suffit régulièrement à empêcher un ou plusieurs disques de redémarrer - un disque qui tourne depuis trois ans sans interruption peut ne jamais repartir.
Quand vous insérez un disque de remplacement, le contrôleur lance la reconstruction : il lit l'intégralité des disques survivants, du premier au dernier secteur, pour recalculer bloc par bloc le contenu du nouveau disque. Selon la capacité et la charge, cela dure de quelques heures à plusieurs jours.
Le problème tient en une phrase : c'est la seule opération de la vie d'un RAID qui lit tous les disques à 100 %, en continu, pendant des heures. Et elle survient précisément au moment où la grappe n'a plus aucune marge.
Trois facteurs aggravants se cumulent.
Les disques ont le même âge et la même usure. Ils ont été achetés ensemble, souvent dans le même lot de production, et ont subi la même charge, la même température, les mêmes cycles. Le premier disque qui tombe est très souvent l'annonce du deuxième. Statistiquement, les défaillances d'une grappe ne sont pas des événements indépendants, c'est toute la faiblesse du modèle.
L'URE (Unrecoverable Read Error) devient probable sur les gros volumes. Les fabricants annoncent, pour un disque grand public, un taux d'erreur de lecture irrécupérable de l'ordre de 1 pour 1014 bits lus, soit environ 12,5 To lus. Or reconstruire un RAID 5 de quatre disques de 8 To impose de lire 24 To - deux fois le seuil annoncé. Ce chiffre est une valeur de spécification très conservatrice, et en pratique les disques font souvent mieux; mais le risque n'est pas théorique: un seul secteur illisible sur un survivant suffit à faire échouer le rebuild d'un RAID 5, faute de deuxième source de redondance. Les disques NAS et entreprise (1015, soit ~125 To) sont dix fois plus tolérants - une des vraies raisons de les préférer.
La reconstruction est longue et cumule les risques. Ordres de grandeur observés, à titre indicatif :
Sur un NAS grand public à processeur ARM, ces durées peuvent doubler. Pendant tout ce temps, vous êtes sans filet : une coupure de courant, un disque qui abandonne, un secteur illisible, et le volume bascule en échec.
La sauvegarde passe avant la reconstruction, toujours. Si la copie n'est plus possible parce que le système refuse ou se bloque, c'est que vous êtes déjà au-delà du dégradé simple : n'aggravez surtout pas la situation en forçant une reconstruction par-dessus.
C'est l'erreur la plus destructrice, et de loin la plus fréquente. Les interfaces de contrôleurs proposent, dans le même menu, des entrées qui se ressemblent : add array, create array, assemble, initialize, rebuild, restore, reconstruct. Sous stress, dans une situation qu'on rencontre une fois tous les cinq ans, l'utilisateur choisit la mauvaise.
La différence est pourtant radicale :
Un rebuild correct recalcule le contenu du membre manquant par parité et n'écrit que sur le disque neuf. Les disques survivants ne sont pas modifiés
Une initialisation est la synchronisation initiale d'une grappe neuve : elle recalcule et réécrit les blocs de parité sur tous les membres, à partir des données présentes, donc, avec un disque neuf en place, à partir de données parasites
Ce que ça donne concrètement : sur un RAID 5 de trois disques, environ un tiers des blocs de la grappe deviennent faux (10 % environ sur une grappe de dix disques). Cela semble « peu », mais avec une taille de bloc de 64 Ko, une période complète ne représente que quelques centaines de kilo-octets, autrement dit, presque tous les fichiers réels (photos, documents, archives, bases) sont touchés au moins une fois et deviennent illisibles. La grappe s'affiche « saine » et le volume est vide ou corrompu. Un RAID qui revient « propre mais vide » après une manipulation est, neuf fois sur dix, une initialisation accidentelle.
Le point qui sauve les cas : après une initialisation, la parité a été « réalignée » sur des données fausses. Reconstituer la grappe avec les seuls disques restants redonnerait exactement les mêmes données fausses, c'est démontrable, et c'est pour cela qu'aucun logiciel ne peut y remédier. La seule copie exploitable des données d'origine est sur le disque qui a été retiré. D'où la règle absolue qui suit.
Gardez-le. Étiquetez-le. Ne l'effacez pas, ne le testez pas dans un autre PC avec un utilitaire qui écrit, ne le rendez pas au SAV avant que vos données soient récupérées et vérifiées. Dans un dossier de récupération RAID, le disque défaillant retiré est souvent la pièce la plus importante du puzzle, nous en demandons systématiquement la restitution, y compris quand il ne démarre plus.
Réintroduire dans la baie un disque sorti depuis plusieurs jours ou plusieurs semaines crée un conflit de métadonnées : le contrôleur voit deux versions divergentes de la configuration. Selon les cas, il peut marquer la grappe comme foreign, monter une combinaison incohérente, ou proposer un rebuild qui écrasera la dernière copie saine. Le contenu de ce disque est périmé : les fichiers créés depuis sa sortie n'y ont jamais été écrits.
C'est le même raisonnement qui nous interdit, en laboratoire, de rendre les disques d'origine à leur contrôleur : l'assemblage se fait virtuellement, sur des copies, jamais sur le matériel qui a créé le conflit.
C'est l'erreur fatale. À ce stade, la grappe n'a plus de quoi recalculer quoi que ce soit, et chaque tentative fait tourner des disques déjà mourants pendant des heures, en lecture intensive, sur des zones précisément défectueuses. Un disque qui aurait pu être imagé à 99,9 % en laboratoire peut devenir totalement illisible après trois rebuilds forcés.
L'ordre des membres fait partie intégrante de la configuration RAID, au même titre que la taille de bloc ou l'algorithme de parité. Le modifier, ou recréer le volume « pour réparer », détruit les métadonnées qui décrivent la géométrie. Sur un NAS, « réinitialiser », « supprimer et recréer le groupe de stockage », « réparer le volume » ou un
Un disque de bureau sans TLER, un SMR, un modèle de capacité inférieure, ou un disque de récupération d'un autre serveur qui porte encore d'anciennes métadonnées RAID : chacun de ces choix fait échouer une reconstruction, parfois en apparaissant plusieurs heures après son démarrage.
1. Documenter avant de toucher.
Photo de la baie, numéros de série, position de chaque disque, capture d'écran de la configuration (niveau RAID, taille de bloc, ordre des membres, système de fichiers). Sur un contrôleur matériel, exportez la configuration si l'utilitaire le permet. Cinq minutes qui peuvent sauver un dossier entier.
2. Sauvegarder - priorité absolue.
Tant que le volume monte, copiez sur un support externe. Par ordre de criticité, pas par ordre alphabétique. Si vous n'avez pas assez d'espace : les données irremplaçables d'abord (ce qui n'existe nulle part ailleurs), le reste ensuite. Une copie qui plante sur certains fichiers vous renseigne aussi : elle indique où sont les zones abîmées.
3. Vérifier la sauvegarde.
Ouvrez réellement une dizaine de fichiers de types différents, dont deux ou trois volumineux. Une copie « terminée sans erreur » n'est pas une preuve, c'est exactement le principe que nous appliquons en laboratoire avant de valider une récupération (voir la liste de fichiers récupérés, à vérifier avant paiement).
4. Relever le SMART de tous les survivants, et décider.
Tous les compteurs
5. Choisir le bon disque de remplacement.
Même capacité que les autres membres, ou supérieure (le surplus sera perdu). Jamais inférieure, même de quelques Go - deux disques « 4 To » de marques différentes n'ont pas exactement le même nombre de secteurs
CMR obligatoire, jamais SMR. Vérifiez la référence complète (
Gamme NAS ou entreprise, avec TLER/ERC activable : WD Red Plus / Red Pro, Seagate IronWolf / IronWolf Pro / Exos, Toshiba N300 / MG. Attention : le « WD Red » tout court peut être SMR, le Red Plus ne l'est pas
Disque neuf, sorti de son emballage. Un disque de récupération peut porter d'anciennes métadonnées RAID qui perturbent le contrôleur
Vérifiez la compatibilité firmware avec votre contrôleur ou votre modèle de NAS (liste de compatibilité constructeur)
Pour la fourniture du matériel et le montage, BSC Informatique (atelier de Hyères) sélectionne les disques compatibles NAS et RAID et se charge du remplacement.
6. Insérer le disque et lancer la reconstruction - au bon moment.
Vendredi soir ou pendant une période creuse, jamais en pleine activité. Coupez ce qui peut l'être : sauvegardes planifiées, indexation, antivirus programmé, synchronisation cloud, machines virtuelles non essentielles. Sur un NAS, réglez la priorité de reconstruction pour privilégier la vitesse plutôt que le service, si vous pouvez vous permettre l'indisponibilité.
7. Brancher l'onduleur - vraiment.
Une coupure de courant en plein rebuild sur une grappe sans redondance est un des scénarios les plus destructeurs qui soient. Si vous n'avez pas d'onduleur, ce n'est pas le moment de reconstruire.
8. Surveiller la reconstruction.
Contrôlez la progression et la température des disques (un rebuild fait grimper de 8 à 12 °C ; au-delà de 50 °C, améliorez la ventilation ou pausez). Surveillez le SMART pendant l'opération. Si un autre disque commence à générer des erreurs, arrêtez : mieux vaut une grappe dégradée figée qu'une grappe en échec.
9. Après le rebuild : vérifier, puis corriger la cause.
Une fois la grappe revenue en optimal, lancez un contrôle de cohérence (scrub / data scrubbing), refaites une sauvegarde complète, et posez-vous la vraie question: pourquoi ce disque est-il tombé ? Si les autres membres ont le même âge, planifiez leur remplacement échelonné, ou la migration vers un niveau à double parité.
Situation courante sur les serveurs correctement configurés : un hot spare (disque de rechange déclaré dans la grappe) a pris la place du membre défaillant, et la reconstruction a démarré sans que personne ne clique. Vous découvrez la chose une heure ou un jour plus tard.
Le réflexe naturel, couper pour reprendre la main, est le mauvais. Un rebuild interrompu brutalement laisse la grappe dans un état intermédiaire ; sur certains contrôleurs, il repart de zéro au redémarrage, ce qui vous fait subir deux fois le stress de lecture. Ce qu'il faut faire :
1. Laissez-le finir, sauf si un autre disque commence à générer des erreurs pendant l'opération. Un rebuild qui progresse normalement est en train de vous rendre votre tolérance de panne.
2. Pendant qu'il tourne, réduisez tout le reste : sauvegardes planifiées, antivirus, indexation, VM non essentielles.
3. Surveillez le SMART des survivants et la température à intervalles réguliers.
4. Ne sauvegardez pas en parallèle sur le volume lui-même si vous pouvez l'éviter: vous doubleriez la charge de lecture au pire moment. Si vos données ne sont nulle part ailleurs, c'est un arbitrage à faire, et dans ce cas la sauvegarde reste prioritaire, à débit réduit.
5. Quand c'est terminé : contrôle de cohérence, sauvegarde complète, puis remplacement du hot spare consommé (une grappe sans rechange déclaré n'a plus de filet automatique).
Le cas qui doit vous alerter : un rebuild automatique qui se relance en boucle, ou qui échoue toujours au même endroit. Là, ce n'est plus un incident, c'est un survivant défaillant - voir Quand le rebuild échoue.
La réponse dépend de ce que vous voulez obtenir.
Mettre en pause : oui, et c'est souvent utile. La plupart des contrôleurs matériels et des NAS permettent d'abaisser la priorité de reconstruction, voire de la suspendre (réglage de
Annuler purement et simplement : possible, mais rarement souhaitable. Interrompre un rebuild vous ramène en mode dégradé, avec un disque neuf partiellement écrit qui devra tout recommencer. Les seules bonnes raisons de le faire :
un autre disque commence à générer des erreurs pendant l'opération (compteurs qui bougent, ralentissements brutaux, journal qui se remplit d'erreurs média) : arrêter est alors la bonne décision, une grappe dégradée figée se récupère bien mieux qu'une grappe effondrée
vous découvrez en cours de route que vous n'avez aucune sauvegarde et que les compteurs SMART des survivants sont mauvais : mieux vaut geler la situation et faire imager les disques
le disque de remplacement se révèle inadapté (SMR, capacité insuffisante) : il vaut mieux arrêter que de laisser le contrôleur l'éjecter en plein rebuild
Ce qu'il ne faut jamais faire pour « annuler » : couper l'alimentation, retirer un disque à chaud, ou redémarrer brutalement le serveur. Passez toujours par l'interface, et si elle ne répond plus, appelez avant d'improviser.
La majorité des grappes dégradées que nous recevons proviennent de NAS de TPE, d'associations ou de particuliers avancés. Quelques spécificités qui changent la donne.
C'est du RAID logiciel Linux. Synology (y compris en SHR, qui superpose plusieurs grappes md pour gérer des disques de tailles différentes), QNAP, Asustor, TerraMaster reposent sur mdadm, souvent complété par LVM, avec un système de fichiers ext4 ou Btrfs. Conséquence pratique : la configuration n'est pas enfermée dans un contrôleur propriétaire, elle est écrite sur les disques eux-mêmes, dans le superbloc md que chaque membre porte en propre. C'est une bonne nouvelle pour la récupération: même sans le NAS d'origine, boîtier mort, alimentation grillée, modèle introuvable, les disques suffisent à reconstituer le volume.
La structure typique déroute les non-initiés : chaque disque contient d'abord de petites partitions montées en RAID 1 (le système du NAS et le swap, identiques sur tous les membres), puis une grande partition qui porte le RAID 5 de données. Voir un « RAID 1 » dans les outils d'analyse ne signifie donc pas que vos données sont en miroir.
Le disque sans superbloc md valide (ou dont l'Update Time est ancien) est le membre sorti de la grappe. C'est souvent la première chose que nous identifions sur un dossier NAS, et c'est aussi lui qui, s'il est réintégré à l'aveugle, ramène des données périmées.
Ce qu'il ne faut jamais faire sur un NAS dégradé :
réinitialiser le NAS (même le « reset doux » qui « ne touche pas aux données » : il peut recréer des partitions système)
supprimer puis recréer le groupe de stockage ou le volume
lancer un
accepter la proposition « réparer le système de fichiers » avant d'avoir sauvegardé
mettre à jour le firmware du NAS pendant que le volume est dégradé
retirer les disques de leurs baies sans les numéroter (voir la règle des baies avant d'envoyer les disques)
Si le NAS lui-même est en panne (il ne démarre plus, le volume ne monte plus), le sujet est traité marque par marque : NAS Synology en panne, NAS QNAP en panne : volume non monté, voyant rouge, NAS Asustor, TerraMaster, Buffalo, ReadyNAS en panne et, pour les boîtiers à un ou deux disques, WD My Cloud, My Book Live, Seagate Personal Cloud en panne.
Boîtier mort et disques sains ? Avant de brancher un membre sur un PC, lisez NAS mort, disques sains : lire un disque ext4 ou Btrfs sur PC : un membre de RAID 5 pris isolément ne contient qu'une fraction de chaque fichier, et Windows proposera de l'initialiser. Refusez.
Une coupure de courant, une microcoupure, un onduleur en fin de batterie : au redémarrage, la grappe est annoncée dégradée, ou un disque a disparu. C'est un scénario à part, parce que la cause n'est pas nécessairement un disque en panne.
Ce qui se passe réellement. Une coupure brutale interrompt les écritures en cours. Le contrôleur (ou mdadm) constate au redémarrage que les compteurs d'événements des membres divergent, et exclut celui qui est « en retard ». Le disque exclu peut être parfaitement sain. Par ailleurs, le spin-up simultané de tous les disques après une coupure est le pic de contrainte électrique le plus élevé du cycle de vie d'une baie : c'est aussi le moment où un disque déjà fatigué ne repart pas.
La conduite à tenir :
1. Ne relancez pas de resynchronisation dans la foulée. Vérifiez d'abord l'état de chaque membre et de l'alimentation.
2. Contrôlez l'alimentation et l'onduleur avant tout le reste. Une alimentation qui fléchit va reproduire l'incident, et cette fois pendant le rebuild.
3. Regardez le
4. Attention au système de fichiers. Après une coupure, la grappe peut remonter « saine » et le volume être incohérent (journal ext4/Btrfs, NTFS marqué sale). C'est le moment où l'on est tenté de lancer une réparation automatique, c'est exactement ce qu'il ne faut pas faire avant d'avoir sauvegardé.
5. Si le contrôleur a une batterie/condensateur de cache (BBU/CacheVault) déchargée, il désactive le cache en écriture : le volume devient très lent mais fonctionne. C'est une alerte à traiter, pas une panne de disque.
Les grappes montées sur carte mère ou par le système méritent une mise au point, parce que leurs pièges sont différents.
Intel RST (RAID de chipset). L'utilitaire annonce le volume Degraded ou « Non redondant ». Deux spécificités : le RAID est piloté par le pilote Windows, donc une réinstallation système ou un changement de mode SATA (RAID ↔ AHCI dans le BIOS) suffit à rendre le volume invisible, ce n'est pas une perte de données, c'est un changement de mode à annuler. Et les métadonnées, elles, sont bien sur les disques. Avant toute manipulation dans l'utilitaire Intel: sauvegardez, et n'utilisez jamais l'option de réinitialisation des disques en non-RAID, qui efface les métadonnées. Un volume ou un SSD qui disparaît après une mise à jour du BIOS ou de Windows relève souvent du même mode Intel VMD / RST : SSD NVMe disparu après mise à jour BIOS ou Windows.
RAID logiciel Windows (disques dynamiques / LDM). Les volumes agrégés par bandes avec parité sont visibles dans la Gestion des disques avec la mention « Échec de la redondance ». La reconstruction se fait par « Réactiver le volume » puis « Réparer le volume » - après sauvegarde, comme partout ailleurs. Particularité utile à connaître: sous LDM, une même partition peut appartenir à plusieurs volumes différents, ce qui rend l'analyse plus complexe qu'un mdadm.
Windows Storage Spaces. Ce n'est pas un RAID au sens classique : un pool combine des disques de tailles et de connectiques différentes, et la répartition des données est décrite dans les métadonnées, pas par une règle de calcul régulière. Conséquences pratiques : un espace de stockage en état « Avertissement » ou « Réduit » se répare depuis le panneau Espaces de stockage (après ajout d'un disque), mais aucun outil générique de reconstruction RAID ne peut deviner sa géométrie - la récupération passe obligatoirement par la lecture des métadonnées du pool. C'est faisable en laboratoire, mais cela exclut les logiciels grand public qui « détectent le RAID automatiquement ». Détail dans Drobo, Storage Spaces, Synology SHR : les RAID que les logiciels ne lisent pas.
Dans les trois cas, la règle reste identique : sauvegarder avant de réparer, et ne jamais laisser un assistant recréer un pool ou un volume « pour corriger l'erreur ».
Un rebuild peut s'arrêter en cours de route, se figer, ou repasser la grappe en échec. Le pourcentage auquel il s'arrête est une information de diagnostic à part entière.
Il s'arrête toujours au même pourcentage.
C'est la signature d'un secteur illisible à un endroit précis d'un des disques survivants. Relancer ne changera rien : le contrôleur rebutera au même endroit, en stressant à nouveau tous les disques. C'est le cas typique où l'imagerie bas niveau résout tout: un matériel d'imagerie professionnel lit la zone difficile avec des réglages adaptés, timeouts courts, lecture par blocs, passes multiples, contournement des zones instables, et produit une copie complète sur laquelle la reconstruction se fait sans obstacle.
Dans tous les cas : ne relancez pas en boucle. Deux tentatives infructueuses suffisent à établir que la voie du rebuild est fermée. La suite est un travail sur copies, pas sur originaux.
Le cas est traité symptôme par symptôme dans Rebuild RAID échoué ou bloqué à X % : arrêtez tout.
C'est la situation la plus difficile, mais elle est loin d'être désespérée. La grande majorité des RAID 5 à deux disques défaillants que nous traitons repartent avec l'essentiel des données, voire l'intégralité. La condition : que la grappe n'ait pas été « travaillée » entre-temps.
La récupération se fait en deux temps, et jamais sur les disques d'origine en écriture.
Chaque membre, y compris ceux qui semblent morts, y compris celui qui a été retiré en premier, est copié secteur par secteur vers un disque sain, sur un matériel d'imagerie spécialisé. Ce matériel permet ce qu'un PC ne sait pas faire: régler les temporisations, isoler les têtes défaillantes, lire dans un ordre choisi, gérer les zones instables sans épuiser le disque, reprendre une imagerie interrompue. Quand la panne est mécanique (têtes, moteur), l'intervention passe par le remplacement des têtes en salle blanche avant de pouvoir imager quoi que ce soit.
À partir de ce moment, tout le travail se fait sur les copies. Les disques d'origine ne sont plus touchés, c'est ce qui rend l'opération sans risque supplémentaire, et c'est aussi pourquoi il ne faut jamais bricoler avant.
Reste à retrouver la géométrie exacte du RAID, à partir des images. Ce que nous devons déterminer :
quels disques font réellement partie de la grappe (une baie contient parfois un hot spare, un disque système, ou le disque d'une autre grappe)
l'ordre des membres, qui n'est pas nécessairement l'ordre physique dans le châssis
la taille de bloc (stripe size)
l'algorithme de parité : sur un RAID 5, la position du bloc de parité (gauche/droite) et celle des blocs de données par rapport à lui (synchrone/asynchrone) donnent quatre combinaisons possibles
le décalage de départ (start offset), l'espace de service réservé en tête de disque, qui n'est pas forcément un multiple de la taille de bloc
le delay éventuel, c'est-à-dire le nombre de groupes consécutifs conservant la même distribution - un paramètre qu'on rencontre notamment sur d'anciens contrôleurs HP/Compaq et Adaptec
Quand les métadonnées sont présentes (superbloc md d'un NAS, métadonnées LVM, Btrfs, VMFS, configuration d'un contrôleur connu), la configuration se retrouve directement. Quand elles ont été détruites, initialisation accidentelle, volume recréé, disques mélangés, elle se déduit du contenu même des disques : analyse statistique de la répartition des données pour faire apparaître la périodicité des blocs de parité, recherche des structures du système de fichiers, et validation finale.
La validation, justement, est le point que les logiciels grand public ratent : voir une arborescence s'afficher ne prouve rien. Un petit fichier tient dans un seul bloc et s'ouvrira même avec un ordre de disques erroné. La seule preuve qu'une configuration est correcte, c'est qu'un fichier plus gros qu'une période complète de la grappe s'ouvre parfaitement. C'est le test que nous appliquons systématiquement avant de lancer l'extraction.
Il mérite d'être connu, car il explique bien des récupérations qui semblent impossibles. Quand un disque est sorti de la grappe longtemps avant le sinistre, parfois des mois, sans que personne ne voie l'alerte, son contenu est figé à cette date: les fichiers créés depuis n'y ont jamais été écrits. L'assembler tel quel produit une arborescence qui s'ouvre… avec des fichiers récents corrompus.
En laboratoire, ce membre est identifié (superbloc absent ou Update Time ancien), puis exclu de l'assemblage : son contenu est recalculé par la redondance à partir des autres membres. Un fichier récent qui s'ouvre correctement après cette manipulation, et pas avant, est la signature du cas.
L'écart de temps entre les deux défaillances. Plus il est grand, plus le premier disque est périmé, mais c'est un problème traitable (voir ci-dessus)
Ce qui a été tenté avant. Une grappe intacte se récupère quasi intégralement. Une grappe qui a subi trois rebuilds forcés et une recréation de volume, beaucoup moins
L'état physique des membres. Un disque imagé à 100 % ne pose aucun problème; à 99,9 %, quelques fichiers seront touchés - ceux dont les secteurs manquants tombent dans les zones illisibles
Notre laboratoire traite toutes les configurations : RAID 0, 1, 5, 6, 10, 50, JBOD, SHR, mdadm/LVM, Btrfs, ZFS, Storage Spaces, VMFS et machines virtuelles, sur baie matérielle, contrôleur logiciel ou NAS.
Pour maximiser les chances, un dossier RAID complet comprend :
tous les disques de la grappe, y compris ceux qui sont déclarés morts
le disque qui a été retiré en premier - celui qu'on est tenté de jeter, et qui est souvent décisif
l'ordre des emplacements (votre photo, ou des étiquettes)
le modèle du NAS ou de la carte contrôleur, et si possible le niveau RAID et la taille de bloc
l'historique honnête de ce qui a été tenté : rebuild lancé, volume recréé, logiciel de récupération exécuté, réinitialisation… Cette information ne sert pas à juger, elle sert à savoir ce qui a été écrit et où chercher. Un client qui dit « j'ai cliqué sur quelque chose, je ne sais plus quoi » nous fait gagner des heures
une liste des fichiers ou dossiers prioritaires, elle permet souvent d'extraire l'essentiel avant même d'avoir terminé le traitement complet
Le boîtier NAS lui-même n'est en général pas nécessaire, mais il peut aider sur des modèles au partitionnement atypique. Où que vous soyez en France, vous pouvez nous expédier les disques par colis suivi via notre service de récupération de données à distance : suivez la règle des baies pour envoyer les disques d'un NAS ou d'un RAID et nos consignes d'emballage d'un disque dur pour l'expédition, en emballant chaque disque séparément et en numérotant les emplacements.
Certaines activités reviennent souvent dans les dossiers RAID, chacune avec ses urgences : rushes et projets d'un vidéaste sur disque ou RAID en panne, projets d'architecte ou de bureau d'études sur un NAS en panne, base EBP, Sage ou Ciel sur un serveur HS, vidéosurveillance, caisse ou serveur d'un commerce. Dans tous ces cas, la liste des dossiers prioritaires fait gagner des jours.
Une fois la grappe reconstruite ou les données récupérées, quelques décisions évitent la récidive.
Le RAID n'est pas une sauvegarde.
C'est le malentendu le plus coûteux du stockage professionnel. Un RAID protège contre la panne d'un disque, et contre rien d'autre : ni la suppression accidentelle, ni le ransomware, ni le formatage malheureux, ni le dégât des eaux, ni le vol du serveur. Il augmente la disponibilité, pas la sécurité des données. La règle 3-2-1 reste la seule protection réelle : trois copies, sur deux supports différents, dont une hors site. Notre article qu'est-ce qu'une sauvegarde et pourquoi c'est important détaille la mise en pratique, et rappelle pourquoi les clés USB et les SSD sont de mauvais supports de sauvegarde au long cours.
Activez le contrôle de cohérence périodique (data scrubbing sur Synology/QNAP, patrol read / consistency check sur les contrôleurs matériels), une fois par mois ou par trimestre. Son rôle est précisément de découvrir les secteurs illisibles pendant que la redondance est encore disponible pour les corriger - au lieu de les découvrir en plein rebuild, quand il est trop tard. C'est la mesure préventive la plus rentable qui existe sur un RAID 5.
Activez les alertes.
Un très grand nombre de grappes arrivent chez nous avec deux disques tombés à plusieurs mois d'intervalle, parce que personne n'a vu passer la première alerte : notification e-mail non configurée, adresse obsolète, voyant à l'arrière d'un serveur dans un local que personne ne visite. Configurez une notification par e-mail testée pour de bon (envoyez-vous un test, vérifiez qu'il n'atterrit pas en indésirable), et vérifiez visuellement la baie tous les mois.
Ne renouvelez pas tous les disques du même lot.
Si les autres membres approchent des 50 000 heures, remplacez-les de manière échelonnée, de préférence avec des références ou des lots de fabrication différents.
Gardez un disque de rechange sur l'étagère.
Le même modèle, acheté à l'avance. Le jour où un membre tombe, vous n'attendez pas trois jours de livraison en mode dégradé.
La question se pose une fois les données à l'abri, pas avant. Voici de quoi trancher.
La règle empirique la plus utile : au-delà de 4 To par disque, le RAID 5 devient un pari. Non pas parce qu'il est mal conçu, mais parce que le temps de rebuild et le volume lu pendant celui-ci dépassent ce qu'un lot de disques vieillissants encaisse sans incident. Le RAID 6 rend le rebuild survivable ; le RAID 10 le rend court. Le coût du disque supplémentaire est sans commune mesure avec celui d'une récupération.
Et dans tous les cas, cela mérite d'être répété,aucun de ces niveaux ne remplace une sauvegarde.
Les niveaux non traités dans ce guide ont chacun leur page : RAID 1 en panne et RAID 0 en panne.
Trois facteurs déterminent le devis : le nombre de disques abîmés (pas le nombre de disques de la grappe), leur état physique et la complexité de la reconstruction (métadonnées présentes ou géométrie à déduire). Notre grille NAS / RAID est publique :
Quatre situations courantes sur un RAID 5 dégradé :
Grappe saine, configuration du contrôleur perdue (tous les disques lisibles) : 190 €
Un disque sorti de la grappe, puis le volume ne monte plus ; un survivant a des secteurs défectueux, le disque sorti est lisible : 190 € + 390 € = 580 €
Le disque sorti claque, les trois autres membres sont sains : la parité suffit, on n'ouvre pas le disque qui claque : 190 €
Deux disques en panne mécanique, initialisation accidentelle ou volume recréé puis rebuild forcé : sur devis, après le diagnostic gratuit
Diagnostic et devis : gratuits et sans engagement. Vous connaissez le montant avant toute intervention
Délai de diagnostic : 24 à 48 h selon la complexité
Cas logique (grappe saine, configuration perdue, initialisation accidentelle) : traitement généralement rapide, l'essentiel du travail étant l'assemblage virtuel et la validation
Cas physique (un ou plusieurs membres à imager, têtes à remplacer) : le délai dépend de l'imagerie, qui est l'étape la plus longue et la moins compressible
Extraction prioritaire possible : si vous fournissez une liste de dossiers critiques, ils peuvent souvent être sortis avant la fin du traitement complet
Le détail est expliqué dans prix d'une récupération de données NAS et RAID : ce qui fait le devis, devis de récupération : fourchette avant diagnostic et comparaison de deux devis et le diagnostic gratuit en laboratoire, étape par étape. La grille tarifaire complète couvre tous les supports. Voir aussi combien coûte une récupération de données et taux de réussite et délais.
Un RAID 5 dégradé fonctionne-t-il encore normalement ?
Oui, il sert toujours les données, mais avec des performances nettement réduites (chaque lecture du membre absent exige un calcul de parité) et zéro tolérance de panne. Considérez-le comme un sursis : sauvegardez sans attendre.
Combien de temps peut-on rester en mode dégradé ?
Techniquement indéfiniment, et c'est bien le piège, car « ça marche » invite à repousser. Chaque jour supplémentaire augmente la probabilité qu'un deuxième disque lâche, sur des membres de même âge et de même usure. La bonne réponse: sauvegarder immédiatement, puis remplacer rapidement si les autres disques sont sains.
Puis-je continuer à travailler sur le volume pendant qu'il est dégradé ?
Techniquement oui, mais réduisez la charge au strict nécessaire, et faites votre sauvegarde en priorité. Évitez absolument les opérations lourdes : gros imports, réindexation, sauvegardes complètes vers d'autres systèmes, machines virtuelles intensives.
Le rebuild peut-il faire perdre les données ?
Oui, c'est le moment le plus risqué de la vie de la grappe. La lecture intégrale des survivants peut révéler une erreur de lecture irrécupérable (URE) ou achever un disque déjà usé. D'où la règle : sauvegarder avant, vérifier le SMART, et renoncer au rebuild si un survivant est douteux.
Combien de temps dure un rebuild de RAID 5 ?
De quelques heures à plusieurs jours selon la capacité, le nombre de membres, la puissance du contrôleur et la charge du système. Comptez 8 à 14 h pour des disques de 4 To sur une grappe au repos, plusieurs jours pour des disques de 8 à 12 To sur un NAS en production.
Peut-on arrêter ou mettre en pause un rebuild en cours ?
Une pause (ou une baisse de priorité) ne détruit rien et peut être utile pour faire retomber la température ou laisser passer une sauvegarde. Une annulation vous ramène en mode dégradé et oblige à tout recommencer : à ne faire que si un autre disque se met à générer des erreurs, ou si vous découvrez que le disque de remplacement est inadapté. Ne coupez jamais l'alimentation pour arrêter un rebuild.
Un rebuild s'est lancé automatiquement (hot spare) : dois-je l'interrompre ?
Non, sauf si un autre disque commence à générer des erreurs. Laissez-le finir en réduisant tout le reste de la charge, et surveillez SMART et température. Remplacez ensuite le hot spare consommé.
Faut-il un disque exactement identique pour le rebuild ?
Idéalement oui : même capacité, même gamme, même technologie. Une capacité supérieure fonctionne (le surplus est perdu), une capacité inférieure jamais - attention, deux disques annoncés « 4 To » de marques différentes peuvent différer de quelques millions de secteurs. Et dans tous les cas: CMR, jamais SMR.
Puis-je remplacer un disque de NAS par un disque de bureau ordinaire ?
Très déconseillé. Sans TLER/ERC, le disque passe trop de temps à réessayer sur une erreur de lecture et finit par être éjecté par le contrôleur, alors qu'il est en bon état. C'est une cause classique de grappes qui se dégradent à répétition.
Mon rebuild a échoué à 99 %, que faire ?
Ne le relancez pas en boucle. Un blocage reproductible au même pourcentage signale un secteur illisible précis sur un disque survivant. Arrêtez et faites imager les disques en laboratoire : la reconstruction se fera ensuite sur les copies, sans obstacle.
Le NAS me propose de « réparer » le volume : je clique ?
Pas avant d'avoir sauvegardé. « Réparer » recouvre selon les cas une resynchronisation légitime… ou une réécriture destructive. Si vos données ne sont pas ailleurs, cette question n'a qu'une réponse : sauvegarder d'abord.
J'ai lancé une initialisation au lieu d'un rebuild. C'est fini ?
Non - à une condition: ne jetez pas le disque que vous avez retiré. Après une initialisation, la parité a été recalculée sur des données parasites et les seuls disques restants ne suffisent plus à retrouver les données d'origine. Le disque sorti de la grappe porte la copie manquante : avec lui, une récupération complète reste possible dans la plupart des cas.
Mon contrôleur affiche « Foreign configuration » : j'importe ou j'efface ?
Ni l'un ni l'autre dans la précipitation. Importer est en général non destructif et souvent la bonne action après un changement de carte ou un déplacement de disques ; effacer écrase les métadonnées du disque et peut coûter la récupération. Documentez l'état actuel (photos,
Un disque est en « predictive failure » mais la grappe est encore saine : que faire ?
C'est la meilleure position possible. Sauvegardez pendant que la redondance est intacte, vérifiez le SMART de tous les membres, commandez le bon disque, puis remplacez de façon planifiée en période creuse. Ne retirez pas le disque signalé « pour voir » : tant qu'il est là, la grappe est complète.
Peut-on récupérer un RAID 5 dont la configuration du contrôleur a été perdue ?
Oui, dans la grande majorité des cas. L'ordre des disques, la taille de bloc, l'algorithme de parité et le décalage de départ se retrouvent par analyse des métadonnées présentes sur les disques, ou à défaut par analyse du contenu lui-même, même sans le contrôleur d'origine, et même si celui-ci n'existe plus.
Mon NAS est mort mais les disques sont bons : les données sont-elles perdues ?
Non. Sur les NAS Synology, QNAP, Asustor et assimilés, la configuration RAID est écrite sur les disques (superbloc mdadm), pas dans le boîtier. Les disques seuls suffisent à reconstituer le volume et à en extraire les données.
Deux disques sont tombés en même temps : y a-t-il encore un espoir ?
Oui, très souvent. Les deux défaillances sont rarement simultanées et rarement totales : un membre est fréquemment imageable à 100 %, l'autre à 99 % et quelques poussières. Le facteur décisif n'est pas le nombre de disques tombés, mais ce qui a été tenté après.
Le volume est remonté après une coupure de courant, mais un disque a disparu : il est mort ?
Pas nécessairement. Une coupure interrompt les écritures et fait diverger les compteurs d'événements : le contrôleur exclut le membre « en retard », qui peut être parfaitement sain. Vérifiez l'alimentation et l'onduleur avant de relancer quoi que ce soit - sinon l'incident se reproduira, cette fois pendant le rebuild.
Un logiciel de récupération RAID du commerce peut-il faire l'affaire ?
Sur une grappe dont tous les membres sont physiquement sains et dont il ne manque que la configuration, oui, parfois. Dès qu'un disque a des secteurs illisibles, non : le logiciel va marteler les zones défectueuses pendant des heures et achever le disque, alors qu'un matériel d'imagerie professionnel l'aurait copié proprement. Nous détaillons ces limites dans logiciels gratuits de récupération : ce qu'ils savent faire et ce qu'ils cassent.
Un RAID 1, un RAID 6 ou un SHR « dégradé » : même conduite qu'un RAID 5 ?
Oui pour l'ordre des opérations : sauvegarder, relever le SMART, reconstruire ensuite. Ce qui change, c'est la marge. Un RAID 1 ou un SHR simple dégradé n'a plus aucune tolérance, comme un RAID 5. Un RAID 6 ou un SHR-2 avec un seul disque tombé en garde encore une : c'est le meilleur moment pour agir au calme. Un RAID 0 ne se dégrade pas : un disque en moins, le volume est en échec. Voir le tableau par niveau.
Peut-on reconstruire un RAID 5 dégradé sans perdre les données ?
Oui, c'est le fonctionnement normal : la reconstruction recalcule le disque manquant par parité et n'écrit que sur le disque neuf. Elle ne devient dangereuse que si un survivant a des secteurs illisibles (le rebuild échoue et peut l'achever), si le courant coupe en cours de route, ou si l'on clique « initialiser » à la place de « reconstruire ». D'où les trois conditions : sauvegarde faite, SMART des survivants propre, onduleur branché.
Combien coûte une récupération de RAID 5 ?
190 € pour la reconstruction du volume quand tous les disques sont lisibles, plus 390 € par disque à secteurs défectueux ou à carte électronique grillée, et à partir de 790 € par disque à ouvrir en salle blanche. Un RAID 5 de quatre disques dont un survivant a des secteurs défectueux revient donc à 580 €. Deux disques en panne mécanique, ou volume recréé : sur devis, après un diagnostic gratuit. Détail dans prix d'une récupération NAS et RAID.
1. Dégradé, c'est une alerte, pas une panne. Le temps joue contre vous, mais vous avez encore la main.
2. Sauvegarder, vérifier, puis seulement reconstruire. Cet ordre n'est pas négociable.
3. Le SMART des survivants décide : compteurs à zéro → rebuild raisonnable ; compteurs qui bougent → imagerie d'abord.
4. Ne jetez jamais le disque sorti de la grappe. C'est régulièrement lui qui sauve le dossier.
5. Méfiez-vous des mots : initialize n'est pas rebuild, effacer une config foreign n'est pas l'importer, « réparer » n'est pas toujours réparer.
6. Au premier doute, rebuild qui échoue, deuxième disque qui faiblit, volume qui ne monte plus, arrêtez. Une grappe figée se récupère bien mieux qu'une grappe « travaillée ».
Récupération sur RAID 0, 1, 5, 6, 10, 50, JBOD, NAS Synology / QNAP / Asustor, serveurs et baies de stockage - cas logiques et physiques, salle blanche et remplacement de têtes en interne.
Réception des disques par colis suivi depuis toute la France.
Diagnostic sous 24 à 48 h - devis gratuit et sans engagement.
La réponse en 30 secondes
Un RAID 5 dégradé, c'est un disque manquant et zéro tolérance restante : les données sont encore là, mais le prochain incident les rend inaccessibles. Dans l'ordre, et sans en sauter :
1. Ne redémarrez pas, ne retirez aucun disque.
2. Sauvegardez maintenant, tant que le volume monte encore.
3. Relevez le SMART de tous les disques restants, c'est lui qui décide si un rebuild est raisonnable ou suicidaire.
4. Puis seulement : remplacez le disque (CMR, gamme NAS, capacité ≥) et reconstruisez, onduleur branché.
5. Ne jetez jamais le disque sorti de la grappe.
Sauvegarder → vérifier → reconstruire. Cet ordre n'est pas négociable, et c'est précisément lui qui n'est pas respecté dans la majorité des sinistres que nous recevons au laboratoire.
📞 RAID dégradé, rebuild bloqué, deuxième disque tombé ?
BSC DataRecovery - 09 71 32 65 95 : diagnostic sous 24 à 48 h, devis gratuit et sans engagement.
BSC DataRecovery - 09 71 32 65 95 : diagnostic sous 24 à 48 h, devis gratuit et sans engagement.
Trouvez votre situation en 10 secondes
| Votre situation | Ce qu'il faut faire | Section |
|---|---|---|
| Un disque signalé HS, le volume monte encore | Sauvegarder immédiatement, ne rien réparer | Les 30 premières minutes |
| Un disque est « en avertissement » mais pas encore éjecté | Anticiper, ne pas attendre l'éjection | Predictive failure |
| Le NAS ou le contrôleur a déjà démarré un rebuild tout seul (hot spare) | Ne pas l'interrompre à l'aveugle, surveiller | Rebuild automatique |
| Le rebuild est en cours et vous avez un doute | Ne pas couper le courant, lire les signaux | Surveiller / annuler |
| Le rebuild a échoué (bloqué à x %) | Arrêter, ne pas relancer en boucle | Quand le rebuild échoue |
| Deux disques sont tombés, le volume ne monte plus | Éteindre, ne plus rien tenter | Deuxième disque tombé |
| Vous avez cliqué « Initialize » au lieu de « Rebuild » | Conserver le disque retiré : il sauve le dossier | L'erreur n°2 |
| Le NAS est mort mais les disques semblent bons | Les données sont sur les disques, pas dans le boîtier | Cas NAS |
| Ce n'est pas un RAID 5 (RAID 1, RAID 6, RAID 10, SHR) | Même conduite, marge de sécurité différente | RAID dégradé sur un autre niveau |
| Vous voulez savoir combien ça coûte | 190 € de reconstruction, plus le prix des disques abîmés | Prix et délais |
Sommaire
• Les 30 premières minutes : la checklist d'urgence
• Qu'est-ce qu'un RAID 5 « dégradé », exactement ?
• RAID dégradé sur un autre niveau : RAID 1, RAID 6, RAID 10, SHR
• Décoder ce qu'affiche votre système : le lexique des états
• Vérifier l'état réel de la grappe, interface par interface
• Le relevé SMART : l'information qui décide de tout
• Un disque éjecté n'est pas toujours un disque mort
• Le disque « en avertissement » : agir avant l'éjection
• Faut-il éteindre, ou laisser tourner ?
• Pourquoi la reconstruction (rebuild) est le moment le plus dangereux
• Les 7 erreurs qui transforment un incident en sinistre
• La bonne procédure, étape par étape
• Un rebuild automatique s'est lancé tout seul : que faire ?
• Peut-on mettre en pause ou annuler un rebuild en cours ?
• Cas particulier : RAID 5 sur NAS (Synology, QNAP…)
• Cas particulier : RAID 5 après une coupure de courant
• Cas particulier : Intel RST, Windows et Storage Spaces
• Quand le rebuild échoue
• Si un deuxième disque est déjà tombé
• Ce qu'il faut nous apporter (et pourquoi)
• Après : ne pas revivre la même journée
• RAID 5, RAID 6 ou RAID 10 : que reconstruire ensuite ?
• Combien coûte une récupération RAID, et en combien de temps ?
• FAQ - RAID 5 dégradé
• Les 30 premières minutes : la checklist d'urgence
• Qu'est-ce qu'un RAID 5 « dégradé », exactement ?
• RAID dégradé sur un autre niveau : RAID 1, RAID 6, RAID 10, SHR
• Décoder ce qu'affiche votre système : le lexique des états
• Vérifier l'état réel de la grappe, interface par interface
• Le relevé SMART : l'information qui décide de tout
• Un disque éjecté n'est pas toujours un disque mort
• Le disque « en avertissement » : agir avant l'éjection
• Faut-il éteindre, ou laisser tourner ?
• Pourquoi la reconstruction (rebuild) est le moment le plus dangereux
• Les 7 erreurs qui transforment un incident en sinistre
• La bonne procédure, étape par étape
• Un rebuild automatique s'est lancé tout seul : que faire ?
• Peut-on mettre en pause ou annuler un rebuild en cours ?
• Cas particulier : RAID 5 sur NAS (Synology, QNAP…)
• Cas particulier : RAID 5 après une coupure de courant
• Cas particulier : Intel RST, Windows et Storage Spaces
• Quand le rebuild échoue
• Si un deuxième disque est déjà tombé
• Ce qu'il faut nous apporter (et pourquoi)
• Après : ne pas revivre la même journée
• RAID 5, RAID 6 ou RAID 10 : que reconstruire ensuite ?
• Combien coûte une récupération RAID, et en combien de temps ?
• FAQ - RAID 5 dégradé
Le contexte : pourquoi cet état est si mal géré
Une LED orange sur la baie, un mail « Volume dégradé » du NAS, un contrôleur qui annonce Degraded au démarrage du serveur : un disque de votre RAID 5 vient d'être éjecté de la grappe. Le partage réseau répond encore, les utilisateurs travaillent, tout semble normal. C'est précisément ce qui rend cette situation dangereuse.
Un RAID 5 dégradé, ce n'est pas une panne : c'est la dernière alerte avant la panne. Vos données sont toujours là, mais la sécurité qui les protégeait a été consommée. À partir de cet instant, le moindre incident sur un des disques restants, un secteur illisible, un disque qui prend deux secondes de trop pour répondre, une coupure pendant la reconstruction, fait basculer l'ensemble du volume dans l'inaccessible.
Et c'est là que la plupart des sinistres que nous recevons au laboratoire se jouent. Dans la grande majorité des cas, le RAID n'a pas été perdu par la panne du premier disque, mais par ce qui a été fait ensuite : un rebuild lancé sans sauvegarde, un « initialize » cliqué à la place d'un « rebuild », un disque remplacé par un modèle inadapté, un volume recréé « pour réparer ». La fenêtre pour bien faire est ouverte, mais elle est étroite.
Ce guide vous donne l'ordre exact des opérations: ce qu'il faut faire dans l'heure, ce qu'il ne faut surtout pas toucher, comment décider si votre grappe peut supporter un rebuild, et quoi faire si elle ne le supporte pas.
En bref
Dégradé = un disque manquant, zéro tolérance restante. Les données sont accessibles, mais un deuxième incident les rend inaccessibles Sauvegardez d'abord, reconstruisez ensuite. Jamais l'inverse. Tant que le volume monte encore, chaque heure passée à copier est une heure gagnée Le rebuild est le moment le plus dangereux de la vie d'un RAID: il lit l'intégralité de tous les disques survivants, d'un seul trait, pendant des heures - exactement le stress qui achève un disque déjà fatigué Vérifiez le SMART des disques restants avant de reconstruire. Un survivant avec des secteurs en attente = rebuild à haut risque Ne jetez JAMAIS le disque sorti de la grappe. En cas de manipulation malheureuse, c'est souvent lui qui porte la seule copie exploitable des données Ne remplacez jamais un disque de NAS/RAID par un disque SMR : il fera échouer le rebuild et sera éjecté à son tour Un deuxième disque est déjà tombé ? Arrêtez tout, n'insistez pas sur le rebuild : chaque tentative supplémentaire réduit les chances de récupérationLes 30 premières minutes : la checklist d'urgence
Si vous n'avez le temps de lire qu'une seule section, c'est celle-ci. Dans l'ordre, sans en sauter :
1. Ne redémarrez pas le serveur ou le NAS.
Un redémarrage peut déclencher une resynchronisation automatique, ou faire tomber un deuxième disque au moment du démarrage des moteurs (le pic de courant du spin-up est le moment le plus dur pour un disque usé).
2. Ne retirez aucun disque de la baie, même celui qui est annoncé défaillant, tant que vous n'avez pas terminé les étapes 3 et 4.
3. Photographiez la façade et l'arrière de la baie, en identifiant clairement l'ordre des emplacements. Notez le numéro de série de chaque disque et sa position. Cette photo vaut de l'or si le contrôleur perd sa configuration.
4. Copiez immédiatement les données critiques sur un support externe. Le volume est encore monté: profitez-en. Priorisez, comptabilité, dossiers clients, projets en cours, plutôt que de lancer une copie intégrale qui n'aboutira peut-être pas.
5. Relevez le SMART de tous les disques restants (voir plus bas). C'est ce relevé qui déterminera si vous pouvez tenter un rebuild ou non.
6. Réduisez la charge du volume : suspendez les sauvegardes automatiques, les indexations, les antivirus programmés, les tâches de synchronisation cloud, les machines virtuelles non essentielles. Chaque lecture inutile est un risque supplémentaire.
7. Ne lancez aucun outil de « réparation », ni
chkdsk, ni fsck, ni la fonction « réparer le volume » du NAS - tant que la sauvegarde n'est pas terminée. Sur un volume dégradé, ces outils écrivent, et chkdsk peut aggraver définitivement la situation.
⚠️ Si le volume ne monte plus du tout, ou si un deuxième disque est déjà signalé défaillant
N'appliquez pas cette checklist. Éteignez proprement et passez directement à la section « Si un deuxième disque est déjà tombé ».
N'appliquez pas cette checklist. Éteignez proprement et passez directement à la section « Si un deuxième disque est déjà tombé ».
Qu'est-ce qu'un RAID 5 « dégradé », exactement ?
Un RAID 5 en mode dégradé (degraded), c'est l'état dans lequel un des disques membres a été retiré de la grappe, parce qu'il est tombé en panne, ou parce que le contrôleur a décidé qu'il ne répondait plus assez vite, et où le volume continue à fonctionner grâce à la parité.
Concrètement, le RAID 5 répartit les données sur au moins trois disques, et calcule pour chaque bande (stripe) un bloc de parité stocké en alternance sur les différents membres. Ce bloc est le résultat d'un XOR des blocs de données de la même rangée : il permet de recalculer mathématiquement n'importe quel bloc manquant à partir de tous les autres. C'est ce calcul qui, en mode dégradé, reconstitue à la volée les données du disque absent à chaque lecture.
Bonne nouvelle : rien n'est perdu, le serveur tourne, les utilisateurs ne voient (presque) rien.
Mauvaise nouvelle : chaque lecture coûte désormais un calcul de parité, les performances s'effondrent, en particulier en écriture, et surtout, votre unique disque de tolérance a été consommé.
| État du RAID 5 | Disques en panne | Données | Sécurité restante |
|---|---|---|---|
| Sain (optimal) | 0 | OK | tolère 1 panne |
| Dégradé (degraded) | 1 | OK, accessibles | aucune |
| En reconstruction (rebuilding) | 1 (remplacé) | OK, très lentes | aucune - phase la plus risquée |
| En échec (failed / offline) | 2 ou plus | inaccessibles | perte du volume → récupération en laboratoire |
RAID dégradé sur un autre niveau : RAID 1, RAID 6, RAID 10, SHR
Le mot « dégradé » n'est pas réservé au RAID 5. Sur tout niveau redondant, il désigne le même état : un membre manque, le volume fonctionne encore, la marge de sécurité a été entamée. Ce qui change d'un niveau à l'autre, c'est ce qui reste de cette marge, donc l'urgence réelle.
| Niveau | « Dégradé » veut dire | Tolérance restante | Ce qui change dans la conduite |
|---|---|---|---|
| RAID 1 (miroir, 2 disques) | Un des deux disques est sorti, le volume tourne sur un seul | aucune | Même urgence qu'un RAID 5. Le disque restant est la seule copie : copier d'abord, reconstruire ensuite. Voir RAID 1 en panne : deux disques tombés, miroir désynchronisé |
| RAID 5 | Un membre manque | aucune | Ce guide |
| RAID 6 | Un membre manque (dégradé simple) ou deux (dégradé critique) | 1 panne, puis aucune | Un seul disque tombé : vous avez encore un filet, c'est le moment idéal pour sauvegarder puis reconstruire au calme. Deux disques tombés : vous êtes exactement dans la situation d'un RAID 5 dégradé |
| RAID 10 | Un disque manque dans un des miroirs | 1 panne par miroir intact, aucune sur le miroir touché | La reconstruction ne lit qu'un seul disque (le jumeau), elle est courte et peu risquée. Mais si le jumeau tombe, tout le volume est perdu |
| SHR / SHR-2 (Synology) | Un membre manque dans une ou plusieurs des grappes empilées | Comme RAID 5 (SHR) ou RAID 6 (SHR-2) | Même conduite que le niveau équivalent. Particularité : la géométrie est propre à Synology et les logiciels génériques ne la reconstruisent pas, voir Drobo, Storage Spaces, Synology SHR : les RAID que les logiciels ne lisent pas |
| RAID 0 | N'existe pas : sans redondance, un disque en moins = volume en échec | s.o. | Ce n'est pas un RAID dégradé mais un RAID en panne : RAID 0 en panne ou disque HS : récupérer les données |
Décoder ce qu'affiche votre système : le lexique des états
Les interfaces parlent rarement français, et rarement la même langue entre elles. Un même état porte quatre noms selon le constructeur, et certains messages qui font peur sont bénins, quand d'autres, anodins, annoncent une catastrophe. Voici la traduction.
| Ce que vous lisez | Où | Ce que ça veut dire | Gravité |
|---|---|---|---|
| Degraded / Dégradé / Critical | Partout | Un membre manque, données accessibles, plus aucune tolérance | 🟠 Urgent, pas critique |
| Volume dégradé / Attention | Synology DSM, QNAP | Idem | 🟠 |
| Rebuilding / Réparation en cours / Resyncing | Partout | Reconstruction en cours - phase la plus fragile | 🟠 Ne rien couper |
| Failed / Offline / Planté / Inactive | Partout, mdadm | Deux membres ou plus manquent : volume inaccessible | 🔴 Éteindre |
| Foreign / Foreign configuration | Dell PERC, LSI, Broadcom | Le contrôleur voit sur un disque une config RAID qu'il ne reconnaît pas comme la sienne | 🔴 Ne jamais « effacer » à l'aveugle |
| Predictive failure / Warning / SMART Warning | PERC, HPE, DSM | Le disque fonctionne encore mais annonce sa fin | 🟠 Voir ci-dessous |
| Not Redundant | QNAP, Intel RST | Traduction marketing de « dégradé » | 🟠 |
| Unassigned / Ready / Hot spare | Contrôleurs matériels | Disque présent mais hors grappe (rechange, ou sorti) | ⚪ Informatif |
| Initializing / Background init | Contrôleurs matériels | ⚠️ Ce n'est pas un rebuild : la parité est réécrite | 🔴 Voir l'erreur n°2 |
[UUU_] dans /proc/mdstat |
Linux / NAS | 4 membres, le 4e absent | 🟠 |
[U_U_] ou [_UU_] |
Linux / NAS | Deux membres absents | 🔴 |
| Crashed / System Partition Failed | Synology | La partition système est touchée, pas forcément les données | 🟠 |
Vérifier l'état réel de la grappe, interface par interface
Avant toute décision, il faut savoir exactement ce que voit le système : quel disque manque, depuis quand, et dans quel état sont les autres. Le voyant de façade ne suffit pas.
Sur un NAS Synology (DSM)
Dans DSM → Gestionnaire de stockage, l'onglet Groupe de stockage affiche l'état (
Dégradé, Réparation en cours, Planté) et l'onglet HDD/SSD le détail par disque, avec l'état SMART et le nombre de secteurs réalloués. Notez le numéro de série du disque signalé.DSM propose un bouton « Réparer » dès qu'un disque de remplacement est inséré. Ce bouton lance un vrai rebuild md, il est légitime,mais ne le cliquez pas avant d'avoir sauvegardé et relevé le SMART des autres disques. C'est un aller sans retour : une fois lancé, la lecture intégrale des survivants commence.
En SSH, la source de vérité reste la couche Linux sous-jacente :
cat /proc/mdstat
sudo mdadm --detail /dev/md2
Une ligne du type sudo mdadm --detail /dev/md2
[UUU_] indique quatre membres dont le quatrième est absent. mdadm --detail donne le rôle de chaque disque, l'état (active sync, faulty, removed, spare) et surtout l'Update Time - précieux pour savoir si un disque est sorti de la grappe il y a une heure ou il y a huit mois. Cet écart est l'un des facteurs qui déterminent le taux de récupération.Sur un NAS QNAP
Storage & Snapshots → Storage/Snapshots, puis le détail du pool. Les journaux (System Logs) permettent de retrouver le moment exact où le disque a été éjecté et le message associé (erreur de lecture, timeout, disque retiré à chaud). C'est une information de diagnostic à part entière : un disque éjecté sur timeout et un disque éjecté sur erreur média n'appellent pas la même conduite.
Sur un contrôleur matériel (Dell PERC, HPE Smart Array, LSI/Broadcom, Adaptec)
Passez par l'utilitaire du constructeur plutôt que par le BIOS de la carte :
perccli / storcli (LSI et dérivés), ssacli (HPE), arcconf (Adaptec). Vous obtiendrez l'état de la grappe (Degraded), l'état de chaque disque physique (Failed, Foreign, Rebuild, Online), et le compteur d'erreurs médias par disque. Si les membres sont des disques SAS, n'essayez pas de les lire sur un PC de bureau : un disque SAS ne se branche pas sur un port SATA.
storcli /c0 show all
perccli /c0/vall show
ssacli ctrl all show config detail
arcconf GETCONFIG 1
Le statut Foreign mérite une mise en garde à part. Il signifie que le contrôleur voit sur un disque une configuration RAID qu'il ne considère pas comme la sienne - après un changement de carte, un déplacement de disques, ou une réinsertion. Les utilitaires proposent alors deux actions dont les noms se ressemblent et dont les effets sont opposés: importer la configuration étrangère (non destructif, souvent la bonne action) et effacer/clear la configuration étrangère (destructif : les métadonnées du disque sont écrasées). Ne « nettoyez » jamais une configuration foreign à l'aveugle.perccli /c0/vall show
ssacli ctrl all show config detail
arcconf GETCONFIG 1
Sur un serveur virtualisé (VMware ESXi, Proxmox, Hyper-V)
L'hyperviseur masque souvent l'état du RAID matériel : le datastore paraît sain alors que la grappe est dégradée depuis des semaines. Interrogez le contrôleur directement (agent constructeur, iDRAC/iLO, ou
storcli depuis le shell ESXi) et non l'interface de virtualisation. Sur un datastore VMFS porté par une grappe dégradée, la priorité est la même : sortir les machines virtuelles critiques par sauvegarde avant toute reconstruction. Si le datastore est déjà inaccessible, voir VM, datastore VMware, Hyper-V ou Proxmox en panne : récupérer les données.Le relevé SMART : l'information qui décide de tout
C'est ce relevé qui va vous dire si la grappe peut supporter une reconstruction. Sur chaque disque restant :
smartctl -a /dev/sda
smartctl -a -d sat+megaraid,0 /dev/sda # derrière un contrôleur LSI/PERC
Les attributs qui comptent :smartctl -a -d sat+megaraid,0 /dev/sda # derrière un contrôleur LSI/PERC
| Attribut | Nom | Ce que ça signifie sur un membre de RAID |
|---|---|---|
05 |
Reallocated Sector Count | Des secteurs ont déjà été remplacés. Au-delà de quelques unités, ou s'il augmente, c'est un signal fort. |
C5 |
Current Pending Sector | Le plus critique. Des secteurs sont illisibles et en attente. Chacun est une bombe à retardement pour un rebuild. |
C6 |
Offline Uncorrectable | Secteurs définitivement illisibles. Un rebuild butera dessus. |
C7 |
UDMA CRC Error Count | Erreurs de transmission : câble SATA, fond de panier, alimentation. Souvent un faux problème de disque. |
BB / 01 |
Reported Uncorrect / Raw Read Error Rate | Erreurs de lecture non corrigées. À croiser avec les autres. |
09 |
Power On Hours | L'âge réel. Trois disques de 55 000 heures achetés ensemble = une grappe en fin de vie. |
C1 |
Load/Unload Cycle Count | Sur un NAS mal paramétré (mise en veille agressive des têtes), il grimpe très vite et use prématurément les disques. |
La règle de décision, en trois lignes
| Relevé sur les survivants | Décision |
|---|---|
05, C5, C6 tous à zéro, pas d'erreurs CRC |
Rebuild raisonnable - après sauvegarde |
Un seul C5 ou C6 non nul, ou en progression |
Ne pas reconstruire → imagerie des disques d'abord, reconstruction ensuite sur les copies |
C7 qui grimpe, compteurs de secteurs à zéro |
Chercher du côté du câblage / fond de panier / alimentation, pas du disque |
| Disques > 45 000-50 000 h et gros volume | Même prudence : le rebuild lit tout, sur des disques en fin de vie |
C5 ou C6 non nuls, un rebuild classique a de fortes chances d'échouer et de faire tomber ce disque. Dans ce cas, la reconstruction n'est pas la bonne opération - l'imagerie préalable des disques l'est.Pour comprendre en détail ces valeurs, voir notre guide complet : SMART disque dur : lire les attributs et anticiper la panne.
Un disque éjecté n'est pas toujours un disque mort
C'est une nuance capitale, et elle change la stratégie. Un contrôleur RAID ne fait pas de diagnostic: il applique une règle brutale,si un disque ne répond pas dans le délai imparti, il est sorti de la grappe. Les causes possibles, par ordre de fréquence :
1. Le disque a réellement une panne mécanique ou électronique.
Cliquetis, disque qui ne démarre plus, carte électronique grillée. C'est le cas « propre » : le disque est mort, la grappe est dégradée, la procédure normale s'applique. Voir disque dur qui fait du bruit, disque dur qui ne s'allume plus et disque dur qui démarre puis s'arrête. Un bruit inhabituel n'est pas toujours une panne : disque dur qui fait du bruit, normal ou panne ?
2. Le disque a mis trop de temps à récupérer une erreur de lecture (problème de TLER).
Un disque de bureau, face à un secteur difficile, peut passer 30 secondes à deux minutes à réessayer avant d'abandonner. Un contrôleur RAID, lui, attend en général 7 à 8 secondes. Passé ce délai, il éjecte le disque, qui est pourtant en parfait état de marche. C'est la fonction TLER (Western Digital), ERC (Seagate) ou CCTL (autres) qui limite ce temps de retry sur les disques conçus pour le NAS : elle indique au disque d'abandonner vite et de laisser le RAID recalculer le bloc par parité. Un disque de bureau dans un RAID finit statistiquement toujours par être éjecté. Le même mécanisme de retry explique, hors RAID, un disque détecté mais très lent, copie bloquée.
3. Le disque est un SMR.
Les disques à enregistrement en tuiles (Shingled Magnetic Recording) réorganisent leurs pistes en arrière-plan. Sous écritures soutenues, exactement le profil d'un rebuild, leur cache sature, le débit s'effondre à quelques Mo/s, le contrôleur dépasse son timeout et éjecte le disque. C'est une cause majeure et totalement silencieuse de rebuilds ratés. Le sujet mérite à lui seul un article : CMR ou SMR : quel disque choisir pour un NAS ou un RAID.
4. Le problème n'est pas le disque du tout.
Câble SATA/SAS défectueux, connecteur de fond de panier oxydé, alimentation sous-dimensionnée qui fléchit quand tous les disques sollicitent en même temps, contrôleur en surchauffe. L'attribut
C7 (erreurs CRC) est le meilleur indicateur - s'il grimpe alors que les compteurs de secteurs restent à zéro, cherchez du côté du câblage. Nous détaillons ce mécanisme dans erreur CRC sur un disque dur.Pourquoi c'est important pour vous ? Parce que dans les cas 2, 3 et 4, le disque éjecté est intact et contient des données valides. C'est une ressource précieuse : en cas de manipulation malheureuse par la suite, c'est lui qui permettra la récupération. Raison de plus pour ne jamais le jeter, l'effacer, ou le réutiliser ailleurs.
Le test qui distingue les quatre cas en cinq minutes
Branchez le disque éjecté seul, sur un autre poste, en lecture seule (jamais d'écriture, jamais de formatage, jamais de « réparation » proposée par Windows), et relevez son SMART. S'il se détecte instantanément et affiche des compteurs propres, vous êtes dans les cas 2, 3 ou 4 : le problème est ailleurs dans la chaîne. S'il claque, tourne sans se détecter ou affiche des centaines de secteurs en attente, c'est le cas 1.
Branchez le disque éjecté seul, sur un autre poste, en lecture seule (jamais d'écriture, jamais de formatage, jamais de « réparation » proposée par Windows), et relevez son SMART. S'il se détecte instantanément et affiche des compteurs propres, vous êtes dans les cas 2, 3 ou 4 : le problème est ailleurs dans la chaîne. S'il claque, tourne sans se détecter ou affiche des centaines de secteurs en attente, c'est le cas 1.
Le disque « en avertissement » : agir avant l'éjection
Une situation intermédiaire, très fréquente, et curieusement peu traitée : le disque n'est pas encore tombé, mais le système l'a mis en garde. Selon l'interface, cela s'affiche en Predictive Failure, Warning, SMART Status: Failing, « État anormal » ou « Avertissement » dans DSM.
Vous n'êtes alors pas encore en RAID dégradé, vous êtes à quelques heures ou quelques semaines de l'être. C'est la meilleure position possible : vous avez encore votre tolérance de panne intacte, et le temps de bien faire.
Ce qu'il faut faire, dans cet ordre :
1. Sauvegardez. Vous avez la redondance de votre côté et un volume rapide : c'est le moment idéal, pas quand la grappe sera dégradée.
2. Vérifiez le SMART de tous les membres, pas seulement du disque signalé. Une alerte sur un membre d'un lot acheté ensemble annonce souvent les suivantes.
3. Commandez le disque de remplacement (voir les critères plus bas) et attendez-le sans rien faire.
4. Remplacez le disque de façon planifiée, en période creuse, onduleur branché - un rebuild lancé sur une grappe encore complète et à froid est infiniment plus sûr qu'un rebuild d'urgence.
Ce qu'il ne faut surtout pas faire : retirer le disque signalé « pour voir », ou le remplacer dans la précipitation sans sauvegarde préalable. Un disque en predictive failure participe toujours à la redondance : tant qu'il est là, la grappe est complète.
Faut-il éteindre, ou laisser tourner ?
La question revient systématiquement, et la réponse dépend d'une seule chose : avez-vous une sauvegarde à jour ?
| Situation | Décision |
|---|---|
| Volume dégradé, données critiques non sauvegardées | Laisser tourner et copier immédiatement, à charge réduite. Un disque en fonctionnement continu est moins sollicité qu'un disque qu'on rallume. |
| Volume dégradé, sauvegarde complète et vérifiée | Vous pouvez éteindre proprement et intervenir sereinement. |
| Bruits anormaux (cliquetis, grattement, bip) sur un disque | Éteindre immédiatement. Chaque minute supplémentaire dégrade les surfaces. |
| Volume déjà inaccessible / deuxième disque tombé | Éteindre. Toute tentative supplémentaire réduit les chances de récupération. |
Pourquoi la reconstruction (rebuild) est le moment le plus dangereux
Quand vous insérez un disque de remplacement, le contrôleur lance la reconstruction : il lit l'intégralité des disques survivants, du premier au dernier secteur, pour recalculer bloc par bloc le contenu du nouveau disque. Selon la capacité et la charge, cela dure de quelques heures à plusieurs jours.
Le problème tient en une phrase : c'est la seule opération de la vie d'un RAID qui lit tous les disques à 100 %, en continu, pendant des heures. Et elle survient précisément au moment où la grappe n'a plus aucune marge.
Trois facteurs aggravants se cumulent.
Les disques ont le même âge et la même usure. Ils ont été achetés ensemble, souvent dans le même lot de production, et ont subi la même charge, la même température, les mêmes cycles. Le premier disque qui tombe est très souvent l'annonce du deuxième. Statistiquement, les défaillances d'une grappe ne sont pas des événements indépendants, c'est toute la faiblesse du modèle.
L'URE (Unrecoverable Read Error) devient probable sur les gros volumes. Les fabricants annoncent, pour un disque grand public, un taux d'erreur de lecture irrécupérable de l'ordre de 1 pour 1014 bits lus, soit environ 12,5 To lus. Or reconstruire un RAID 5 de quatre disques de 8 To impose de lire 24 To - deux fois le seuil annoncé. Ce chiffre est une valeur de spécification très conservatrice, et en pratique les disques font souvent mieux; mais le risque n'est pas théorique: un seul secteur illisible sur un survivant suffit à faire échouer le rebuild d'un RAID 5, faute de deuxième source de redondance. Les disques NAS et entreprise (1015, soit ~125 To) sont dix fois plus tolérants - une des vraies raisons de les préférer.
La reconstruction est longue et cumule les risques. Ordres de grandeur observés, à titre indicatif :
| Capacité par disque | Grappe au repos | Grappe en production |
|---|---|---|
| 2 To | 4 à 8 h | 12 à 24 h |
| 4 To | 8 à 14 h | 1 à 2 jours |
| 8 To | 16 à 30 h | 2 à 4 jours |
| 12 To et plus | 24 à 48 h | 3 à 7 jours |
C'est exactement pour cette raison que les gros volumes se construisent aujourd'hui en RAID 6 (double parité, tolère deux pannes simultanées) ou en RAID 10. Mais si vous êtes déjà en RAID 5 dégradé, la priorité n'est pas de changer d'architecture : c'est de sécuriser l'existant. On change d'architecture après, à froid, une fois les données à l'abri - voir RAID 5, RAID 6 ou RAID 10.
Les 7 erreurs qui transforment un incident en sinistre
1. Lancer le rebuild avant d'avoir copié les données
La sauvegarde passe avant la reconstruction, toujours. Si la copie n'est plus possible parce que le système refuse ou se bloque, c'est que vous êtes déjà au-delà du dégradé simple : n'aggravez surtout pas la situation en forçant une reconstruction par-dessus.
2. Cliquer « Initialize » (ou « Create ») au lieu de « Rebuild »
C'est l'erreur la plus destructrice, et de loin la plus fréquente. Les interfaces de contrôleurs proposent, dans le même menu, des entrées qui se ressemblent : add array, create array, assemble, initialize, rebuild, restore, reconstruct. Sous stress, dans une situation qu'on rencontre une fois tous les cinq ans, l'utilisateur choisit la mauvaise.
La différence est pourtant radicale :
Un rebuild correct recalcule le contenu du membre manquant par parité et n'écrit que sur le disque neuf. Les disques survivants ne sont pas modifiés Une initialisation est la synchronisation initiale d'une grappe neuve : elle recalcule et réécrit les blocs de parité sur tous les membres, à partir des données présentes, donc, avec un disque neuf en place, à partir de données parasitesCe que ça donne concrètement : sur un RAID 5 de trois disques, environ un tiers des blocs de la grappe deviennent faux (10 % environ sur une grappe de dix disques). Cela semble « peu », mais avec une taille de bloc de 64 Ko, une période complète ne représente que quelques centaines de kilo-octets, autrement dit, presque tous les fichiers réels (photos, documents, archives, bases) sont touchés au moins une fois et deviennent illisibles. La grappe s'affiche « saine » et le volume est vide ou corrompu. Un RAID qui revient « propre mais vide » après une manipulation est, neuf fois sur dix, une initialisation accidentelle.
Le point qui sauve les cas : après une initialisation, la parité a été « réalignée » sur des données fausses. Reconstituer la grappe avec les seuls disques restants redonnerait exactement les mêmes données fausses, c'est démontrable, et c'est pour cela qu'aucun logiciel ne peut y remédier. La seule copie exploitable des données d'origine est sur le disque qui a été retiré. D'où la règle absolue qui suit.
3. Jeter, effacer ou réutiliser le disque sorti de la grappe
Gardez-le. Étiquetez-le. Ne l'effacez pas, ne le testez pas dans un autre PC avec un utilitaire qui écrit, ne le rendez pas au SAV avant que vos données soient récupérées et vérifiées. Dans un dossier de récupération RAID, le disque défaillant retiré est souvent la pièce la plus importante du puzzle, nous en demandons systématiquement la restitution, y compris quand il ne démarre plus.
4. Réinsérer l'ancien disque « pour voir »
Réintroduire dans la baie un disque sorti depuis plusieurs jours ou plusieurs semaines crée un conflit de métadonnées : le contrôleur voit deux versions divergentes de la configuration. Selon les cas, il peut marquer la grappe comme foreign, monter une combinaison incohérente, ou proposer un rebuild qui écrasera la dernière copie saine. Le contenu de ce disque est périmé : les fichiers créés depuis sa sortie n'y ont jamais été écrits.
C'est le même raisonnement qui nous interdit, en laboratoire, de rendre les disques d'origine à leur contrôleur : l'assemblage se fait virtuellement, sur des copies, jamais sur le matériel qui a créé le conflit.
5. Forcer un rebuild après la chute d'un deuxième disque
C'est l'erreur fatale. À ce stade, la grappe n'a plus de quoi recalculer quoi que ce soit, et chaque tentative fait tourner des disques déjà mourants pendant des heures, en lecture intensive, sur des zones précisément défectueuses. Un disque qui aurait pu être imagé à 99,9 % en laboratoire peut devenir totalement illisible après trois rebuilds forcés.
6. Réorganiser l'ordre des disques, ou recréer le volume
L'ordre des membres fait partie intégrante de la configuration RAID, au même titre que la taille de bloc ou l'algorithme de parité. Le modifier, ou recréer le volume « pour réparer », détruit les métadonnées qui décrivent la géométrie. Sur un NAS, « réinitialiser », « supprimer et recréer le groupe de stockage », « réparer le volume » ou un
mdadm --create lancé pour « réassembler » sont des opérations d'écriture, jamais des opérations de réparation de données.7. Remplacer par un disque inadapté
Un disque de bureau sans TLER, un SMR, un modèle de capacité inférieure, ou un disque de récupération d'un autre serveur qui porte encore d'anciennes métadonnées RAID : chacun de ces choix fait échouer une reconstruction, parfois en apparaissant plusieurs heures après son démarrage.
La bonne procédure, étape par étape
1. Documenter avant de toucher.
Photo de la baie, numéros de série, position de chaque disque, capture d'écran de la configuration (niveau RAID, taille de bloc, ordre des membres, système de fichiers). Sur un contrôleur matériel, exportez la configuration si l'utilitaire le permet. Cinq minutes qui peuvent sauver un dossier entier.
2. Sauvegarder - priorité absolue.
Tant que le volume monte, copiez sur un support externe. Par ordre de criticité, pas par ordre alphabétique. Si vous n'avez pas assez d'espace : les données irremplaçables d'abord (ce qui n'existe nulle part ailleurs), le reste ensuite. Une copie qui plante sur certains fichiers vous renseigne aussi : elle indique où sont les zones abîmées.
3. Vérifier la sauvegarde.
Ouvrez réellement une dizaine de fichiers de types différents, dont deux ou trois volumineux. Une copie « terminée sans erreur » n'est pas une preuve, c'est exactement le principe que nous appliquons en laboratoire avant de valider une récupération (voir la liste de fichiers récupérés, à vérifier avant paiement).
4. Relever le SMART de tous les survivants, et décider.
Tous les compteurs
05, C5, C6 à zéro, pas d'erreurs CRC → le rebuild est raisonnable. Un ou plusieurs compteurs non nuls, ou des erreurs qui augmentent → ne lancez pas de rebuild : faites imager les disques d'abord, la reconstruction se fera ensuite sur des copies, sans risque pour les originaux. Disques très âgés (plus de 45 000-50 000 heures) et volume important → même prudence.5. Choisir le bon disque de remplacement.
Même capacité que les autres membres, ou supérieure (le surplus sera perdu). Jamais inférieure, même de quelques Go - deux disques « 4 To » de marques différentes n'ont pas exactement le même nombre de secteurs CMR obligatoire, jamais SMR. Vérifiez la référence complète (ST8000VN004, WD40EFPX…) contre la liste officielle du fabricant, pas le nom commercial. Deux références qui diffèrent de deux lettres peuvent séparer un disque NAS d'un disque d'archivage : ST8000VN004 (IronWolf, CMR) et ST8000DM004 (Barracuda, SMR) Gamme NAS ou entreprise, avec TLER/ERC activable : WD Red Plus / Red Pro, Seagate IronWolf / IronWolf Pro / Exos, Toshiba N300 / MG. Attention : le « WD Red » tout court peut être SMR, le Red Plus ne l'est pas Disque neuf, sorti de son emballage. Un disque de récupération peut porter d'anciennes métadonnées RAID qui perturbent le contrôleur Vérifiez la compatibilité firmware avec votre contrôleur ou votre modèle de NAS (liste de compatibilité constructeur)Pour la fourniture du matériel et le montage, BSC Informatique (atelier de Hyères) sélectionne les disques compatibles NAS et RAID et se charge du remplacement.
6. Insérer le disque et lancer la reconstruction - au bon moment.
Vendredi soir ou pendant une période creuse, jamais en pleine activité. Coupez ce qui peut l'être : sauvegardes planifiées, indexation, antivirus programmé, synchronisation cloud, machines virtuelles non essentielles. Sur un NAS, réglez la priorité de reconstruction pour privilégier la vitesse plutôt que le service, si vous pouvez vous permettre l'indisponibilité.
7. Brancher l'onduleur - vraiment.
Une coupure de courant en plein rebuild sur une grappe sans redondance est un des scénarios les plus destructeurs qui soient. Si vous n'avez pas d'onduleur, ce n'est pas le moment de reconstruire.
8. Surveiller la reconstruction.
Contrôlez la progression et la température des disques (un rebuild fait grimper de 8 à 12 °C ; au-delà de 50 °C, améliorez la ventilation ou pausez). Surveillez le SMART pendant l'opération. Si un autre disque commence à générer des erreurs, arrêtez : mieux vaut une grappe dégradée figée qu'une grappe en échec.
9. Après le rebuild : vérifier, puis corriger la cause.
Une fois la grappe revenue en optimal, lancez un contrôle de cohérence (scrub / data scrubbing), refaites une sauvegarde complète, et posez-vous la vraie question: pourquoi ce disque est-il tombé ? Si les autres membres ont le même âge, planifiez leur remplacement échelonné, ou la migration vers un niveau à double parité.
⚠️ RAID en panne, rebuild échoué, deuxième disque tombé ?
Stoppez tout. Ne tentez plus de reconstruction. Le laboratoire BSC DataRecovery reconstruit les grappes RAID (0, 1, 5, 6, 10, 50, JBOD, SHR) à partir de l'imagerie individuelle de chaque disque.
Obtenir une estimation pour mon RAID → (diagnostic et devis gratuits)
Stoppez tout. Ne tentez plus de reconstruction. Le laboratoire BSC DataRecovery reconstruit les grappes RAID (0, 1, 5, 6, 10, 50, JBOD, SHR) à partir de l'imagerie individuelle de chaque disque.
Obtenir une estimation pour mon RAID → (diagnostic et devis gratuits)
Un rebuild automatique s'est lancé tout seul : que faire ?
Situation courante sur les serveurs correctement configurés : un hot spare (disque de rechange déclaré dans la grappe) a pris la place du membre défaillant, et la reconstruction a démarré sans que personne ne clique. Vous découvrez la chose une heure ou un jour plus tard.
Le réflexe naturel, couper pour reprendre la main, est le mauvais. Un rebuild interrompu brutalement laisse la grappe dans un état intermédiaire ; sur certains contrôleurs, il repart de zéro au redémarrage, ce qui vous fait subir deux fois le stress de lecture. Ce qu'il faut faire :
1. Laissez-le finir, sauf si un autre disque commence à générer des erreurs pendant l'opération. Un rebuild qui progresse normalement est en train de vous rendre votre tolérance de panne.
2. Pendant qu'il tourne, réduisez tout le reste : sauvegardes planifiées, antivirus, indexation, VM non essentielles.
3. Surveillez le SMART des survivants et la température à intervalles réguliers.
4. Ne sauvegardez pas en parallèle sur le volume lui-même si vous pouvez l'éviter: vous doubleriez la charge de lecture au pire moment. Si vos données ne sont nulle part ailleurs, c'est un arbitrage à faire, et dans ce cas la sauvegarde reste prioritaire, à débit réduit.
5. Quand c'est terminé : contrôle de cohérence, sauvegarde complète, puis remplacement du hot spare consommé (une grappe sans rechange déclaré n'a plus de filet automatique).
Le cas qui doit vous alerter : un rebuild automatique qui se relance en boucle, ou qui échoue toujours au même endroit. Là, ce n'est plus un incident, c'est un survivant défaillant - voir Quand le rebuild échoue.
Peut-on mettre en pause ou annuler un rebuild en cours ?
La réponse dépend de ce que vous voulez obtenir.
Mettre en pause : oui, et c'est souvent utile. La plupart des contrôleurs matériels et des NAS permettent d'abaisser la priorité de reconstruction, voire de la suspendre (réglage de
speed_limit sur mdadm, priorité de rebuild sur PERC/HPE, planification horaire sur DSM). Cela sert à faire baisser la température, ou à laisser passer une sauvegarde urgente. Une pause ne détruit rien : la reconstruction reprend où elle en était.Annuler purement et simplement : possible, mais rarement souhaitable. Interrompre un rebuild vous ramène en mode dégradé, avec un disque neuf partiellement écrit qui devra tout recommencer. Les seules bonnes raisons de le faire :
un autre disque commence à générer des erreurs pendant l'opération (compteurs qui bougent, ralentissements brutaux, journal qui se remplit d'erreurs média) : arrêter est alors la bonne décision, une grappe dégradée figée se récupère bien mieux qu'une grappe effondrée vous découvrez en cours de route que vous n'avez aucune sauvegarde et que les compteurs SMART des survivants sont mauvais : mieux vaut geler la situation et faire imager les disques le disque de remplacement se révèle inadapté (SMR, capacité insuffisante) : il vaut mieux arrêter que de laisser le contrôleur l'éjecter en plein rebuildCe qu'il ne faut jamais faire pour « annuler » : couper l'alimentation, retirer un disque à chaud, ou redémarrer brutalement le serveur. Passez toujours par l'interface, et si elle ne répond plus, appelez avant d'improviser.
Cas particulier : RAID 5 sur NAS (Synology, QNAP, Asustor…)
La majorité des grappes dégradées que nous recevons proviennent de NAS de TPE, d'associations ou de particuliers avancés. Quelques spécificités qui changent la donne.
C'est du RAID logiciel Linux. Synology (y compris en SHR, qui superpose plusieurs grappes md pour gérer des disques de tailles différentes), QNAP, Asustor, TerraMaster reposent sur mdadm, souvent complété par LVM, avec un système de fichiers ext4 ou Btrfs. Conséquence pratique : la configuration n'est pas enfermée dans un contrôleur propriétaire, elle est écrite sur les disques eux-mêmes, dans le superbloc md que chaque membre porte en propre. C'est une bonne nouvelle pour la récupération: même sans le NAS d'origine, boîtier mort, alimentation grillée, modèle introuvable, les disques suffisent à reconstituer le volume.
La structure typique déroute les non-initiés : chaque disque contient d'abord de petites partitions montées en RAID 1 (le système du NAS et le swap, identiques sur tous les membres), puis une grande partition qui porte le RAID 5 de données. Voir un « RAID 1 » dans les outils d'analyse ne signifie donc pas que vos données sont en miroir.
Le disque sans superbloc md valide (ou dont l'Update Time est ancien) est le membre sorti de la grappe. C'est souvent la première chose que nous identifions sur un dossier NAS, et c'est aussi lui qui, s'il est réintégré à l'aveugle, ramène des données périmées.
Ce qu'il ne faut jamais faire sur un NAS dégradé :
réinitialiser le NAS (même le « reset doux » qui « ne touche pas aux données » : il peut recréer des partitions système) supprimer puis recréer le groupe de stockage ou le volume lancer un mdadm --create en espérant réassembler, c'est l'équivalent d'une initialisation, cela réécrit les superblocs accepter la proposition « réparer le système de fichiers » avant d'avoir sauvegardé mettre à jour le firmware du NAS pendant que le volume est dégradé retirer les disques de leurs baies sans les numéroter (voir la règle des baies avant d'envoyer les disques)Si le NAS lui-même est en panne (il ne démarre plus, le volume ne monte plus), le sujet est traité marque par marque : NAS Synology en panne, NAS QNAP en panne : volume non monté, voyant rouge, NAS Asustor, TerraMaster, Buffalo, ReadyNAS en panne et, pour les boîtiers à un ou deux disques, WD My Cloud, My Book Live, Seagate Personal Cloud en panne.
Boîtier mort et disques sains ? Avant de brancher un membre sur un PC, lisez NAS mort, disques sains : lire un disque ext4 ou Btrfs sur PC : un membre de RAID 5 pris isolément ne contient qu'une fraction de chaque fichier, et Windows proposera de l'initialiser. Refusez.
Cas particulier : RAID 5 dégradé après une coupure de courant
Une coupure de courant, une microcoupure, un onduleur en fin de batterie : au redémarrage, la grappe est annoncée dégradée, ou un disque a disparu. C'est un scénario à part, parce que la cause n'est pas nécessairement un disque en panne.
Ce qui se passe réellement. Une coupure brutale interrompt les écritures en cours. Le contrôleur (ou mdadm) constate au redémarrage que les compteurs d'événements des membres divergent, et exclut celui qui est « en retard ». Le disque exclu peut être parfaitement sain. Par ailleurs, le spin-up simultané de tous les disques après une coupure est le pic de contrainte électrique le plus élevé du cycle de vie d'une baie : c'est aussi le moment où un disque déjà fatigué ne repart pas.
La conduite à tenir :
1. Ne relancez pas de resynchronisation dans la foulée. Vérifiez d'abord l'état de chaque membre et de l'alimentation.
2. Contrôlez l'alimentation et l'onduleur avant tout le reste. Une alimentation qui fléchit va reproduire l'incident, et cette fois pendant le rebuild.
3. Regardez le
C7 (erreurs CRC) et les journaux : une coupure abîme rarement un plateau, mais elle révèle les faiblesses de câblage et de fond de panier.4. Attention au système de fichiers. Après une coupure, la grappe peut remonter « saine » et le volume être incohérent (journal ext4/Btrfs, NTFS marqué sale). C'est le moment où l'on est tenté de lancer une réparation automatique, c'est exactement ce qu'il ne faut pas faire avant d'avoir sauvegardé.
5. Si le contrôleur a une batterie/condensateur de cache (BBU/CacheVault) déchargée, il désactive le cache en écriture : le volume devient très lent mais fonctionne. C'est une alerte à traiter, pas une panne de disque.
Cas particulier : Intel RST, RAID Windows et Storage Spaces
Les grappes montées sur carte mère ou par le système méritent une mise au point, parce que leurs pièges sont différents.
Intel RST (RAID de chipset). L'utilitaire annonce le volume Degraded ou « Non redondant ». Deux spécificités : le RAID est piloté par le pilote Windows, donc une réinstallation système ou un changement de mode SATA (RAID ↔ AHCI dans le BIOS) suffit à rendre le volume invisible, ce n'est pas une perte de données, c'est un changement de mode à annuler. Et les métadonnées, elles, sont bien sur les disques. Avant toute manipulation dans l'utilitaire Intel: sauvegardez, et n'utilisez jamais l'option de réinitialisation des disques en non-RAID, qui efface les métadonnées. Un volume ou un SSD qui disparaît après une mise à jour du BIOS ou de Windows relève souvent du même mode Intel VMD / RST : SSD NVMe disparu après mise à jour BIOS ou Windows.
RAID logiciel Windows (disques dynamiques / LDM). Les volumes agrégés par bandes avec parité sont visibles dans la Gestion des disques avec la mention « Échec de la redondance ». La reconstruction se fait par « Réactiver le volume » puis « Réparer le volume » - après sauvegarde, comme partout ailleurs. Particularité utile à connaître: sous LDM, une même partition peut appartenir à plusieurs volumes différents, ce qui rend l'analyse plus complexe qu'un mdadm.
Windows Storage Spaces. Ce n'est pas un RAID au sens classique : un pool combine des disques de tailles et de connectiques différentes, et la répartition des données est décrite dans les métadonnées, pas par une règle de calcul régulière. Conséquences pratiques : un espace de stockage en état « Avertissement » ou « Réduit » se répare depuis le panneau Espaces de stockage (après ajout d'un disque), mais aucun outil générique de reconstruction RAID ne peut deviner sa géométrie - la récupération passe obligatoirement par la lecture des métadonnées du pool. C'est faisable en laboratoire, mais cela exclut les logiciels grand public qui « détectent le RAID automatiquement ». Détail dans Drobo, Storage Spaces, Synology SHR : les RAID que les logiciels ne lisent pas.
Dans les trois cas, la règle reste identique : sauvegarder avant de réparer, et ne jamais laisser un assistant recréer un pool ou un volume « pour corriger l'erreur ».
Quand le rebuild échoue
Un rebuild peut s'arrêter en cours de route, se figer, ou repasser la grappe en échec. Le pourcentage auquel il s'arrête est une information de diagnostic à part entière.
| Symptôme | Ce que ça signifie | Conduite à tenir |
|---|---|---|
| Bloqué toujours au même % | Secteur illisible précis sur un survivant | Ne pas relancer → imagerie bas niveau puis reconstruction sur copies |
| Bloqué à un % différent à chaque fois | Disque instable (électronique, tête faible, surchauffe) ou alim/câblage | Arrêter : relancer, c'est l'achever |
| Échoue à 98-99 % | Très courant : métadonnées et zones chaudes du système de fichiers en fin de volume | Même conduite : arrêter, imager |
| Le disque neuf est éjecté pendant le rebuild | SMR ? disque de bureau sans TLER ? câblage ? | Vérifier la référence exacte avant tout |
| Rebuild très lent puis abandon | SMR, cache saturé, ou contrôleur avec cache désactivé (BBU HS) | Diagnostiquer avant de réessayer |
C'est la signature d'un secteur illisible à un endroit précis d'un des disques survivants. Relancer ne changera rien : le contrôleur rebutera au même endroit, en stressant à nouveau tous les disques. C'est le cas typique où l'imagerie bas niveau résout tout: un matériel d'imagerie professionnel lit la zone difficile avec des réglages adaptés, timeouts courts, lecture par blocs, passes multiples, contournement des zones instables, et produit une copie complète sur laquelle la reconstruction se fait sans obstacle.
Dans tous les cas : ne relancez pas en boucle. Deux tentatives infructueuses suffisent à établir que la voie du rebuild est fermée. La suite est un travail sur copies, pas sur originaux.
Le cas est traité symptôme par symptôme dans Rebuild RAID échoué ou bloqué à X % : arrêtez tout.
Si un deuxième disque est déjà tombé
C'est la situation la plus difficile, mais elle est loin d'être désespérée. La grande majorité des RAID 5 à deux disques défaillants que nous traitons repartent avec l'essentiel des données, voire l'intégralité. La condition : que la grappe n'ait pas été « travaillée » entre-temps.
La récupération se fait en deux temps, et jamais sur les disques d'origine en écriture.
1. Imagerie individuelle de chaque disque
Chaque membre, y compris ceux qui semblent morts, y compris celui qui a été retiré en premier, est copié secteur par secteur vers un disque sain, sur un matériel d'imagerie spécialisé. Ce matériel permet ce qu'un PC ne sait pas faire: régler les temporisations, isoler les têtes défaillantes, lire dans un ordre choisi, gérer les zones instables sans épuiser le disque, reprendre une imagerie interrompue. Quand la panne est mécanique (têtes, moteur), l'intervention passe par le remplacement des têtes en salle blanche avant de pouvoir imager quoi que ce soit.
À partir de ce moment, tout le travail se fait sur les copies. Les disques d'origine ne sont plus touchés, c'est ce qui rend l'opération sans risque supplémentaire, et c'est aussi pourquoi il ne faut jamais bricoler avant.
2. Reconstruction virtuelle de la grappe
Reste à retrouver la géométrie exacte du RAID, à partir des images. Ce que nous devons déterminer :
quels disques font réellement partie de la grappe (une baie contient parfois un hot spare, un disque système, ou le disque d'une autre grappe) l'ordre des membres, qui n'est pas nécessairement l'ordre physique dans le châssis la taille de bloc (stripe size) l'algorithme de parité : sur un RAID 5, la position du bloc de parité (gauche/droite) et celle des blocs de données par rapport à lui (synchrone/asynchrone) donnent quatre combinaisons possibles le décalage de départ (start offset), l'espace de service réservé en tête de disque, qui n'est pas forcément un multiple de la taille de bloc le delay éventuel, c'est-à-dire le nombre de groupes consécutifs conservant la même distribution - un paramètre qu'on rencontre notamment sur d'anciens contrôleurs HP/Compaq et AdaptecQuand les métadonnées sont présentes (superbloc md d'un NAS, métadonnées LVM, Btrfs, VMFS, configuration d'un contrôleur connu), la configuration se retrouve directement. Quand elles ont été détruites, initialisation accidentelle, volume recréé, disques mélangés, elle se déduit du contenu même des disques : analyse statistique de la répartition des données pour faire apparaître la périodicité des blocs de parité, recherche des structures du système de fichiers, et validation finale.
La validation, justement, est le point que les logiciels grand public ratent : voir une arborescence s'afficher ne prouve rien. Un petit fichier tient dans un seul bloc et s'ouvrira même avec un ordre de disques erroné. La seule preuve qu'une configuration est correcte, c'est qu'un fichier plus gros qu'une période complète de la grappe s'ouvre parfaitement. C'est le test que nous appliquons systématiquement avant de lancer l'extraction.
Le cas particulier du membre « périmé »
Il mérite d'être connu, car il explique bien des récupérations qui semblent impossibles. Quand un disque est sorti de la grappe longtemps avant le sinistre, parfois des mois, sans que personne ne voie l'alerte, son contenu est figé à cette date: les fichiers créés depuis n'y ont jamais été écrits. L'assembler tel quel produit une arborescence qui s'ouvre… avec des fichiers récents corrompus.
En laboratoire, ce membre est identifié (superbloc absent ou Update Time ancien), puis exclu de l'assemblage : son contenu est recalculé par la redondance à partir des autres membres. Un fichier récent qui s'ouvre correctement après cette manipulation, et pas avant, est la signature du cas.
Ce qui détermine le taux de récupération
L'écart de temps entre les deux défaillances. Plus il est grand, plus le premier disque est périmé, mais c'est un problème traitable (voir ci-dessus) Ce qui a été tenté avant. Une grappe intacte se récupère quasi intégralement. Une grappe qui a subi trois rebuilds forcés et une recréation de volume, beaucoup moins L'état physique des membres. Un disque imagé à 100 % ne pose aucun problème; à 99,9 %, quelques fichiers seront touchés - ceux dont les secteurs manquants tombent dans les zones illisiblesNotre laboratoire traite toutes les configurations : RAID 0, 1, 5, 6, 10, 50, JBOD, SHR, mdadm/LVM, Btrfs, ZFS, Storage Spaces, VMFS et machines virtuelles, sur baie matérielle, contrôleur logiciel ou NAS.
⚠️ RAID en échec, rebuild impossible, deuxième disque tombé ?
Stoppez tout. Ne tentez plus de reconstruction.
BSC DataRecovery - 09 71 32 65 95,obtenir une estimation pour mon RAID → (diagnostic et devis gratuits)
Pannes traitées, méthodes et tarifs : récupération de données sur RAID.
Stoppez tout. Ne tentez plus de reconstruction.
BSC DataRecovery - 09 71 32 65 95,obtenir une estimation pour mon RAID → (diagnostic et devis gratuits)
Pannes traitées, méthodes et tarifs : récupération de données sur RAID.
Ce qu'il faut nous apporter (et pourquoi)
Pour maximiser les chances, un dossier RAID complet comprend :
tous les disques de la grappe, y compris ceux qui sont déclarés morts le disque qui a été retiré en premier - celui qu'on est tenté de jeter, et qui est souvent décisif l'ordre des emplacements (votre photo, ou des étiquettes) le modèle du NAS ou de la carte contrôleur, et si possible le niveau RAID et la taille de bloc l'historique honnête de ce qui a été tenté : rebuild lancé, volume recréé, logiciel de récupération exécuté, réinitialisation… Cette information ne sert pas à juger, elle sert à savoir ce qui a été écrit et où chercher. Un client qui dit « j'ai cliqué sur quelque chose, je ne sais plus quoi » nous fait gagner des heures une liste des fichiers ou dossiers prioritaires, elle permet souvent d'extraire l'essentiel avant même d'avoir terminé le traitement completLe boîtier NAS lui-même n'est en général pas nécessaire, mais il peut aider sur des modèles au partitionnement atypique. Où que vous soyez en France, vous pouvez nous expédier les disques par colis suivi via notre service de récupération de données à distance : suivez la règle des baies pour envoyer les disques d'un NAS ou d'un RAID et nos consignes d'emballage d'un disque dur pour l'expédition, en emballant chaque disque séparément et en numérotant les emplacements.
Certaines activités reviennent souvent dans les dossiers RAID, chacune avec ses urgences : rushes et projets d'un vidéaste sur disque ou RAID en panne, projets d'architecte ou de bureau d'études sur un NAS en panne, base EBP, Sage ou Ciel sur un serveur HS, vidéosurveillance, caisse ou serveur d'un commerce. Dans tous ces cas, la liste des dossiers prioritaires fait gagner des jours.
Après : ne pas revivre la même journée
Une fois la grappe reconstruite ou les données récupérées, quelques décisions évitent la récidive.
Le RAID n'est pas une sauvegarde.
C'est le malentendu le plus coûteux du stockage professionnel. Un RAID protège contre la panne d'un disque, et contre rien d'autre : ni la suppression accidentelle, ni le ransomware, ni le formatage malheureux, ni le dégât des eaux, ni le vol du serveur. Il augmente la disponibilité, pas la sécurité des données. La règle 3-2-1 reste la seule protection réelle : trois copies, sur deux supports différents, dont une hors site. Notre article qu'est-ce qu'une sauvegarde et pourquoi c'est important détaille la mise en pratique, et rappelle pourquoi les clés USB et les SSD sont de mauvais supports de sauvegarde au long cours.
Activez le contrôle de cohérence périodique (data scrubbing sur Synology/QNAP, patrol read / consistency check sur les contrôleurs matériels), une fois par mois ou par trimestre. Son rôle est précisément de découvrir les secteurs illisibles pendant que la redondance est encore disponible pour les corriger - au lieu de les découvrir en plein rebuild, quand il est trop tard. C'est la mesure préventive la plus rentable qui existe sur un RAID 5.
Activez les alertes.
Un très grand nombre de grappes arrivent chez nous avec deux disques tombés à plusieurs mois d'intervalle, parce que personne n'a vu passer la première alerte : notification e-mail non configurée, adresse obsolète, voyant à l'arrière d'un serveur dans un local que personne ne visite. Configurez une notification par e-mail testée pour de bon (envoyez-vous un test, vérifiez qu'il n'atterrit pas en indésirable), et vérifiez visuellement la baie tous les mois.
Ne renouvelez pas tous les disques du même lot.
Si les autres membres approchent des 50 000 heures, remplacez-les de manière échelonnée, de préférence avec des références ou des lots de fabrication différents.
Gardez un disque de rechange sur l'étagère.
Le même modèle, acheté à l'avance. Le jour où un membre tombe, vous n'attendez pas trois jours de livraison en mode dégradé.
RAID 5, RAID 6 ou RAID 10 : que reconstruire ensuite ?
La question se pose une fois les données à l'abri, pas avant. Voici de quoi trancher.
| RAID 5 | RAID 6 | RAID 10 | |
|---|---|---|---|
| Disques minimum | 3 | 4 | 4 |
| Capacité utile (n disques) | n − 1 | n − 2 | n / 2 |
| Pannes tolérées | 1 | 2 | 1 par miroir (2 fatales si même miroir) |
| Survivre à une panne pendant le rebuild | non | oui | le plus souvent |
| Performance en écriture | faible (parité à calculer) | plus faible encore (double parité) | excellente |
| Durée de rebuild | longue, lit tous les membres | longue | courte, ne lit qu'un miroir |
| Recommandé pour | petits volumes, disques ≤ 4 To | volumes importants, disques ≥ 4 To | bases de données, VM, écritures intensives |
Et dans tous les cas, cela mérite d'être répété,aucun de ces niveaux ne remplace une sauvegarde.
Les niveaux non traités dans ce guide ont chacun leur page : RAID 1 en panne et RAID 0 en panne.
Combien coûte une récupération RAID, et en combien de temps ?
Trois facteurs déterminent le devis : le nombre de disques abîmés (pas le nombre de disques de la grappe), leur état physique et la complexité de la reconstruction (métadonnées présentes ou géométrie à déduire). Notre grille NAS / RAID est publique :
| Prestation | Prix |
|---|---|
| Reconstruction du volume : copie individuelle de chaque disque, reconstruction virtuelle du RAID, réparation logique (système de fichiers, partition, configuration du NAS) | 190 € |
| + par disque en panne physique (secteurs défectueux, carte électronique grillée, disque qui lit mal) | 390 € |
| + par disque en panne mécanique (ouverture en salle blanche, échange des têtes) | à partir de 790 € : forfait salle blanche fixé selon le modèle, puis récupération à partir de 490 € due uniquement en cas de succès |
| NAS équipé de SSD (pas de panne mécanique possible) | reconstruction 190 €, secteurs défectueux 390 €, panne physique, suppression ou formatage 690 € |
Grappe saine, configuration du contrôleur perdue (tous les disques lisibles) : 190 € Un disque sorti de la grappe, puis le volume ne monte plus ; un survivant a des secteurs défectueux, le disque sorti est lisible : 190 € + 390 € = 580 € Le disque sorti claque, les trois autres membres sont sains : la parité suffit, on n'ouvre pas le disque qui claque : 190 € Deux disques en panne mécanique, initialisation accidentelle ou volume recréé puis rebuild forcé : sur devis, après le diagnostic gratuit Diagnostic et devis : gratuits et sans engagement. Vous connaissez le montant avant toute intervention Délai de diagnostic : 24 à 48 h selon la complexité Cas logique (grappe saine, configuration perdue, initialisation accidentelle) : traitement généralement rapide, l'essentiel du travail étant l'assemblage virtuel et la validation Cas physique (un ou plusieurs membres à imager, têtes à remplacer) : le délai dépend de l'imagerie, qui est l'étape la plus longue et la moins compressible Extraction prioritaire possible : si vous fournissez une liste de dossiers critiques, ils peuvent souvent être sortis avant la fin du traitement completLe détail est expliqué dans prix d'une récupération de données NAS et RAID : ce qui fait le devis, devis de récupération : fourchette avant diagnostic et comparaison de deux devis et le diagnostic gratuit en laboratoire, étape par étape. La grille tarifaire complète couvre tous les supports. Voir aussi combien coûte une récupération de données et taux de réussite et délais.
FAQ - RAID 5 dégradé
Un RAID 5 dégradé fonctionne-t-il encore normalement ?
Oui, il sert toujours les données, mais avec des performances nettement réduites (chaque lecture du membre absent exige un calcul de parité) et zéro tolérance de panne. Considérez-le comme un sursis : sauvegardez sans attendre.
Combien de temps peut-on rester en mode dégradé ?
Techniquement indéfiniment, et c'est bien le piège, car « ça marche » invite à repousser. Chaque jour supplémentaire augmente la probabilité qu'un deuxième disque lâche, sur des membres de même âge et de même usure. La bonne réponse: sauvegarder immédiatement, puis remplacer rapidement si les autres disques sont sains.
Puis-je continuer à travailler sur le volume pendant qu'il est dégradé ?
Techniquement oui, mais réduisez la charge au strict nécessaire, et faites votre sauvegarde en priorité. Évitez absolument les opérations lourdes : gros imports, réindexation, sauvegardes complètes vers d'autres systèmes, machines virtuelles intensives.
Le rebuild peut-il faire perdre les données ?
Oui, c'est le moment le plus risqué de la vie de la grappe. La lecture intégrale des survivants peut révéler une erreur de lecture irrécupérable (URE) ou achever un disque déjà usé. D'où la règle : sauvegarder avant, vérifier le SMART, et renoncer au rebuild si un survivant est douteux.
Combien de temps dure un rebuild de RAID 5 ?
De quelques heures à plusieurs jours selon la capacité, le nombre de membres, la puissance du contrôleur et la charge du système. Comptez 8 à 14 h pour des disques de 4 To sur une grappe au repos, plusieurs jours pour des disques de 8 à 12 To sur un NAS en production.
Peut-on arrêter ou mettre en pause un rebuild en cours ?
Une pause (ou une baisse de priorité) ne détruit rien et peut être utile pour faire retomber la température ou laisser passer une sauvegarde. Une annulation vous ramène en mode dégradé et oblige à tout recommencer : à ne faire que si un autre disque se met à générer des erreurs, ou si vous découvrez que le disque de remplacement est inadapté. Ne coupez jamais l'alimentation pour arrêter un rebuild.
Un rebuild s'est lancé automatiquement (hot spare) : dois-je l'interrompre ?
Non, sauf si un autre disque commence à générer des erreurs. Laissez-le finir en réduisant tout le reste de la charge, et surveillez SMART et température. Remplacez ensuite le hot spare consommé.
Faut-il un disque exactement identique pour le rebuild ?
Idéalement oui : même capacité, même gamme, même technologie. Une capacité supérieure fonctionne (le surplus est perdu), une capacité inférieure jamais - attention, deux disques annoncés « 4 To » de marques différentes peuvent différer de quelques millions de secteurs. Et dans tous les cas: CMR, jamais SMR.
Puis-je remplacer un disque de NAS par un disque de bureau ordinaire ?
Très déconseillé. Sans TLER/ERC, le disque passe trop de temps à réessayer sur une erreur de lecture et finit par être éjecté par le contrôleur, alors qu'il est en bon état. C'est une cause classique de grappes qui se dégradent à répétition.
Mon rebuild a échoué à 99 %, que faire ?
Ne le relancez pas en boucle. Un blocage reproductible au même pourcentage signale un secteur illisible précis sur un disque survivant. Arrêtez et faites imager les disques en laboratoire : la reconstruction se fera ensuite sur les copies, sans obstacle.
Le NAS me propose de « réparer » le volume : je clique ?
Pas avant d'avoir sauvegardé. « Réparer » recouvre selon les cas une resynchronisation légitime… ou une réécriture destructive. Si vos données ne sont pas ailleurs, cette question n'a qu'une réponse : sauvegarder d'abord.
J'ai lancé une initialisation au lieu d'un rebuild. C'est fini ?
Non - à une condition: ne jetez pas le disque que vous avez retiré. Après une initialisation, la parité a été recalculée sur des données parasites et les seuls disques restants ne suffisent plus à retrouver les données d'origine. Le disque sorti de la grappe porte la copie manquante : avec lui, une récupération complète reste possible dans la plupart des cas.
Mon contrôleur affiche « Foreign configuration » : j'importe ou j'efface ?
Ni l'un ni l'autre dans la précipitation. Importer est en général non destructif et souvent la bonne action après un changement de carte ou un déplacement de disques ; effacer écrase les métadonnées du disque et peut coûter la récupération. Documentez l'état actuel (photos,
storcli/perccli) avant de choisir, et si vos données ne sont pas sauvegardées, faites-vous accompagner.Un disque est en « predictive failure » mais la grappe est encore saine : que faire ?
C'est la meilleure position possible. Sauvegardez pendant que la redondance est intacte, vérifiez le SMART de tous les membres, commandez le bon disque, puis remplacez de façon planifiée en période creuse. Ne retirez pas le disque signalé « pour voir » : tant qu'il est là, la grappe est complète.
Peut-on récupérer un RAID 5 dont la configuration du contrôleur a été perdue ?
Oui, dans la grande majorité des cas. L'ordre des disques, la taille de bloc, l'algorithme de parité et le décalage de départ se retrouvent par analyse des métadonnées présentes sur les disques, ou à défaut par analyse du contenu lui-même, même sans le contrôleur d'origine, et même si celui-ci n'existe plus.
Mon NAS est mort mais les disques sont bons : les données sont-elles perdues ?
Non. Sur les NAS Synology, QNAP, Asustor et assimilés, la configuration RAID est écrite sur les disques (superbloc mdadm), pas dans le boîtier. Les disques seuls suffisent à reconstituer le volume et à en extraire les données.
Deux disques sont tombés en même temps : y a-t-il encore un espoir ?
Oui, très souvent. Les deux défaillances sont rarement simultanées et rarement totales : un membre est fréquemment imageable à 100 %, l'autre à 99 % et quelques poussières. Le facteur décisif n'est pas le nombre de disques tombés, mais ce qui a été tenté après.
Le volume est remonté après une coupure de courant, mais un disque a disparu : il est mort ?
Pas nécessairement. Une coupure interrompt les écritures et fait diverger les compteurs d'événements : le contrôleur exclut le membre « en retard », qui peut être parfaitement sain. Vérifiez l'alimentation et l'onduleur avant de relancer quoi que ce soit - sinon l'incident se reproduira, cette fois pendant le rebuild.
Un logiciel de récupération RAID du commerce peut-il faire l'affaire ?
Sur une grappe dont tous les membres sont physiquement sains et dont il ne manque que la configuration, oui, parfois. Dès qu'un disque a des secteurs illisibles, non : le logiciel va marteler les zones défectueuses pendant des heures et achever le disque, alors qu'un matériel d'imagerie professionnel l'aurait copié proprement. Nous détaillons ces limites dans logiciels gratuits de récupération : ce qu'ils savent faire et ce qu'ils cassent.
Un RAID 1, un RAID 6 ou un SHR « dégradé » : même conduite qu'un RAID 5 ?
Oui pour l'ordre des opérations : sauvegarder, relever le SMART, reconstruire ensuite. Ce qui change, c'est la marge. Un RAID 1 ou un SHR simple dégradé n'a plus aucune tolérance, comme un RAID 5. Un RAID 6 ou un SHR-2 avec un seul disque tombé en garde encore une : c'est le meilleur moment pour agir au calme. Un RAID 0 ne se dégrade pas : un disque en moins, le volume est en échec. Voir le tableau par niveau.
Peut-on reconstruire un RAID 5 dégradé sans perdre les données ?
Oui, c'est le fonctionnement normal : la reconstruction recalcule le disque manquant par parité et n'écrit que sur le disque neuf. Elle ne devient dangereuse que si un survivant a des secteurs illisibles (le rebuild échoue et peut l'achever), si le courant coupe en cours de route, ou si l'on clique « initialiser » à la place de « reconstruire ». D'où les trois conditions : sauvegarde faite, SMART des survivants propre, onduleur branché.
Combien coûte une récupération de RAID 5 ?
190 € pour la reconstruction du volume quand tous les disques sont lisibles, plus 390 € par disque à secteurs défectueux ou à carte électronique grillée, et à partir de 790 € par disque à ouvrir en salle blanche. Un RAID 5 de quatre disques dont un survivant a des secteurs défectueux revient donc à 580 €. Deux disques en panne mécanique, ou volume recréé : sur devis, après un diagnostic gratuit. Détail dans prix d'une récupération NAS et RAID.
Les bons réflexes, avec les bons interlocuteurs
💾 Remplacer les disques et remettre le serveur en service
Une fois les données sécurisées, BSC Informatique (atelier de Hyères) fournit les disques compatibles NAS et RAID (CMR, gamme NAS ou entreprise), remplace les membres fatigués, reconfigure la grappe et remet le serveur ou le NAS en production.
Une fois les données sécurisées, BSC Informatique (atelier de Hyères) fournit les disques compatibles NAS et RAID (CMR, gamme NAS ou entreprise), remplace les membres fatigués, reconfigure la grappe et remet le serveur ou le NAS en production.
🛡️ Mettre en place une sauvegarde qui protège vraiment
Un RAID ne remplace pas une sauvegarde. Pour un poste ou un petit bureau, BSC Assistance intervient à domicile sur Hyères et ses environs pour installer une sauvegarde automatique, la tester et vous montrer comment vérifier qu'elle fonctionne réellement.
Un RAID ne remplace pas une sauvegarde. Pour un poste ou un petit bureau, BSC Assistance intervient à domicile sur Hyères et ses environs pour installer une sauvegarde automatique, la tester et vous montrer comment vérifier qu'elle fonctionne réellement.
🔌 Le serveur ne s'allume plus, ou ne détecte plus aucun disque
Quand la panne vient de la carte mère ou de l'alimentation et non des disques, BSC Electronique diagnostique et répare les cartes au composant.
Quand la panne vient de la carte mère ou de l'alimentation et non des disques, BSC Electronique diagnostique et répare les cartes au composant.
💻 Rester opérationnel pendant l'immobilisation
Un serveur ou un NAS bloqué plusieurs jours en laboratoire, c'est une activité à l'arrêt. BSC Location propose des ordinateurs fixes et portables en location courte durée pour tenir la période.
Un serveur ou un NAS bloqué plusieurs jours en laboratoire, c'est une activité à l'arrêt. BSC Location propose des ordinateurs fixes et portables en location courte durée pour tenir la période.
🔧 Récupérer les données d'une grappe en échec
Deux disques tombés, rebuild impossible, volume recréé par erreur : BSC DataRecovery image chaque membre individuellement et reconstitue la grappe virtuellement, sur toutes les configurations (RAID 0, 1, 5, 6, 10, 50, JBOD, SHR, mdadm/LVM, Btrfs, ZFS, VMFS), avec salle blanche et remplacement de têtes en interne. Devis gratuit et sans engagement - diagnostic en 24 à 48 h. ☎ 09 71 32 65 95.
Deux disques tombés, rebuild impossible, volume recréé par erreur : BSC DataRecovery image chaque membre individuellement et reconstitue la grappe virtuellement, sur toutes les configurations (RAID 0, 1, 5, 6, 10, 50, JBOD, SHR, mdadm/LVM, Btrfs, ZFS, VMFS), avec salle blanche et remplacement de têtes en interne. Devis gratuit et sans engagement - diagnostic en 24 à 48 h. ☎ 09 71 32 65 95.
À retenir
1. Dégradé, c'est une alerte, pas une panne. Le temps joue contre vous, mais vous avez encore la main.
2. Sauvegarder, vérifier, puis seulement reconstruire. Cet ordre n'est pas négociable.
3. Le SMART des survivants décide : compteurs à zéro → rebuild raisonnable ; compteurs qui bougent → imagerie d'abord.
4. Ne jetez jamais le disque sorti de la grappe. C'est régulièrement lui qui sauve le dossier.
5. Méfiez-vous des mots : initialize n'est pas rebuild, effacer une config foreign n'est pas l'importer, « réparer » n'est pas toujours réparer.
6. Au premier doute, rebuild qui échoue, deuxième disque qui faiblit, volume qui ne monte plus, arrêtez. Une grappe figée se récupère bien mieux qu'une grappe « travaillée ».
Récupération sur RAID 0, 1, 5, 6, 10, 50, JBOD, NAS Synology / QNAP / Asustor, serveurs et baies de stockage - cas logiques et physiques, salle blanche et remplacement de têtes en interne.
Réception des disques par colis suivi depuis toute la France.
Diagnostic sous 24 à 48 h - devis gratuit et sans engagement.