Analyse
Comprendre ce qu'une coupure peut provoquer
Une panne d'alimentation sur un RAID peut sembler anodine si le système redémarre. Pourtant, l'arrêt brutal peut interrompre des écritures, laisser un cache incohérent, bloquer une reconstruction ou révéler un disque déjà affaibli. Le volume peut alors apparaître dégradé, absent ou partiellement lisible.
Le scénario électrique doit être reconstitué précisément : perte secteur unique, microcoupures, onduleur épuisé, bloc d'alimentation instable ou remises sous tension successives. Chaque cycle peut faire évoluer les compteurs de génération, relancer un resync et solliciter un membre qui n'avait pas achevé ses écritures. Le nombre de démarrages compte donc autant que la durée de la coupure.
Le RAID ajoute une difficulté : les données ne sont pas toujours contenues sur un seul disque. Elles sont réparties selon un niveau, un ordre, une taille de bloc et une parité. Après une coupure, une partie du volume peut sembler saine alors que les métadonnées ne correspondent plus à l'état réel.
Cache validé ne signifie pas écriture terminée sur disque
Un contrôleur en mode write-back peut confirmer une écriture à l'application alors que les blocs attendent encore dans son cache. Une batterie ou un condensateur de protection permet normalement de conserver cette file, mais une protection absente, épuisée ou défaillante change le risque. Le système de fichiers peut également avoir validé son journal alors que les données applicatives n'ont pas toutes atteint les membres du RAID.
| Symptôme après remise sous tension | Hypothèse à vérifier | Action à éviter |
|---|---|---|
| Volume « dirty » ou contrôle automatique | Écriture interrompue | Accepter une réparation sans copie préalable |
| Membre soudainement absent | Défaut antérieur révélé au démarrage | Remplacer plusieurs disques à la suite |
| Contrôleur demandant un import | Configuration étrangère ou cache incohérent | Initialiser une nouvelle configuration |
| Rebuild repris automatiquement | Reconstruction interrompue | Multiplier les redémarrages pour la relancer |
Il faut donc éviter les conclusions rapides. Un volume monté ne garantit pas que toutes les données sont cohérentes. Un disque déclaré en panne n'est pas forcément la cause initiale. Une reconstruction proposée par l'interface n'est pas toujours la bonne décision.
Analyse
Éviter la reconstruction automatique
La reconstruction RAID peut être utile dans un système maîtrisé, mais elle devient risquée quand l'état initial est incertain. Si le mauvais disque est remplacé, si l'ordre est perdu ou si un autre disque possède des secteurs faibles, l'opération peut écrire une structure incohérente.
Un redémarrage n'est pas une observation neutre : le contrôleur peut importer une configuration, marquer un membre, rejouer un journal ou lancer une resynchronisation dès l'amorçage. Avant une nouvelle tentative, il faut savoir ce que la précédente a écrit et si les sauvegardes permettent de déplacer la reprise hors de la baie sinistrée.
Figer avant de réparer
La séquence prudente tient en quatre gestes :
- Arrêter les redémarrages répétés ;
- Photographier la baie et relever les alertes sans acquitter ce qui effacerait l'historique ;
- Identifier l'état des sauvegardes dans un environnement distinct ;
- Conserver chaque membre, y compris celui que le contrôleur déclare hors ligne.
Ne pas confondre import et initialisation. L'un tente de relire une configuration existante ; l'autre peut créer de nouvelles métadonnées. Si l'interface ne permet pas de distinguer clairement les deux, aucune validation ne doit être faite sous la pression.
La bonne stratégie commence par la préservation. Tous les disques doivent être conservés, y compris ceux retirés ou déclarés défectueux. L'ordre des baies doit être noté. Les messages d'erreur, journaux et captures doivent être gardés si l'interface reste accessible.
Récupération de données sur RAID couvre le service dédié. Le diagnostic se concentre sur le moment précis qui suit une coupure : les décisions prises dans les premières heures changent souvent le résultat.
Analyse
Documenter l'état avant intervention
Un diagnostic RAID a besoin d'une chronologie claire. Il faut savoir quand la panne d'alimentation a eu lieu, combien de redémarrages ont suivi, quels disques ont changé d'état, si une reconstruction a commencé et quelles données étaient utilisées au moment de la coupure.
L'inventaire associe chaque emplacement au numéro de série, à la capacité exacte et au statut affiché, puis ajoute modèle de baie, contrôleur et niveau déclaré. Des photographies prises avant retrait conservent cette relation. Sans cette carte, deux disques identiques sortis ensemble peuvent devenir impossibles à replacer avec certitude.
Les sauvegardes doivent être identifiées mais pas restaurées à l'aveugle. Une sauvegarde peut être ancienne, incomplète ou contenir une corruption déjà propagée. Elle doit être testée dans un espace séparé, surtout si le volume RAID contient une base ou des fichiers partagés.
Une chronologie exploitable vaut mieux qu'un diagnostic supposé
Il faut relever l'heure de la coupure, le retour du courant, chaque tentative de démarrage, les changements de voyants, les membres déclarés absents et le pourcentage éventuel d'une reconstruction. Il est également utile de préciser si des écritures importantes étaient actives : base transactionnelle, VM, copie de sauvegarde ou mise à jour. Ces faits aident à distinguer une incohérence logique d'un disque déjà faible.
Il faut aussi définir les données prioritaires. Un volume complet peut contenir des archives et quelques dossiers critiques. Connaître la priorité permet d'adapter la lecture si certains disques sont instables.
Analyse
Lire les disques avec une stratégie contrôlée
La récupération d'un RAID après coupure repose souvent sur des images disque ou des lectures contrôlées. L'objectif est de travailler sur des copies quand c'est possible, puis de reconstruire virtuellement le volume avant d'extraire les données.
Chaque acquisition produit une carte des zones lues, relues ou absentes. Comparer ces cartes aux métadonnées et à la parité aide à repérer un membre en retard ou une bande incohérente sans corriger l'original. Le volume virtuel obtenu reste ensuite une hypothèse à valider par le système de fichiers et les données applicatives.
Reconstruire virtuellement, puis valider par couches
Les membres lisibles peuvent être clonés avec une stratégie adaptée à leur stabilité. L'ensemble est ensuite assemblé virtuellement en testant les paramètres connus — ordre, taille de bande, rotation de parité et décalage — sans écrire une nouvelle configuration sur les originaux. Ce n'est qu'après cohérence du système de fichiers que les fichiers prioritaires sont extraits vers un troisième support sain.
Les cas les plus sensibles concernent les bases, machines virtuelles et fichiers en cours d'écriture au moment de la panne. Même si le volume est reconstruit, certains fichiers peuvent être incohérents. Le diagnostic doit distinguer un volume accessible d’une donnée applicative exploitable.
Datastrophe aborde ces dossiers par couches : disques, configuration RAID, système de fichiers, volumes, fichiers et priorités métier. Cette progression évite de déclarer un succès trop tôt.
Analyse
Prévenir les pertes liées à l'alimentation
La prévention commence par une alimentation stable et un onduleur adapté. Mais un onduleur ne remplace pas une sauvegarde, une surveillance des disques et une procédure d'arrêt. Il réduit un risque, sans supprimer les pannes matérielles ou erreurs humaines.
Les événements antérieurs donnent la profondeur du problème : erreurs média avant incident, batterie d'onduleur en fin de vie, cache non protégé ou rebuild déjà actif. Ils doivent déclencher une action avec délai et responsable ; sinon la coupure ne crée pas seule la panne, elle révèle une dette de maintenance restée ouverte.
L'onduleur doit être testé avec la charge réelle et relié à une procédure d'arrêt propre. Son autonomie nominale ne prouve ni l'état de sa batterie ni la capacité du NAS, du serveur et des extensions à s'arrêter dans le bon ordre. Le cache protégé du contrôleur et les sauvegardes séparées restent nécessaires : ils couvrent d'autres scénarios que l'alimentation secteur.
Il faut aussi documenter le RAID avant incident : niveau, ordre des disques, modèle de baie, sauvegardes, contacts et procédure d'arrêt. Le jour où le volume ne monte plus, ces informations évitent les essais au hasard.
Après l'arrêt brutal, on conserve tous les membres dans leur ordre, on exporte les journaux sans acquitter les alertes destructrices et on teste une restauration ailleurs. Ce gel évite qu'une réparation automatique transforme un décalage encore interprétable en nouvelle configuration considérée à tort comme la référence.
Il faut également éviter de remplacer plusieurs composants à la fois. Changer l'alimentation, déplacer les disques, mettre à jour le micrologiciel et relancer le volume dans la même séquence rend l'incident difficile à comprendre. Chaque changement doit être documenté, surtout si le volume contient des données métier.
Pour tenir un délai de reprise, il est possible de restaurer les services prioritaires sur une infrastructure isolée après contrôle du point de retour. Le RAID coupé reste alors hors écriture pour l'analyse. Cette organisation traite le RTO sans sacrifier les membres qui portent peut-être une version plus récente ou les journaux nécessaires à la cohérence.
La panne d'alimentation n'est donc pas seulement un problème électrique. C'est un événement qui peut désynchroniser des couches de stockage. Le bon traitement consiste à protéger les originaux, comprendre l'ordre des événements et reconstruire le volume seulement quand les paramètres sont suffisamment établis.
Le contrôle de restitution s'effectue avec des critères préparés : période couverte, dossiers attendus, ouverture d'un échantillon, démarrage des VM et vérification applicative des bases. Les utilisateurs référents confirment le sens métier. Une arborescence visible ou un partage monté ne prouve ni la complétude ni la cohérence transactionnelle.
Cette validation évite une erreur fréquente : croire que le RAID est sauvé parce que l'arborescence réapparaît. La récupération n'est terminée que lorsque les fichiers prioritaires sont copiés sur un support sain, ouverts et compris dans leurs limites.
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 après coupure : préserver les données »
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.