mdadm raid5 récupère l'échec du double disque - avec une torsion (ordre des lecteurs)

Permettez-moi de reconnaître tout d'abord que j'ai fait des erreurs et que j'ai une sauvegarde pour la plupart mais pas toutes les données de ce RAID. J'ai toujours l'espoir de récupérer le reste des données. Je n'ai pas le genre d'argent pour amener les disques à une entreprise experte en récupération.

Erreur # 0, ne pas avoir de sauvegarde à 100%. Je sais.

J'ai un mdadmsystème RAID5 de 4x3TB. Drives / dev / sd [be], le tout avec une seule partition /dev/sd[b-e]1. Je suis conscient que RAID5 sur de très gros disques est risqué, mais je l'ai quand même fait.

Événements récents

Le RAID se dégrade après une panne de deux disques. Un lecteur [/ dev / sdc] a vraiment disparu, l'autre [/ dev / sde] est revenu après un cycle d'alimentation, mais n'a pas été automatiquement ajouté au RAID. Je me suis donc retrouvé avec un RAID à 4 périphériques avec seulement 2 disques actifs [/ dev / sdb et / dev / sdd].

Erreur # 1, ne pas utiliser de copies dd des disques pour restaurer le RAID. Je n'avais ni les lecteurs ni le temps. Erreur # 2, ne pas faire de sauvegarde du superbloc et mdadm -Edes disques restants.

Tentative de récupération

J'ai remonté le RAID en mode dégradé avec

mdadm --assemble --force /dev/md0, using /dev/sd[bde]1.

Je pouvais alors accéder à mes données. J'ai remplacé /dev/sdcpar une pièce de rechange; vide; lecteur identique.

J'ai retiré l'ancien /dev/sdc1du RAID

mdadm --fail /dev/md0 /dev/sdc1

Erreur # 3, ne pas faire cela avant de remplacer le lecteur

J'ai ensuite partitionné le nouveau /dev/sdcet l' ai ajouté au RAID.

mdadm --add /dev/md0 /dev/sdc1

Il a alors commencé à restaurer le RAID. ETA 300 min. J'ai suivi le processus /proc/mdstatjusqu'à 2%, puis je suis allé faire d'autres choses.

Vérification du résultat

Plusieurs heures (mais moins de 300 minutes) plus tard, j'ai vérifié le processus. Il s'était arrêté en raison d'une erreur de lecture sur /dev/sde1.

Voici où les ennuis commencent vraiment

J'ai ensuite retiré /dev/sde1du RAID et l' ai rajouté. Je ne me souviens pas pourquoi j'ai fait ça; il était tard.

mdadm --manage /dev/md0 --remove /dev/sde1
mdadm --manage /dev/md0 --add /dev/sde1

Cependant, /dev/sde1était désormais marqué comme de rechange. J'ai donc décidé de recréer l'ensemble du tableau en utilisant --assume-clean en utilisant ce que je pensais être le bon ordre, et avec /dev/sdc1manquant.

mdadm --create /dev/md0 --assume-clean -l5 -n4 /dev/sdb1 missing /dev/sdd1 /dev/sde1

Cela a fonctionné, mais le système de fichiers n'a pas été reconnu lors de la tentative de montage. (Cela aurait dû être EXT4).

Ordre des appareils

J'ai ensuite vérifié une sauvegarde récente que j'avais /proc/mdstat, et j'ai trouvé l'ordre du lecteur.

md0 : active raid5 sdb1[0] sde1[4] sdd1[2] sdc1[1]
      8790402048 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]

Je me suis alors souvenu que ce RAID avait subi une perte de disque il y a environ un an, et je m'en suis remis en remplaçant le disque défectueux par un disque de rechange. Cela a peut-être un peu brouillé l'ordre des périphériques ... il n'y avait donc pas de lecteur [3] mais seulement [0], [1], [2] et [4].

J'ai essayé de trouver l'ordre du lecteur avec le script Permute_array: https://raid.wiki.kernel.org/index.php/Permute_array.pl mais cela n'a pas trouvé l'ordre approprié .

Des questions

J'ai maintenant deux questions principales:

1. J'ai foutu tous les superblocs sur les disques, mais j'ai seulement donné:

   mdadm --create --assume-clean
   

   commandes (donc je n'aurais pas dû écraser les données elles-mêmes /dev/sd[bde]1. Ai-je raison qu'en théorie le RAID peut être restauré [en supposant un instant que ce /dev/sde1soit ok] si je trouve juste le bon ordre de périphérique?

2. Est-il important de /dev/sde1donner le numéro de périphérique [4] dans le RAID? Quand je le crée avec

   mdadm --create /dev/md0 --assume-clean -l5 -n4 \
     /dev/sdb1 missing /dev/sdd1 /dev/sde1
   

   on lui attribue le numéro [3]. Je me demande si cela est pertinent pour le calcul des blocs de parité. Si cela s'avère important, comment puis-je recréer le tableau avec /dev/sdb1[0][1] manquant /dev/sdd1[2] /dev/sde1[4]? Si je pouvais faire fonctionner cela, je pourrais le démarrer en mode dégradé et ajouter le nouveau lecteur /dev/sdc1et le laisser se resynchroniser à nouveau.

Ce n'est pas grave si vous souhaitez me faire remarquer que ce n'était peut-être pas la meilleure solution, mais vous constaterez que je m'en suis rendu compte. Ce serait génial si quelqu'un avait des suggestions.

Pour répondre à vos questions,

1. Peut-il être restauré?

   • La première chose est la première - STOP, asseyez-vous et réfléchissez un peu. Oui, l'algorithme, la taille des morceaux et l'ordre des disques sont essentiels pour que le système de fichiers qui était présent soit correctement réassemblé. Mais puisque vous avez remplacé les superblocs, vous vous retrouvez maintenant avec des essais et des erreurs.
   • Deuxièmement, existe-t-il un moyen de récupérer la disposition de disque précédente? Je fais toujours un mdadm --detail> backupfile juste pour garder cette disposition de disque quelque part en sécurité. Vérifiez dmesg, / var / log pour toute preuve de la configuration des disques dans le raid.
   • Enfin, si vous correspondez à la taille de bloc et à l'ordre de disque précédents, vous avez peut-être endommagé le superbloc ext4 - il existe des moyens de rechercher astucieusement d'autres superblocs (et il existe un programme astucieux appelé TestDisk qui recherche les superblocs des systèmes de fichiers existants et essaie de les parcourir). manuellement: http://www.cgsecurity.org/wiki/Main_Page )

2. Puisque sdc est nouveau, je continuerais d'essayer de l'assembler manuellement via la clause manquante, et oui, sde doit être dans le bon ordre pour qu'il s'assemble en mode dégradé. Une fois que vous avez trouvé la mise en page correcte - copiez toutes les données du tableau et recommencez, en documentant la mise en page (afin de ne plus rencontrer ce problème).

Bonne chance

Avant de faire quoi que ce soit d'autre, capturez un «mdadm --examine / dev / sdX1» pour chacun des lecteurs qui ÉTAIENT dans votre baie, et un «mdadm --detail / dev / md0» à partir de cela, vous devriez pouvoir déterminer la disposition exacte.

Je devais juste le faire moi-même pour récupérer un tableau Synology dans une question distincte:

Comment récupérer une baie mdadm sur un Synology NAS avec un lecteur en état "E"?

Edit: Désolé, je viens de voir que vous avez dit que vous avez perdu les superblocs sur tous les disques.

Vos commandes ultérieures semblent correctes. L'option la plus simple pourrait être d'exécuter les créations avec chaque commande possible, puis de voir si vous pouvez monter et accéder au système de fichiers en lecture seule.

Cette question est ancienne et je suis sûr que personne ne peut vous aider maintenant, mais pour les autres qui lisent:

l'erreur la plus dangereuse que vous avez commise n'est pas celle que vous avez numérotée, qui devait s'exécuter:

mdadm --create ...

sur les disques d'origine, avant de vous préparer à savoir quoi faire. Cela a écrasé les métadonnées, vous n'avez donc aucun enregistrement de l'ordre du lecteur, du décalage des données, de la taille des morceaux, etc.

Pour récupérer de cela, vous devez les remplacer à nouveau avec les valeurs correctes. La façon la plus simple de le savoir est de regarder les métadonnées, mais vous les avez déjà détruites. La prochaine façon est de deviner. Devinez les différentes combinaisons d'une commande comme celle-ci, avec des valeurs différentes pour chacune des options, sauf ce que vous savez (4 appareils, niveau 5), et également un ordre de disque différent:

mdadm --create /dev/md0 --assume-clean --metadata=1.2 --raid-devices=4 --level=5 --layout=... --chunk=512 --data-offset=128M /dev/sdb1 missing /dev/sdd1 /dev/sde1

Mais puisque vous ne connaissez PAS le résultat correct, encore une fois, vous ne devriez pas l'exécuter sur les anciens disques en les détruisant davantage, faisant la même erreur fatale. Utilisez plutôt une superposition; par exemple, cette procédure devrait fonctionner pour protéger les originaux.

Une fois que vous avez trouvé des arguments qui produisent un tableau fonctionnel que vous pouvez fsck ou monter et vérifier (par exemple, vérifiez la somme de contrôle d'un fichier suffisamment grand pour couvrir tous les membres du raid comme une iso que vous devriez avoir stockée avec sa somme de contrôle / pgp signature, ou décompressez -t ou gunzip -ta grande archive)