Récupération de données sur RAID, NAS et baie

Après une seconde panne ou un mauvais ordre de disques, ne lancez pas de rebuild : une reconstruction écrite peut propager silencieusement des blocs erronés.

Demander un devis

La bonne réaction est d’arrêter les écritures

Rebuild, import forcé et remplacement en série modifient les membres avant que leur rôle soit compris.

Éteignez l’ensemble de manière contrôlée et notez l’état affiché. Ne réinitialisez aucun disque et ne confirmez pas une reconstruction. Les journaux, voyants et captures déjà disponibles sont conservés. Un RAID dégradé peut encore présenter ses partages tout en réécrivant des blocs, ce qui rend la continuité d’activité dangereuse pour la récupération.

Avant l’arrêt, seules les informations déjà visibles sont consignées : membres signalés, progression éventuelle, alertes et heure de la dernière activité. On ne provoque pas un nouveau scan pour enrichir le diagnostic. Les postes clients sont déconnectés et les tâches de sauvegarde ou de réplication suspendues. Si l’activité doit continuer, elle repart sur un stockage distinct qui ne monte aucun volume issu de l’ensemble concerné.

Aucun rebuild ni resynchronisation
Aucun disque neuf ajouté
Aucune écriture depuis les utilisateurs

Une seconde panne change le risque

Le premier membre absent peut déjà avoir laissé le système sans redondance. Le second défaut, même intermittent, touche alors des blocs uniques. Continuer à lire en production multiplie les erreurs et les écritures de journal.

Un rebuild interrompu crée un état hybride

Certaines zones reflètent l’ancienne géométrie, d’autres la nouvelle. Reprendre à l’aveugle peut aggraver la divergence. Les positions et l’avancement sont documentés avant toute reconstruction sur des copies.

Un volume encore monté n’est pas une garantie de cohérence après plusieurs pannes.

L’ordre physique des membres doit être photographié

Numéro de baie, série et statut sont relevés avant le premier retrait.

Chaque disque reçoit une identité indépendante de son emplacement futur. Étiquettes, numéros de série, tiroirs, câbles et ordre sont consignés. On ne se fie pas uniquement aux voyants : un disque déclaré « failed » peut contenir une version plus récente qu’un membre revenu en ligne. L’historique des remplacements aide à dater chaque état.

Les disques de réserve, anciens membres et caches SSD sont inclus dans l’inventaire sans être mélangés aux emplacements actifs. Une photo générale est complétée par un gros plan lisible de chaque numéro de série. Pour une baie à tiroirs, le numéro de baie reste distinct du numéro donné par le système. Cette double identification permet de reconstruire l’ordre même après transport et de repérer une inversion antérieure.

Photo nette de toutes les baies
Étiquette par série et position
Conservation des contrôleurs et alimentations

Les disques retirés restent dans le dossier

Un membre remplacé plus tôt peut contenir métadonnées, superblock ou fichiers utiles. Il n’est ni formaté ni écarté avant comparaison. L’âge du contenu est établi par plusieurs indices.

Le contrôleur conserve parfois des paramètres

Cache, configuration et micrologiciel peuvent expliquer l’ensemble. On garde carte, batterie et fichiers de configuration, mais on n’impose pas une importation. La géométrie peut être déduite sans écrire sur les disques.

Remettre les disques dans un autre ordre peut faire importer une géométrie erronée.

La géométrie se démontre avant d’assembler les blocs

Niveau RAID, ordre, taille de bande, rotation de parité et décalage doivent produire des structures cohérentes.

Plusieurs hypothèses sont comparées sur les images des membres. Une bonne géométrie fait apparaître des partitions, métadonnées et fichiers plausibles sur la durée, pas seulement un en-tête. Les systèmes propriétaires ou hybrides peuvent ajouter pools, groupes de volumes ou caches SSD. Chaque couche est reconstruite sans modifier les sources.

La comparaison utilise des structures situées à différents offsets, des fichiers dont le contenu est connu et les règles de parité attendues. Une combinaison qui ouvre un dossier mais produit des archives incohérentes est rejetée. Pour un RAID 10, les paires et l’ordre d’entrelacement doivent être démontrés ; pour un RAID 6, les deux parités et leur rotation sont testées. Les résultats restent des vues virtuelles distinctes jusqu’à validation.

Recherche des superblocks et signatures
Validation sur plusieurs zones
Hypothèses conservées séparément

RAID 0 et JBOD n’offrent aucune redondance

Chaque membre fournit des blocs uniques. Un disque manquant laisse des lacunes régulières ou une plage entière absente. La récupération dépend alors directement de l’acquisition physique de tous les membres.

RAID 5 et 6 exigent la bonne parité

La rotation et le sens de parité changent selon les contrôleurs. Une reconstruction plausible est vérifiée par des fichiers connus et des structures internes, jamais choisie sur un seul montage réussi.

Voir une partition ne suffit pas : une mauvaise parité peut corrompre silencieusement les fichiers plus loin.

Chaque disque est acquis selon son propre état

Un ensemble ne se lit pas à la vitesse de son membre le plus sain.

Les sources sont imagées séparément avec suivi des erreurs. Un HDD qui clique reste hors tension jusqu’au diagnostic mécanique ; un SSD intermittent reçoit des paramètres adaptés. Les secteurs absents sont cartographiés par membre. La reconstruction virtuelle utilise ces copies et ne force pas le NAS à resynchroniser.

Les membres sains sont acquis eux aussi : leur rôle ne se limite pas à compenser le disque déclaré en panne. Chaque image reçoit une empreinte, une référence de position et un journal de lecture. Si un support se dégrade, les bandes liées aux métadonnées ou aux données prioritaires passent avant les reprises générales. Le nombre d’erreurs est ensuite interprété dans la géométrie, car une même zone logique traverse plusieurs membres.

Acquisition individuelle des membres
Journal des secteurs manquants
Originaux protégés après copie

Un HDD mécanique peut nécessiter le laboratoire

Clics, frottement ou blocage peuvent imposer une ouverture contrôlée. La salle blanche protège alors les plateaux pour créer une fenêtre d’acquisition, sans remettre le membre en service.

Les priorités guident les reprises difficiles

Des chemins ou bases critiques permettent de relier bandes et secteurs aux membres concernés. Les relectures risquées se concentrent ainsi sur ce qui apporte une valeur réelle au dossier.

Un seul disque instable peut dégrader des bandes réparties sur tout le volume.

Le volume logique vient après le RAID virtuel

Pools, LVM, Btrfs, ZFS, ext4 ou NTFS forment encore une couche à reconstruire.

Un RAID correctement assemblé peut contenir un système de fichiers endommagé. Les journaux et snapshots sont examinés sur un clone. Les partages sont reconstruits avec leurs noms lorsque les métadonnées le permettent. Les fichiers récupérés par signature sans chemin restent séparés pour ne pas fabriquer une arborescence trompeuse.

Les couches sont nommées et figées : ensemble RAID, pool, volume logique, système de fichiers, partage puis application. Une correction appliquée au niveau Btrfs ou ZFS ne doit pas masquer une géométrie incertaine dessous. Les snapshots sont datés et comparés sans être promus automatiquement comme état le plus récent. Un fichier visible est relié aux bandes réellement lues afin que les secteurs manquants restent traçables.

Montage en lecture seule
Analyse des pools et volumes
Copies distinctes pour les réparations

Les machines virtuelles ajoutent un conteneur

Un VMDK ou VHDX récupéré doit encore être vérifié avec sa chaîne. La récupération de disque virtuel sépare le magasin de données, l’instantané et le système invité.

Les bases et LUN exigent leur contexte

Une LUN iSCSI ou une base peut être fragmentée dans le pool. Les applications, versions et priorités servent à tester la cohérence après extraction, sans démarrer directement la production.

Un snapshot situé sur le même ensemble ne protège pas contre la panne de plusieurs membres.

Chiffrement, déduplication et caches ne se devinent pas

Une clé, un cache SSD ou une table de déduplication peut être indispensable à l’interprétation du volume.

Conservez les clés, les contrôleurs, les modules et la configuration. Un volume chiffré reste illisible malgré un RAID bien reconstruit. Une déduplication perd sa cohérence si ses index manquent. Un cache ne doit pas être réinitialisé avant d’avoir établi s’il contient des écritures non destagées. Chaque dépendance est traitée comme une source.

La batterie du cache, la NVRAM et les journaux du contrôleur peuvent décrire des écritures reconnues mais pas encore déposées sur les disques. Leur état est relevé hors de toute réinitialisation. Les clés de volume, certificats et mots de passe sont transmis séparément du matériel. Une table de déduplication partielle est évaluée avant extraction, car un bloc partagé manquant peut affecter de nombreux fichiers pourtant présents dans les répertoires.

Clés transmises par un canal séparé
Caches et NVRAM préservés
Aucune réinitialisation d’usine

Le cache peut contenir la dernière transaction

Une batterie épuisée ne rend pas automatiquement son contenu inutile. Carte et module sont conservés pour comprendre l’état des écritures. Une importation forcée pourrait écraser cette information.

La configuration exportée réduit les hypothèses

Niveau, bande, pools et versions accélèrent l’analyse, mais ne sont pas considérés comme exacts sans vérification sur les membres. Une erreur de configuration peut précisément être la cause de la panne.

Datastrophe n’élude pas les protections ; une clé absente peut être la limite finale.

La validation descend jusqu’aux partages et applications

Un volume monté ne prouve pas que les documents ou bases sont complets.

Les données prioritaires sont testées sur une restitution isolée. Documents, archives, bases, VM et sauvegardes font l’objet de contrôles adaptés. Les fichiers touchés par les secteurs absents sont signalés. Un démarrage d’application ne se fait qu’après duplication et sans connexion immédiate à la production.

Le contrôle suit l’usage attendu : une sauvegarde doit accepter une restauration de test, une VM doit retrouver sa chaîne et une base doit répondre à des vérifications représentatives. Les droits et dates sont conservés lorsqu’ils sont cohérents, mais ne remplacent pas l’ouverture du contenu. Les lots remis reçoivent des empreintes et une liste des zones ou objets partiels pour préparer la migration vers le nouvel ensemble.

Contrôle des partages prioritaires
Tests applicatifs sur une copie
Liste des éléments partiels

La remise en service utilise un nouvel ensemble

Les fichiers validés sont copiés vers un stockage sain. Le RAID d’origine n’est pas reconstruit en place ni réutilisé comme destination. Une seconde copie est conservée avant migration.

Les droits et noms restent utiles mais insuffisants

Ils sont préservés lorsque les métadonnées sont cohérentes. Une arborescence complète peut néanmoins pointer vers des blocs absents ; l’ouverture des fichiers reste le contrôle déterminant.

Le nombre de téraoctets assemblés ne mesure pas la cohérence d’une base ou d’une VM.

L’inventaire du RAID prépare un devis réaliste

Nombre de baies, historique et services attendus comptent davantage que la capacité seule.

Indiquez la marque, le modèle, le niveau supposé, le nombre de membres et leur ordre. Décrivez le premier incident, les remplacements, les reconstructions et les messages. Listez les partages, les VM, les bases et les dates prioritaires. Joignez les captures déjà disponibles et la configuration exportée, sans redémarrer le NAS pour produire de nouveaux journaux.

Pour une prise en charge depuis la Belgique, le matériel à acheminer est défini après cet inventaire : tous les membres sont généralement requis, parfois avec châssis, contrôleur ou cache. Chaque disque est emballé séparément, protégé contre les chocs et identifié sans masquer son étiquette. Les secrets suivent un canal distinct. Le devis tient alors compte du nombre de sources, de leur état et du niveau de validation demandé.

Photographiez les baies avant retrait
Emballez chaque disque séparément
Gardez le contrôleur, le cache et les anciens membres

La continuité d’activité doit être séparée

Un nouveau stockage peut accueillir les nouveaux fichiers, sans recopier ni resynchroniser vers les sources. Cette isolation évite que l’urgence opérationnelle modifie le seul état récupérable.

La demande précise le résultat attendu

Dans la demande de devis, indiquez s’il faut des fichiers, des partages, une base ou des VM. La méthode et les limites sont confirmées après inventaire des membres.

Ne remettez aucun membre en ligne uniquement pour vérifier son voyant.

FAQ

Questions fréquentes

Faut-il lancer un rebuild après le remplacement d’un disque ?

Non lorsque les données sont en jeu ou qu’une seconde panne est possible. Le rebuild écrit sur tous les membres et peut propager des erreurs. Arrêtez les écritures, documentez l’ordre et faites acquérir chaque source avant reconstruction virtuelle.

Pourquoi conserver un disque déjà déclaré défaillant ?

Il peut contenir une version plus récente de certains blocs, des superblocks ou des métadonnées utiles. Le statut du contrôleur ne suffit pas à dater son contenu. Tous les anciens membres restent identifiés jusqu’à comparaison.

Un RAID 5 reste-t-il récupérable après deux pannes ?

Cela dépend de l’état réel des deux membres et des zones touchées. Les secteurs encore lisibles peuvent permettre une reconstruction partielle. Les blocs absents sur plus de membres que la parité ne peut en compenser restent irrécréables.

Le NAS doit-il être envoyé avec les disques ?

Souvent, le châssis, le contrôleur, le cache et la configuration apportent des informations utiles. Ne retirez les membres qu’après avoir photographié et étiqueté leur ordre. La liste précise du matériel nécessaire est définie avant l’envoi.

Un volume remonté signifie-t-il que tout est récupéré ?

Non. Une géométrie erronée peut montrer une arborescence tout en corrompant les blocs. Partages, fichiers, bases et VM prioritaires doivent être ouverts ou testés sur des copies avant toute remise en production.

Supports

Autres expertises

Diagnostic

Un doute sur un support ou une panne ?

Datastrophe évalue le risque avant toute intervention et vous oriente vers la démarche la plus prudente.

Demander un diagnostic