Comment récupérer des données d’un NAS Synology après une défaillance survenue lors de la migration de RAID 1 vers RAID 5 ?
-
Auteur:
Abdelhamid Balti
-
Éditeur:
Mykhailo Miroshnychenko
Imaginez que vous ajoutiez un disque à un NAS Synology et que vous lanciez une migration de RAID 1 vers RAID 5 afin d’augmenter la capacité de stockage. Mais pendant la reconstruction, l’alimentation est soudainement coupée et le NAS s’éteint. Après le rétablissement du courant, il s’avère que l’un des disques d’origine n’est plus détecté et qu’aucun accès aux fichiers n’est possible. Que faire s’il n’existe pas de sauvegarde à jour des données requises ? Peut-on récupérer les fichiers à partir des deux disques survivants lorsque la migration vers le nouveau niveau de RAID n’a jamais été achevée ?
- ÉTAPE 1. Environnement de test
- ÉTAPE 2. Connexion des disques à un ordinateur Windows
- ÉTAPE 3. Résultats de l’analyse du RAID 5
- ÉTAPE 4. Reconstruction manuelle du RAID
- ÉTAPE 5. Détermination du décalage de début des données
- ÉTAPE 6. Détection automatique des paramètres RAID
- ÉTAPE 7. Recherche de données dans la configuration RAID 1 d’origine
- Conclusion
- Questions fréquemment posées
- Commentaires
La migration d’un ensemble sur un NAS Synology de RAID 1 vers RAID 5 s’achève généralement sans perte de données. Cependant, une panne d’alimentation, des erreurs de disque ou une interruption du processus peuvent entraîner une dégradation du stockage ou une indisponibilité totale. Dans une telle situation, l’essentiel est d’éviter toute action précipitée susceptible de compliquer la récupération. Dans cet article, nous examinerons comment évaluer correctement l’état d’un ensemble RAID Synology après une migration d’urgence et quelles méthodes peuvent aider à restaurer l’accès aux données.
Récupération de données d'un NAS Synology après l'échec d'une migration RAID 1 → RAID 5
ÉTAPE 1. Environnement de test
Pour le test, nous avons utilisé un périphérique de stockage réseau Synology DS409 fonctionnant sous DSM 4.2 et trois disques durs d’une capacité de 320 gigaoctets chacun.
Au départ, deux disques ont été combinés en RAID 1 — un ensemble en miroir dans lequel les données étaient dupliquées sur les deux disques. Un volume avec le système de fichiers Ext4 a été créé dessus, et environ 110 gigaoctets de données de test y ont été écrits : documents, photos, vidéos et archives. Les fichiers ont été placés dans des répertoires comportant plusieurs niveaux d’imbrication afin que nous puissions ensuite vérifier la préservation à la fois du contenu et de la structure des dossiers.
Le troisième disque a ensuite été ajouté à l’ensemble, et Storage Manager a été utilisé pour lancer le changement de niveau de RAID de RAID 1 vers RAID 5.
Cette migration permet d’augmenter la capacité de stockage disponible tout en conservant la protection contre la défaillance d’un seul disque après la réussite de l’opération.
Lorsque l’indicateur de reconstruction a affiché 29,55 %, l’alimentation du NAS a été volontairement coupée sans arrêt correct. Ensuite, l’un des deux disques RAID 1 d’origine a été retiré, simulant une indisponibilité totale.
En conséquence, deux disques sont restés disponibles pour la récupération : un disque du miroir d’origine et le troisième disque ajouté pour la transition vers RAID 5. La reconstruction n’ayant pas été terminée, une partie des données avait déjà été déplacée, tandis que le reste était encore stocké selon le schéma précédent. Ces deux disques seront utilisés pour les étapes suivantes.
ÉTAPE 2. Connexion des disques à un ordinateur Windows
Nous passons à un ordinateur Windows sur lequel Hetman RAID Recovery est installé.
Nous connectons les deux disques survivants via une station d’accueil USB :
- l’un des disques RAID 1 d’origine ;
- le disque ajouté pour la transition vers RAID 5.
Le second membre du miroir d’origine n’est pas disponible dans notre test.
Nous lançons le programme. Dans la section RAID Arrays, nous voyons l’ensemble détecté automatiquement DiskStation:2.
Nous le sélectionnons et examinons les informations dans le panneau Preview à droite. Le programme a identifié le type RAID 5, l’ordre des blocs Left Synchronous et une taille de bloc de 64 kilo-octets.
En dessous, dans la liste RAID Disks, nous voyons deux disques connectés et une position Empty disk correspondant au membre manquant. Pour les deux disques disponibles, le même décalage de début des données est indiqué — nous reviendrons sur ce paramètre lors de la reconstruction manuelle.
La liste contient également deux petits ensembles RAID 1 d’environ 2,37 et 2 gigaoctets. Ils correspondent aux zones système de Synology.
Ces ensembles ne doivent pas être confondus avec le miroir d’origine qui contenait nos fichiers de test.
Le RAID 1 d’origine contenant les données utilisateur n’est plus affiché séparément.
ÉTAPE 3. Résultats de l’analyse du RAID 5
Vérifions ce qui est disponible via la configuration RAID 5 détectée automatiquement. Pour cela, ouvrez le volume Ext4 de cet ensemble en double-cliquant dessus. Dans l’assistant d’analyse, sélectionnez Fast scan et cliquez sur Next pour lancer la recherche de fichiers.
La portion disponible des données de test : après l’analyse du RAID 5, le programme a trouvé 390 dossiers et 8 239 fichiers. Dans les résultats, nous pouvons voir le dossier My Data et des répertoires imbriqués contenant des fichiers de test. Une partie de la structure d’origine a été conservée : le programme affiche les noms des dossiers et des fichiers ainsi que leur emplacement.
Ainsi, même avec deux membres disponibles de l’ensemble interrompu, une partie de son contenu peut être lue. Pour enregistrer les fichiers nécessaires, sélectionnez-les, cliquez sur Recovery et indiquez un dossier sur un autre disque qui ne fait pas partie de l’ensemble en cours de récupération afin d’éviter l’écrasement des données source.
Cependant, tous les fichiers écrits avant le test ne figurent pas dans les résultats. Avant la migration, les données étaient stockées sur deux disques sous forme de copies en miroir. Pendant la transition vers RAID 5, le système a progressivement modifié la disposition des blocs, en la répartissant sur trois disques et en créant une parité.
En conséquence, des zones avec une organisation différente des données sont restées sur les disques survivants. La disposition RAID 5 correspond au placement des blocs dans les zones déjà reconstruites, tandis que l’organisation RAID 1 précédente demeure dans le reste, bien que le miroir lui-même ne soit plus détecté automatiquement.
Par conséquent, l’absence d’un fichier dans ces résultats ne prouve pas encore que son contenu est complètement perdu.
ÉTAPE 4. Reconstruction manuelle du RAID
Dans notre cas, le programme a automatiquement identifié RAID 5 et ses paramètres. Mais que faire si la configuration doit être définie manuellement ou si certains paramètres sont inconnus ? À cette fin, Hetman RAID Recovery inclut le RAID Constructor. En prenant comme exemple le RAID 5 détecté, examinons ses capacités, puis utilisons cet outil pour reconstruire le RAID 1 d’origine.
Nous ouvrons le RAID Constructor, sélectionnons RAID 5 et ajoutons les deux disques disponibles. Le membre manquant est marqué comme Empty disk. Cela nous donne trois positions correspondant à la composition de l’ensemble pendant la migration.
Dans les configurations RAID 5 que nous avons testées sur Synology, l’ordre des blocs Left Synchronous et une taille de bloc de 64 kilo-octets sont souvent rencontrés ; nous utiliserons donc cette combinaison dans le constructeur. Dans notre cas, elle correspond également aux paramètres de l’ensemble détecté automatiquement.
Cependant, ces valeurs ne sont pas universelles : pour un autre jeu de disques ou un autre périphérique de stockage, elles doivent être vérifiées séparément, en tenant compte de la configuration de l’ensemble et de l’historique des modifications.
Il est également nécessaire d’indiquer séparément le décalage de début des données pour chaque disque ; nous allons donc d’abord examiner où le trouver et comment le calculer.
ÉTAPE 5. Détermination du décalage de début des données
Le décalage indique quelle portion initiale du disque doit être ignorée avant la lecture des blocs de l’ensemble utilisateur. Sur le schéma du disque physique, nous pouvons voir les partitions système Synology et la partition utilisée pour stocker nos fichiers. Dans ce test, elle commence au secteur 9 437 184. C’est notre point de référence. Les données RAID elles-mêmes commencent légèrement plus tard, car un espace est réservé aux informations système au début de la partition.
Nous ouvrons le disque physique dans HEX Editor. Pour accéder au début de la partition requise, convertissez d’abord son secteur de départ en adresse binaire. Sur la calculatrice, multipliez 9 437 184 par la taille du secteur — 512 octets. Le résultat est 4 831 838 208 octets. Convertissez le résultat en hexadécimal et allez à cette adresse dans l’éditeur.
Depuis la position actuelle, lancez une recherche vers l’avant. Sélectionnez la recherche hexadécimale et saisissez la signature FC 4E 2B A9. Cela nous permet d’ignorer les partitions système Synology initiales et de rechercher le superbloc EXT dans la partition contenant nos fichiers.
La correspondance requise est trouvée à l’adresse 120001000. À proximité, dans la partie texte de l’éditeur, nous pouvons voir le nom DiskStation:2. La signature seule ne suffit pas, car une telle séquence d’octets peut également apparaître dans d’autres données.
Recherchons maintenant le champ data_offset, qui indique le décalage de début des données RAID à l’intérieur de la partition. Dans ce format de superbloc, il se trouve à 128 octets du début et occupe huit octets. Dans notre cas, il s’agit des huit premiers octets de la ligne à l’adresse 120001080.
La valeur est stockée en ordre little-endian. En notation standard, ce nombre est 800 en format hexadécimal. Saisissez-le dans la calculatrice et passez en format décimal — le résultat est 2 048 secteurs. Il s’agit de la distance entre le début de la partition et le début des données RAID. Nous ajoutons donc 2 048 au secteur de départ de la partition. Nous obtenons 9 439 232 secteurs. En multipliant par 512 octets, le décalage final à partir du début du disque physique est de 4 832 886 784 octets. Cela correspond à la valeur indiquée dans les propriétés du RAID 5 détecté automatiquement.
ÉTAPE 6. Détection automatique des paramètres RAID
Nous revenons au RAID Constructor et spécifions le décalage déterminé pour chaque disque disponible. Nous pouvons maintenant utiliser la détection automatique des paramètres inconnus.
Si la taille de bloc ou l’ordre des blocs est inconnu, vous pouvez sélectionner Detect automatically dans les champs Block size et Block order. Pour déterminer l’ordre des membres, une option distincte Detect the disk order automatically est disponible. Par exemple, nous pouvons conserver RAID 5, Left Synchronous et une taille de bloc de 64 kilo-octets, mais laisser le programme déterminer l’ordre des disques.
Après être passé à l’étape suivante, le programme commence à rechercher les configurations correspondant aux conditions spécifiées. Les options trouvées s’affichent dans une liste. Sélectionnez la configuration requise et cliquez sur Add.
Ensuite, le RAID assemblé apparaîtra sur l’écran principal du programme, où il pourra être ouvert pour l’analyse et la recherche de fichiers.
Utilisons maintenant le constructeur pour une autre tâche — nous allons vérifier le disque survivant du miroir d’origine dans une configuration RAID 1.
ÉTAPE 7. Recherche de données dans la configuration RAID 1 d’origine
Nous revenons au RAID Constructor et sélectionnons RAID 1. Nous ajoutons le disque survivant du miroir d’origine et marquons le membre manquant comme Empty disk.
Nous spécifions le décalage de début des données vérifié. Cela indique au programme comment lire les données selon le schéma précédent. Il s’agit d’une reconstruction virtuelle à des fins d’analyse : elle ne rétablit pas la migration ni ne remet les disques dans leur état antérieur à l’incident.
Le RAID 1 assemblé apparaîtra sur l’écran principal du programme.
Nous l’ouvrons par double-clic et sélectionnons Full analysis dans l’assistant d’analyse. Indiquez le système de fichiers Ext4 et lancez l’analyse.
À la fin, le programme a trouvé 979 dossiers et 14 049 fichiers. À titre de comparaison, après le Fast scan de la configuration RAID 5, nous avons obtenu 390 dossiers et 8 239 fichiers. Ces chiffres n’indiquent pas le nombre de fichiers valides uniques : les résultats peuvent contenir des doublons et nécessitent une vérification.
Nous examinons les données trouvées. La structure de répertoires d’origine n’a pas été entièrement reconstruite, et certains objets trouvés se trouvent dans Lost and Found.
La restauration de l’arborescence des dossiers nécessite des structures de métadonnées du système de fichiers conservées ainsi que les relations entre elles. Après une migration interrompue, les données d’un fichier individuel peuvent être lisibles dans la configuration sélectionnée, tandis que les enregistrements qui le reliaient au répertoire d’origine peuvent ne plus être disponibles. Par conséquent, l’absence d’un dossier familier ne signifie pas nécessairement que tout son contenu est perdu.
Pour trouver plus rapidement les fichiers requis, utilisez la fonction Find File. Dans la fenêtre de recherche, saisissez le nom complet ou une partie de celui-ci et cliquez sur Find. Si nécessaire, vous pouvez activer la recherche sensible à la casse ou limiter la recherche aux correspondances exactes du mot entier.
Nous examinons plusieurs fichiers dans différents formats, y compris ceux trouvés par recherche. Dans la fenêtre Preview, nous vérifions les images, le contenu des documents et d’autres fichiers disponibles en aperçu. Cela permet d’identifier les données requises et d’évaluer leur contenu avant l’enregistrement.
Conclusion
Dans ce test, nous avons examiné la perte d’un disque après une migration Synology interrompue de RAID 1 vers RAID 5. Hetman RAID Recovery a détecté automatiquement RAID 5 à partir des métadonnées conservées, mais seule une partie des données d’origine était accessible via cette configuration.
Nous avons donc également analysé le disque survivant du miroir d’origine en tant que RAID 1. Dans les résultats, nous avons trouvé des fichiers dont le contenu peut être consulté, bien que la structure des répertoires n’ait pas été entièrement reconstruite.
Ce cas montre pourquoi, après une migration incomplète, il est important de tenir compte de la configuration antérieure de l’ensemble : ses métadonnées actuelles ne décrivent pas nécessairement l’emplacement de toutes les données sur les disques.
Une sauvegarde à jour simplifie considérablement la récupération après un incident. Si elle n’est pas disponible, l’analyse des données conservées peut permettre de récupérer au moins une partie des fichiers — c’est précisément le scénario que nous avons examiné ici.
