Deux disques sont tombés en panne dans votre matrice Synology SHR-1. DSM indique que le pool de stockage est en état Crashed et précise que les données ne peuvent pas être récupérées. La récupération des données SHR-1 après une double panne de disque est l’objet de cet article — et la situation est en réalité plus nuancée que ne le laisse entendre le message de DSM. La récupérabilité de vos données ne dépend pas uniquement du nombre de disques défaillants, mais aussi de la manière dont ils sont tombés en panne et de l’état des disques restants.
Commencez par identifier votre situation
Avant de poursuivre, utilisez ce tableau pour repérer votre cas précis et accéder directement à la section correspondante :
| Constat | Situation probable | Perspective de récupération des données | Voir |
|---|---|---|---|
| Les deux disques apparaissent dans le système d’exploitation, les superblocs sont lisibles | Défaillance logique — disques physiquement intacts | Possible | Niveau 1 → Niveau 2 |
| Un disque est lisible, l’autre n’est pas détecté | Une défaillance logique + une défaillance matérielle | Partielle | Niveau 2 → Niveau 3 |
| Le second disque est tombé en panne pendant la reconstruction après le premier | Panne double classique — perte de données partielle probable | Partielle | Niveau 2 |
| Un disque ou les deux cliquent, émettent des bruits de frottement, ou ne sont pas détectés | Défaillance matérielle — têtes de lecture/écriture ou plateaux | Intervention en laboratoire requise | Niveau 3 |
Pourquoi deux pannes compromettent mathématiquement le SHR-1
Le SHR-1 utilise un ensemble de parité unique — conceptuellement équivalent à un RAID 5 en matière de tolérance aux pannes. Pour chaque bande (stripe) de l’ensemble, un disque contient la parité XOR des autres. Lorsqu’un disque tombe en panne, n’importe quel bloc de données manquant peut être recalculé : il suffit de prendre le bloc de parité et de le soumettre à un XOR avec tous les blocs de données encore disponibles pour retrouver la valeur manquante. Cela fonctionne parce qu’il n’y a qu’une inconnue et une seule équation.
Avec deux disques défaillants, il y a deux inconnues par bande et toujours une seule équation de parité. Le calcul n’a pas de solution. Aucun logiciel, quelle que soit sa présentation commerciale, ne peut reconstruire deux valeurs indépendamment inconnues à partir d’une seule relation XOR. Il ne s’agit pas d’une limitation d’un outil particulier, mais d’une propriété intrinsèque du schéma de parité.
Ce que le logiciel peut faire, en revanche, c’est récupérer les données des bandes auxquelles un seul des deux disques en panne a contribué. Si vos fichiers sont stockés sur des bandes qui n’impliquent pas simultanément les deux disques défaillants, ils sont récupérables. En revanche, les fichiers répartis sur des bandes faisant intervenir les deux membres du groupe en panne ne le sont pas. La proportion de données récupérables dépend de la taille et de la répartition des disques défaillants dans le volume — c’est pourquoi une récupération partielle est souvent possible, même lorsqu’une récupération complète ne l’est pas.
Le SHR-2 stocke deux ensembles de parité indépendants par bande — à l’instar d’un RAID 6 — et tolère la défaillance simultanée de deux disques sans perte de données. En revanche, le SHR-2 n’est pas immunisé contre ce scénario : trois pannes simultanées compromettent son calcul de parité de la même manière que deux pannes compromettent le SHR-1. Si vous utilisez le SHR-2 et avez perdu trois disques, la logique ci-dessous s’applique également. Pour une comparaison pratique de la tolérance aux pannes du SHR-1 et du SHR-2, consultez notre article sur la récupération de données SHR/SHR-2 après une panne matérielle Synology.
La manière dont les deux disques sont tombés en panne est déterminante
Toutes les doubles pannes ne se valent pas. L’ordre et la nature des pannes déterminent les possibilités de récupération de données :
Défaillance simultanée — incident d’alimentation ou contrôleur
Les deux disques ont cessé de répondre au même moment. Les données présentes sur chaque disque sont probablement physiquement intactes : le système RAID a simplement perdu le quorum. Il s’agit de la forme de double panne la plus facilement récupérable, car aucune des données des disques n’a été partiellement écrasée.
Échec du deuxième disque pendant la reconstruction
Le premier disque est tombé en panne, le tableau RAID a fonctionné en mode dégradé, puis une reconstruction RAID a été lancée — et le deuxième disque est tombé en panne en cours d’opération. Les nouvelles informations de parité étaient en cours d’écriture sur le disque de remplacement lorsque le deuxième disque d’origine est tombé en panne. Les bandes de données reconstruites avant le deuxième échec restent intactes ; celles qui étaient en cours de reconstruction au moment du deuxième échec sont corrompues. Une récupération partielle des données est généralement possible.
Le premier disque est tombé en panne depuis longtemps, sans être détecté
Le RAID est resté en mode dégradé — sans redondance — pendant une longue période, puis le second disque est tombé en panne. Si la première défaillance est passée inaperçue, d’autres écritures ont pu être effectuées entre-temps sur des bandes RAID dégradées. Les chances de récupération des données dépendent entièrement de l’état physique du deuxième disque en panne. Consultez notre article sur la détection des premiers signes de panne de disque dur pour identifier ce type de problème plus tôt.
Évaluer l’état physique de chaque disque
Avant toute tentative logicielle, déterminez si les disques peuvent être lus physiquement. Arrêtez proprement le NAS s’il est encore en fonctionnement — ne procédez pas à un redémarrage forcé et n’insérez pas de disque de remplacement, car cela inciterait DSM à lancer une nouvelle reconstruction. Connectez chaque disque individuellement à une machine de récupération.
Si un disque émet des cliquetis audibles, des bruits de frottement ou présente des tentatives répétées de démarrage infructueuses, mettez-le immédiatement hors tension et n’effectuez aucune autre lecture. Chaque cycle de démarrage sur un disque dont les têtes sont endommagées aggrave la détérioration des plateaux. Passez directement au niveau 3.
Pour les disques qui démarrent sans bruit anormal, exécutez mdadm --examine sur chaque partition de périphérique :
mdadm --examine /dev/sdb3 Magic : a92b4efc Version : 1.2 Feature Map : 0x0 Array UUID : 4b2f8e1a:7c3d9f02:1a4b8c3d:9e2f7b01 Name : DiskStation:2 Creation Time : Fri Mar 10 14:22:31 2023 Raid Level : raid5 Raid Devices : 3 Avail Dev Size : 7813959680 Array Size : 15627862016 Used Dev Size : 7813931008 Data Offset : 2048 sectors Super Offset : 8 sectors Unused Space : before=1968 sectors, after=0 sectors State : clean, degraded Device UUID : 9d3f1c2a:4e8b7f03:2c1d9e4b:7a3f8c01 Update Time : Mon Jun 2 09:14:22 2025 Bad Block Log : 512 entries available at offset 16 sectors Checksum : 3f8a1b2c - correct Events : 247
Recherchez trois éléments : l’UUID de l’array doit être identique sur tous les disques — s’il ne l’est pas, cela signifie qu’un disque provient d’un autre array RAID ou que son superbloc est corrompu. Le compteur Events doit être proche d’un membre à l’autre — un écart important indique qu’un disque a manqué un nombre significatif d’opérations d’écriture. Le champ State affichera clean, degraded sur un disque qui faisait partie d’un array ayant perdu un membre.
Ouvrez également à ce stade le moniteur S.M.A.R.T. intégré dans RS RAID Retrieve. Les valeurs Reallocated Sector Count et Pending Sectors sur un disque encore fonctionnel sont importantes : un disque accumulant des secteurs défectueux pendant une période déjà dégradée peut avoir généré des erreurs de lecture silencieuses, susceptibles d’avoir affecté l’intégrité des données avant la seconde panne. Pour plus d’informations sur l’interprétation des données S.M.A.R.T., consultez notre article sur les signes de panne d’un disque dur.
Trois niveaux de récupération
N’empruntez cette voie que si la commande mdadm --examine renvoie des superblocs valides avec des UUID identiques sur tous les disques. L’approche en terminal offre un contrôle direct à chaque étape, mais elle comporte des limites importantes : tous les disques doivent être physiquement présents et lisibles, aucune solution de repli n’est possible si les superblocs sont endommagés, et il est impossible de déterminer à l’avance quels fichiers sont corrompus. Créez une image de chaque disque avec ddrescue avant d’exécuter l’une quelconque des commandes ci-dessous — travaillez exclusivement à partir des images disque.
Étape 1 — Créez une image de chaque disque avant toute autre opération
# Installer ddrescue s’il n’est pas déjà présent apt-get install -y gddrescue # Créer une image de chaque disque dans un fichier distinct — exécuter la commande pour chaque membre ddrescue -d -r3 /dev/sdb /mnt/images/sdb.img /mnt/images/sdb.log ddrescue -d -r3 /dev/sdc /mnt/images/sdc.img /mnt/images/sdc.log ddrescue -d -r3 /dev/sdd /mnt/images/sdd.img /mnt/images/sdd.log
L’option -r3 indique à ddrescue de réessayer la lecture des secteurs illisibles trois fois avant de les marquer comme défectueux. Le fichier .log permet de reprendre le clonage de disque en cas d’interruption. Ne sautez pas cette étape : un disque présentant des secteurs défectueux masqués se dégradera davantage sous la charge de lecture continue imposée par la reconstruction du RAID.
Étape 2 — Vérifier les superblocs sur tous les membres
# Exécuter sur chaque image — vérifier que l'UUID et les Events correspondent mdadm --examine /mnt/images/sdb.img mdadm --examine /mnt/images/sdc.img mdadm --examine /mnt/images/sdd.img
Avant de poursuivre, vérifiez trois éléments. La valeur Array UUID doit être identique sur toutes les images : toute différence indique qu’un disque appartient à un autre RAID logiciel ou que son superbloc est corrompu. Le compteur Events doit rester proche d’un membre à l’autre : un écart de plusieurs centaines ou milliers signifie qu’un disque a manqué une séquence importante d’écritures. Le nombre Raid Devices doit correspondre au nombre attendu de membres du tableau RAID.
Étape 3 — Forcer l’assemblage à partir de fichiers image
# Indiquer au noyau de traiter les fichiers image comme des périphériques bloc losetup /dev/loop0 /mnt/images/sdb.img losetup /dev/loop1 /mnt/images/sdc.img losetup /dev/loop2 /mnt/images/sdd.img # Forcer l’assemblage — spécifier les partitions de données, et non le périphérique complet mdadm --assemble --force /dev/md0 /dev/loop0p3 /dev/loop1p3 /dev/loop2p3 # Vérifier le résultat de l’assemblage cat /proc/mdstat mdadm --detail /dev/md0
--force assemble l’ensemble RAID même en l’absence d’un nombre suffisant de membres pour obtenir un état cohérent. L’ensemble obtenu est en mode dégradé. Les bandes RAID (stripes) qui incluaient les deux disques en échec contiennent des données reconstruites avec une parité incorrecte ; les fichiers situés sur ces bandes seront corrompus ou réduits à zéro octet lors de la copie. Les fichiers situés sur des bandes n’ayant touché qu’un seul disque en échec restent intacts et lisibles. Il est impossible de déterminer, de l’extérieur, dans quelle catégorie se trouve chaque fichier avant de tenter de le copier.
Étape 4 — Activer LVM et monter en lecture seule
# Activer le groupe de volumes LVM sur le tableau assemblé pvscan vgchange -ay # Lister les volumes логiques pour identifier le bon chemin de périphérique lvs # Monter en lecture seule — ne jamais monter en lecture/écriture sur un tableau endommagé mount /dev/vg1/volume_1 /mnt/data -o ro
Montez toujours avec -o ro. Toute écriture sur un tableau reconstruit de force dans cet état propagera la corruption aux bandes auparavant intactes. Une fois le montage effectué, vérifiez l’arborescence des répertoires et la taille des fichiers avant de lancer toute opération de copie. Les fichiers corrompus se manifestent par des erreurs de lecture, des erreurs d’E/S ou une sortie de taille zéro lors de la copie — il n’existe aucun indicateur préalable.
Étape 5 — Copie avec gestion des erreurs
# Utiliser rsync avec journalisation des erreurs — ignore les fichiers illisibles au lieu d’interrompre l’opération rsync -av --ignore-errors /mnt/data/ /mnt/destination/ 2>&1 | tee /mnt/rsync.log # Examiner les éléments ignorés grep -i "error|failed|cannot" /mnt/rsync.log
La commande standard cp s’arrête au premier erreur de lecture. rsync --ignore-errors consigne l’échec dans le journal et passe au fichier suivant, ce qui maximise la quantité totale de données récupérées. Analysez ensuite le journal pour identifier les fichiers qui n’ont pas pu être copiés — il s’agit de ceux situés sur des bandes de répartition impliquant les deux disques en panne.
Quand s’arrêter et passer au niveau 2 :
mdadm --examine indique des UUID non concordants entre les disques ; l’assemblage avec --force échoue ou produit un volume inactive dans /proc/mdstat ; l’activation LVM ne détecte aucun groupe de volumes ; le système de fichiers se monte, mais affiche une arborescence vide ou corrompue. L’un quelconque de ces cas signifie que le superbloc ou les métadonnées LVM sont trop endommagés pour une récupération manuelle — le constructeur RAID de RS RAID Retrieve prend en charge ces situations.
RS RAID Retrieve prend en charge l’intégralité du processus — diagnostic S.M.A.R.T., création d’images disque, reconstruction RAID, activation LVM et accès au système de fichiers — au sein d’une seule application sous Windows, Linux ou macOS. L’outil couvre deux parcours de reconstruction distincts selon l’état des superblocs mdadm.
Évaluation S.M.A.R.T. — avant toute opération de lecture
Connectez tous les disques à la station de récupération et ouvrez le moniteur S.M.A.R.T. intégré avant de lancer l’analyse. Les attributs les plus importants dans ce cas sont Reallocated Sector Count (ID 05), Current Pending Sector Count (ID C5) et Uncorrectable Sector Count (ID C6). Toute valeur non nulle pour l’un de ces attributs — en particulier sur les disques qui semblent être les survivants « sains » — indique des secteurs déjà défaillants pendant la période de dégradation précédant la panne du deuxième disque. Un disque survivant présentant un nombre élevé de secteurs en attente est un disque susceptible de générer des erreurs de lecture au cours d’une analyse de reconstruction de plusieurs heures.
Création d’image de disque — protégez les données d’origine des sollicitations liées à l’analyse
Pour tout disque présentant des valeurs S.M.A.R.T. élevées, utilisez la fonction intégrée de création d’image de RS RAID Retrieve afin de générer une image secteur par secteur avant l’analyse de reconstruction. L’outil de création d’image effectue plusieurs passages sur les secteurs problématiques, consigne les zones illisibles à l’aide d’une carte des secteurs défectueux et produit un fichier image complet représentant la meilleure lecture possible de ce disque. Toutes les étapes suivantes — reconstruction du RAID, activation de LVM, analyse du système de fichiers — s’exécutent sur le fichier image statique plutôt que sur le disque source en fonctionnement. Cela évite d’aggraver l’état du disque sous la charge de lecture d’une analyse complète du volume, laquelle peut durer plusieurs heures sur une configuration SHR multi-téraoctets.
Reconstruction automatique du RAID — lorsque les superblocs sont intacts
RS RAID Retrieve analyse tous les disques et images connectés à la recherche de signatures de superbloc mdadm. Lorsqu’il en trouve, le logiciel lit l’UUID du tableau, le niveau RAID, les rôles des périphériques membres, la taille de bloc de bande (stripe) et les compteurs d’événements de l’ensemble des membres. Il reconstruit ensuite la topologie du volume SHR — tableau mdadm → volume physique LVM → groupe de volumes → volume logique → système de fichiers Btrfs ou ext4 — sans exiger de quorum valide et sans écrire la moindre donnée sur les disques स्रोत. En cas de double défaillance, lorsque les deux disques sont physiquement lisibles et que les superblocs sont intacts, cette méthode ne nécessite généralement aucune saisie manuelle.
La reconstruction s’effectue en mode dégradé : les bandes auxquelles les deux disques défaillants ont contribué ne peuvent pas être reconstruites à partir de la parité, et les fichiers correspondants sont marqués comme inaccessibles. Les bandes auxquelles un seul des deux disques défaillants a contribué sont reconstruites à partir des données du membre restant et de la parité : ces fichiers sont alors entièrement récupérables. Le logiciel signale les fichiers inaccessibles dans l’arborescence avant l’étape de copie, afin de permettre d’évaluer précisément le périmètre de récupération avant l’écriture vers la destination.
Constructeur RAID — lorsque les métadonnées du superbloc sont endommagées
Si la détection automatique ne donne aucun résultat — parce que les superblocs sont partiellement écrasés, corrompus à la suite d’un événement de firmware ou absents en raison d’un disque en échec partiellement réécrit pendant la reconstruction — basculez vers le Constructeur RAID. Ce mode permet de renseigner manuellement tous les paramètres du volume RAID, en contournant totalement le superbloc.
Commencez par déterminer l’offset du système de fichiers à l’aide de l’éditeur HEX intégré. Ouvrez chaque disque ou image dans l’éditeur HEX et recherchez la chaîne ASCII LABLEONE. Dans les configurations SHR et SHR-2, cette chaîne marque le début de la zone de données du volume. Le secteur immédiatement précédant le secteur LABLEONE — qui sera rempli de zéros — correspond au secteur d’offset. Notez son numéro : c’est la valeur à saisir dans le paramètre Offset du Constructeur RAID.
Renseignez les paramètres suivants dans le Constructeur RAID :
| Paramètre | Valeur pour SHR-1 | Valeur pour SHR-2 |
|---|---|---|
| Type de RAID | RAID 5 | RAID 6 / Left synchronous (P+Q) |
| Taille de bloc | 64 KB | 64 KB |
| Octets par secteur | 512 | 512 |
| Ordre des disques | Correspondre à la séquence d’origine des baies du NAS — baie 1 en premier | |
| Offset | Numéro de secteur trouvé via la recherche de LABLEONE (par disque) | |
Si l’ordre d’origine des disques est inconnu, déterminez-le par essais successifs : ajoutez les disques à la liste Disques sélectionnés selon différentes séquences et observez, après chaque modification, l’arborescence du système de fichiers reconstruit. Un ordre correct affiche une structure de répertoires reconnaissable ; un ordre incorrect produit des données incohérentes ou un arbre vide. La valeur d’offset doit être définie individuellement pour chaque disque physique ou image — elle peut différer d’un membre à l’autre si les disques avaient des capacités différentes dans la configuration SHR d’origine.
Si l’un des disques en échec ne peut pas être connecté du tout — panne mécanique, non détecté — utilisez Ajouter un disque vide pour insérer un emplacement fictif à la position correcte dans la liste des disques. RS RAID Retrieve traite cet emplacement fictif comme un membre totalement illisible : les bandes dont ce disque faisait partie sont reconstruites à partir de la parité à l’aide des autres membres (ce qui permet de récupérer les données de ces bandes), et les bandes pour lesquelles la contribution de parité de cet emplacement est également nécessaire sont signalées comme irrécupérables. Il s’agit du niveau maximal de récupération possible pour une configuration comportant un disque physiquement inaccessible.
Analyse du système de fichiers et récupération sélective des fichiers
Une fois l’ensemble RAID reconstruit — automatiquement ou via RAID Constructor — RS RAID Retrieve analyse le système de fichiers Btrfs ou ext4 présent sur le volume logique. L’analyse parcourt l’arborescence du système de fichiers, identifie les zones intactes et endommagées, puis génère une liste complète des répertoires. Les fichiers et dossiers dont les blocs de données intersectent des bandes irrécupérables sont signalés avant le début de la copie : aucune tentative de copie à l’aveugle n’est nécessaire pour déterminer ce qui est accessible.
Sélectionnez les fichiers et dossiers à récupérer, définissez une destination sur un autre disque disposant de suffisamment d’espace libre, puis lancez la copie. Les disques sources et les images disque sont accessibles en lecture seule pendant toute l’opération. Pour en savoir plus sur la couche LVM située entre l’ensemble mdadm et le système de fichiers, consultez notre article sur la structure et le fonctionnement de LVM.
La récupération de données logicielle — à quelque niveau que ce soit — dépend de la capacité des têtes de lecture/écriture du disque à transmettre les données des secteurs au contrôleur hôte. Lorsque le bloc de têtes est mécaniquement endommagé, que l’actionneur à bobine mobile est grippé ou que le roulement de broche est défaillant, le disque ne peut pas répondre aux requêtes de lecture, quelle que soit la configuration logicielle. Un laboratoire remplace le bloc de têtes en salle blanche (ISO classe 5 ou mieux), ajuste l’alignement des têtes en fonction du plateau concerné et utilise des outils au niveau du micrologiciel pour extraire les données sectorielles des zones que l’électronique du disque refuserait elle-même de lire.
Le résultat d’une intervention en laboratoire est un ensemble d’images disque au niveau des secteurs — une par disque. Ces images contiennent la meilleure lecture possible de chaque surface de disque, y compris les secteurs récupérés dans des zones physiquement endommagées qui génèrent des erreurs d’E/S en conditions normales. Une fois reçues, ces images sont utilisées directement dans RS RAID Retrieve : RAID Constructor lit les superblocs (ou utilise la méthode de décalage LABLEONE si les superblocs sont endommagés), reconstruit la topologie du tableau SHR, puis poursuit l’analyse du système de fichiers et la récupération exactement comme décrit au niveau 2.
La limitation de parité en cas de double panne s’applique aux images de laboratoire de la même manière qu’aux disques physiquement connectés : les bandes impliquant les deux membres défaillants restent mathématiquement irrécupérables, quelle que soit la qualité de l’extraction des données sectorielles. L’apport du laboratoire consiste à accéder à des secteurs qu’un outil logiciel exécuté sur un disque dégradé en fonctionnement aurait ignorés en raison d’erreurs de lecture, ce qui peut augmenter de manière significative la proportion de fichiers récupérables.
Pour une vue d’ensemble plus large des cas dans lesquels une récupération de données professionnelle est recommandée et des étapes qu’elle implique, consultez notre article sur la récupération de données sur disques durs en panne.
Passez directement au niveau 3 si vous observez l’un des symptômes suivants
- Cliquement, bruit de grincement ou bourdonnement émis par un disque au démarrage
- Disque non détecté dans le BIOS/UEFI ni dans la sortie de
lsblk - Disque détecté, mais
mdadm --examinerenvoie des erreurs d’E/S au lieu des données du superbloc - La température de surface du disque augmente à des niveaux anormaux en quelques minutes après la connexion
- Le nombre S.M.A.R.T. de secteurs réalloués (ID 05) se compte par centaines, ou le nombre de tentatives de rotation (Spin Retry Count, ID C0) augmente à chaque cycle d’alimentation
N’effectuez aucune tentative de récupération logicielle sur un disque présentant une défaillance mécanique. Chaque passe de lecture accroît l’usure des surfaces des têtes de lecture/écriture et des plateaux déjà endommagés. Mettez l’équipement hors tension et contactez un laboratoire avant toute autre tentative d’accès.
Une double défaillance en SHR-1 se situe à la frontière entre la récupération logicielle et la récupération physique. La position exacte de cette frontière dans votre cas dépend de l’état des disques, et non des capacités des outils. Deux disques physiquement intacts avec des superblocs intacts offrent à la récupération logicielle une véritable possibilité de récupération partielle. Deux disques en défaillance mécanique doivent être pris en charge directement par un laboratoire de récupération de données. Dans la pratique, la plupart des doubles défaillances se situent entre ces deux extrêmes — d’où l’importance, ici plus que dans tout autre scénario de cette série, d’évaluer l’état des disques avant de choisir une stratégie de récupération de données.
