Analyse
Comprendre la tolérance du RAID 10
Un RAID 10 combine miroir et agrégation. Il peut tolérer certaines pannes de disques, mais pas n'importe lesquelles. Si plusieurs disques instables appartiennent aux mauvais ensembles, le volume peut devenir inaccessible malgré la redondance.
La marge restante ne se lit pas dans le seul statut « dégradé ». Il faut rapprocher chaque alerte de la paire de miroir concernée, de la date du dernier remplacement et des latences observées. Deux membres suspects dans un même groupe de copie constituent une urgence différente de deux défauts répartis sur des miroirs encore complets.
Le RAID 10 est souvent utilisé dans des NAS, serveurs ou baies de stockage. Les données peuvent dépendre d'applications, de machines virtuelles, de bases ou de partages. La récupération doit donc tenir compte de la couche RAID et de l'usage réel des données.
La paire en défaut compte plus que le nombre brut de disques
Dans un RAID 10 à quatre membres, deux pannes peuvent être tolérées si elles ne privent pas le même miroir de toutes ses copies. Deux autres pannes, avec le même nombre de disques, peuvent rendre une partie du volume impossible à lire. La disposition varie en outre selon le contrôleur : paires de miroirs agrégées, profils near, far ou organisation propriétaire. Il ne faut jamais déduire les paires à partir de la seule position visuelle.
| État observé | Ce qu'il suggère | Décision prudente |
|---|---|---|
| Un membre hors ligne, volume stable | Miroir encore disponible | Tester la sauvegarde et documenter avant remplacement |
| Erreurs sur les deux membres supposés d'une paire | Perte imminente de bandes | Arrêter les écritures et préserver tous les membres |
| Rebuild lent avec erreurs nouvelles | Lecture intensive révélant un second défaut | Ne pas enchaîner les reconstructions |
| Ordre ou historique inconnu | Topologie incertaine | Conserver baie, contrôleur, journaux et positions |
La récupération de données sur RAID s'appuie sur cet inventaire pour retrouver paires, bandes et décalages sans écrire sur la baie. Sur un RAID 10 encore accessible, documenter cette topologie avant la chute évite de faire dépendre l'analyse des seules métadonnées survivantes.
La difficulté vient du sentiment de sécurité. Tant que le volume est accessible, les alertes sont parfois reportées. Pourtant, le RAID 10 peut passer d'un état dégradé à une perte sévère pendant une seule reconstruction si un autre disque faible lâche.
Analyse
Identifier les signaux à ne pas ignorer
Les alertes disque ne sont pas les seuls signaux. Un NAS qui devient lent, des fichiers qui s'ouvrent mal, des sauvegardes qui échouent, des journaux d'erreurs ou une reconstruction anormalement longue peuvent indiquer un problème plus large.
Le remplacement récent est lui-même un événement à surveiller. Le rebuild relit les plages du membre survivant de chaque miroir et peut révéler secteurs instables, délais de réponse ou erreurs d'interface jusque-là discrets. Une durée qui s'allonge ou un débit qui s'effondre impose de réévaluer l'opération avant d'enchaîner un second remplacement.
Les coupures d'alimentation et redémarrages répétés sont également dangereux. Ils peuvent interrompre une reconstruction, modifier des métadonnées ou masquer l'ordre réel des événements. La chronologie doit être conservée.
Après une coupure, le cache du contrôleur, le compteur de génération et les écritures interrompues doivent entrer dans la chronologie. Un disque déclaré ancien après l'arrêt brutal n'est pas nécessairement celui qu'il faut exclure en premier.
Les erreurs applicatives doivent également être prises en compte. Une base qui signale des incohérences, une machine virtuelle qui se bloque ou des fichiers récemment corrompus peuvent indiquer que le volume reste monté mais n'est plus fiable.
Une alerte SMART n'est ni un verdict ni une autorisation de continuer
Les compteurs SMART, erreurs d'interface, délais de réponse et événements du contrôleur doivent être lus ensemble. Une absence d'alerte ne certifie pas un disque sain ; une alerte isolée ne désigne pas automatiquement le membre à retirer. La tendance, la chronologie et la position dans le miroir donnent le contexte utile.
Analyse
Préserver avant reconstruction
Avant toute action, il faut relever l'ordre des disques, les emplacements, les numéros de série, les messages du contrôleur, le niveau RAID et les actions déjà réalisées. Ces informations peuvent devenir indispensables si le volume ne remonte plus.
Une initialisation, un import forcé ou un rebuild peut réécrire des superblocs et entériner une mauvaise composition. De même, déplacer les membres vers une autre baie sans noter positions et identifiants expose à un assemblage différent. Tant que les deux côtés de chaque miroir ne sont pas attribués avec confiance, les commandes qui modifient l'ensemble restent suspendues.
Les sauvegardes doivent être testées avant de lancer une opération lourde. Une sauvegarde trop ancienne, incomplète ou corrompue ne doit pas être découverte après une reconstruction ratée. Le test doit confirmer que les fichiers essentiels s'ouvrent.
La reprise opérationnelle peut être organisée sur une restauration testée ou un environnement provisoire, tandis que le RAID 10 est figé. Cette séparation empêche les journaux, snapshots et écritures applicatives de continuer à modifier un volume fragile simplement parce qu'il répond encore aux requêtes.
Il faut aussi éviter les manipulations de panique. Retirer plusieurs disques, changer l'ordre dans la baie ou accepter toutes les propositions de l'interface peut faire perdre les repères nécessaires à une reconstruction maîtrisée.
Arrêt contrôlé recommandé quand la situation se dégrade. Si des erreurs touchent plusieurs membres, si le volume se fige ou si une reconstruction accumule les défauts, maintenir la production pour « finir la copie » peut consommer les dernières lectures utiles. La décision doit intégrer la valeur des données et l'état d'une sauvegarde réellement testée.
Analyse
Décider avec une vision d'ensemble
Un disque en alerte n'est pas toujours le seul problème. Le diagnostic doit regarder l'ensemble : disques, contrôleur, métadonnées RAID, système de fichiers, volumes logiques, hyperviseur et applications. Une décision prise sur un seul disque peut manquer le vrai risque.
L'ordre de lecture découle des dépendances métier : disque système et fichiers de configuration d'une VM, données et journaux d'une base, puis partages ou archives utiles. Cette carte évite de consommer une fenêtre de lecture limitée sur des blocs volumineux mais secondaires alors qu'un petit ensemble cohérent permettrait déjà une reprise.
La récupération d'un RAID 10 peut nécessiter de reconstruire virtuellement l'ensemble plutôt que de réparer la baie source. Travailler sur des copies des disques permet d'analyser sans consommer les supports originaux.
Le diagnostic Datastrophe vise d'abord une composition virtuelle vérifiable à partir des copies disponibles. Le montage d'un volume n'est qu'une étape : machines virtuelles, bases et documents prioritaires doivent ensuite être ouverts ou contrôlés sur un support de restitution sain, avec les lacunes signalées.
Le diagnostic doit rester documenté. Une capture des alertes, la liste des disques, les dates de remplacement et l'état des sauvegardes évitent les décisions contradictoires. Cette documentation simple accélère la prise en charge si le volume tombe.
Dossier minimal avant transport ou analyse
- Photo de la baie avec les positions lisibles ;
- Modèle et numéro de série de chaque disque ;
- Niveau RAID déclaré et contrôleur utilisé ;
- Historique des remplacements, arrêts et reconstructions ;
- Alertes exactes, pas seulement « disque en panne » ;
- Dossiers, VM ou bases à récupérer en priorité.
Ces éléments permettent de tester une reconstruction virtuelle sur des copies sans confondre une ancienne panne, un membre de remplacement et le dernier disque sorti de l'ensemble.
Analyse
Prévenir la prochaine alerte
Après incident, la documentation RAID doit être mise à jour : niveau, ordre des disques, capacité, contrôleur, micrologiciel, sauvegardes et procédure d'arrêt. Une documentation courte peut éviter des décisions improvisées lors de la prochaine alerte.
Chaque signal doit avoir une règle d'escalade : qui accuse réception, quelle sauvegarde restaurer en témoin, quels compteurs comparer et à partir de quels gels ou erreurs multiples arrêter la baie. Sans délai et responsable explicites, la supervision produit un historique, pas une protection.
Les sauvegardes doivent être séparées du RAID. Le RAID améliore la disponibilité, mais il ne remplace pas une sauvegarde. Suppression, corruption, ransomware, erreur humaine ou reconstruction ratée peuvent toucher le volume entier.
La fenêtre offerte par un miroir encore lisible sert à valider une copie indépendante et à cartographier les paires, pas à reporter indéfiniment l'intervention. La panne devient imminente lorsque les erreurs convergent sur un même miroir, que la reconstruction ralentit ou que le volume perd sa stabilité sous charge.
Après retour à un état stable, un test de restauration doit être réalisé. Tant que la sauvegarde n'a pas été ouverte, le RAID reste le seul filet perçu. La prévention réelle repose sur une copie indépendante et contrôlée, pas sur la seule redondance.
Le stock de remplacement doit être contrôlé avant l'incident : capacité utile au moins égale, format de secteurs compatible, interface attendue et comportement accepté par le contrôleur. Découvrir pendant le rebuild qu'un disque est rejeté ou plus petit multiplie les manipulations sur les membres déjà sollicités.
Il faut enfin décider à l'avance quand arrêter le volume. Si les erreurs s'accumulent, continuer à servir des données peut être plus risqué qu'une coupure contrôlée. Cette règle doit être connue avant l'incident.
Un responsable nommé doit pouvoir arbitrer l'arrêt selon la criticité des données et le test de sauvegarde, afin qu'une alerte touchant les deux côtés d'un miroir ne reste pas en attente entre exploitation et infrastructure.
Sources techniques primaires et limites
La documentation du noyau Linux sur les ensembles MD décrit superblocs, rôles, assemblage et états d’un RAID logiciel. Elle ne permet pas d’appliquer automatiquement une géométrie ou une génération à une baie propriétaire, et ne justifie aucune reconstruction sur les membres originaux.
Faire qualifier le dossier « RAID 10 : détecter une panne imminente »
Transmettez à Datastrophe tous les membres actifs, retirés et de secours avec leur ordre de slot, le contrôleur et son cache, les configurations, les cartes d’erreurs et les volumes prioritaires. Les codes, clés et éléments d’authentification autorisés sont communiqués par un canal distinct ; ils ne sont jamais inscrits sur le support ni dans le colis.
Datastrophe réalise directement le diagnostic, les contrôles d’intégrité et la récupération dans son laboratoire, avec sa propre équipe. Le diagnostic et le devis sont gratuits. Le transport privé aller et retour est systématiquement pris en charge ; le transporteur déplace uniquement le colis scellé, sans accéder aux données ni les traiter.
Avant tout paiement, le client reçoit le prix proposé et une liste contrôlée. Chaque élément y est classé, dans cet ordre, recoverable_verified, partial, detected_unverified ou unrecoverable. Seuls les éléments recoverable_verified, dont le contenu a été contrôlé et jugé exploitable, sont présentés comme récupérables. Le client paie seulement après avoir accepté la liste et le prix ; la préparation du résultat et la restitution interviennent ensuite.
Si aucune donnée exploitable n’est vérifiée, si la récupération échoue ou si le client refuse la liste ou le prix, aucun frais standard n’est dû. La seule exception concerne une pièce rare, coûteuse et non remboursable : elle ne peut être commandée qu’après une proposition séparée, explicite et chiffrée.