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

Synology a une version personnalisée du pilote md et des jeux d'outils mdadm qui ajoute un indicateur «DriveError» à la structure des indicateurs rdev-> dans le noyau.

Effet net - si vous avez la malchance d'obtenir une panne de baie (premier disque), combinée à une erreur sur un deuxième disque - la baie se met dans l'état de ne pas vous laisser réparer / reconstruire la baie même si les lectures du disque fonctionnent bien.

À ce stade, je ne suis pas vraiment préoccupé par cette question du point de vue de CE tableau, car j'ai déjà retiré du contenu et j'ai l'intention de reconstruire, mais plus parce que je veux avoir un chemin de résolution pour cela à l'avenir , puisque c'est la deuxième fois que j'y suis mordu, et je sais que j'en ai vu d'autres poser des questions similaires dans les forums.

Le support de Synology a été moins qu'utile (et surtout non réactif), et ne partagera AUCUNE information sur la gestion des ensembles de raids sur la boîte.

Contenu de / proc / mdstat:

ds1512-ent> cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] 
md2 : active raid5 sdb5[1] sda5[5](S) sde5[4](E) sdd5[3] sdc5[2]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUE]

md1 : active raid1 sdb2[1] sdd2[3] sdc2[2] sde2[4] sda2[0]
      2097088 blocks [5/5] [UUUUU]

md0 : active raid1 sdb1[1] sdd1[3] sdc1[2] sde1[4] sda1[0]
      2490176 blocks [5/5] [UUUUU]

unused devices: <none>

État d'un mdadm --detail / dev / md2:

/dev/md2:
        Version : 1.2
  Creation Time : Tue Aug  7 18:51:30 2012
     Raid Level : raid5
     Array Size : 11702126592 (11160.02 GiB 11982.98 GB)
  Used Dev Size : 2925531648 (2790.00 GiB 2995.74 GB)
   Raid Devices : 5
  Total Devices : 5
    Persistence : Superblock is persistent

    Update Time : Fri Jan 17 20:48:12 2014
          State : clean, degraded
 Active Devices : 4
Working Devices : 5
 Failed Devices : 0
  Spare Devices : 1

         Layout : left-symmetric
     Chunk Size : 64K

           Name : MyStorage:2
           UUID : cbfdc4d8:3b78a6dd:49991e1a:2c2dc81f
         Events : 427234

    Number   Major   Minor   RaidDevice State
       0       0        0        0      removed
       1       8       21        1      active sync   /dev/sdb5
       2       8       37        2      active sync   /dev/sdc5
       3       8       53        3      active sync   /dev/sdd5
       4       8       69        4      active sync   /dev/sde5

       5       8        5        -      spare   /dev/sda5

Comme vous pouvez le voir - / dev / sda5 a été rajouté au tableau. (C'est le lecteur qui a carrément échoué) - mais même si md considère le lecteur comme un disque de rechange, il ne le reconstruira pas. / dev / sde5 dans ce cas est le lecteur à problème avec l'état (E) DiskError.

J'ai essayé d'arrêter le périphérique md, d'exécuter la force de réassemblage, de supprimer / lire le sda5 du périphérique / etc. Aucun changement de comportement.

J'ai pu recréer complètement le tableau avec la commande suivante:

mdadm --stop /dev/md2
mdadm --verbose \
   --create /dev/md2 --chunk=64 --level=5 \
   --raid-devices=5 missing /dev/sdb5 /dev/sdc5 /dev/sdd5 /dev/sde5

ce qui a ramené le tableau à cet état:

md2 : active raid5 sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]

J'ai ensuite rajouté / dev / sda5:

mdadm --manage /dev/md2 --add /dev/sda5

après quoi il a commencé une reconstruction:

md2 : active raid5 sda5[5] sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
      [>....................]  recovery =  0.1% (4569508/2925531648) finish=908.3min speed=53595K/sec

Notez la position du lecteur «manquant» correspondant à la position exacte de l'emplacement manquant.

Une fois cela terminé, je pense que je vais probablement tirer le lecteur douteux et le faire reconstruire à nouveau.

Je recherche des suggestions pour savoir s'il existe un moyen "moins effrayant" d'effectuer cette réparation - ou si quelqu'un a vécu cette expérience avec un tableau Synology et sait comment le forcer à reconstruire autre que de déconnecter le périphérique md et recréer le tableau à partir de zéro.

Juste un ajout à la solution que j'ai trouvée après avoir rencontré le même problème. J'ai suivi le billet de blog de dSebastien sur la façon de recréer le tableau:

J'ai trouvé que cette méthode de recréation du tableau fonctionnait mieux que cette méthode ci-dessus. Cependant, après avoir recréé la baie, le volume n'était toujours pas affiché sur l'interface Web. Aucun de mes LUN n'était visible. Fondamentalement, montrant un nouveau tableau sans rien configuré. J'ai contacté le support de Synology et ils se sont éloignés pour résoudre le problème. Malheureusement, ils se sont éloignés pendant que j'étais loin de la console. J'ai quand même réussi à capturer la session et j'ai regardé à travers ce qu'ils ont fait. Alors que j'essayais de récupérer certaines de mes données, le lecteur s'est de nouveau écrasé et j'étais de retour dans la même situation. J'ai recréé le tableau comme dans le blog de dSebastien, puis j'ai parcouru la session de synologie pour effectuer leur mise à jour. Après avoir exécuté les commandes ci-dessous, ma baie et mes LUN sont apparus sur l'interface Web, et j'ai pu travailler avec eux. Je n'ai pratiquement aucune expérience sous Linux, mais ce sont les commandes que j'ai effectuées dans ma situation. J'espère que cela peut aider quelqu'un d'autre, mais utilisez-le à vos risques et périls. Il serait préférable de contacter le support Synology et de le faire réparer pour vous, car cette situation peut être différente de la vôtre

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass 

DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()

DiskStation> spacetool --synoblock-enum
****** Syno-Block of /dev/sda ******
//I've removed the output. This should display info about each disk in your array

DiskStation> vgchange -ay
  # logical volume(s) in volume group "vg1" now active

DiskStation> dd if=/dev/vg1/syno_vg_reserved_area of=/root/reserved_area.img
24576+0 records in
24576+0 records out

DiskStation> synospace --map_file -d
Success to dump space info into '/etc/space,/tmp/space'

DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Not Pass, # conflict 

DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass 

Autre ajout: j'ai rencontré un problème très similaire avec mon périphérique monodisque / RAID niveau 0.

Le support de Synology a été très utile et a restauré mon appareil. Voici ce qui s'est passé, j'espère que cela aide les autres:

Mon disque avait des erreurs de lecture sur un bloc particulier, les messages dans le journal système ( dmesg) étaient:

[4421039.097278] ata1.00: read unc at 105370360
[4421039.101579] lba 105370360 start 9437184 end 5860528064
[4421039.106917] sda3 auto_remap 0
[4421039.110097] ata1.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6
[4421039.116744] ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
[4421039.125410] ata1.00: failed command: READ FPDMA QUEUED
[4421039.130767] ata1.00: cmd 60/00:08:b8:d2:47/02:00:06:00:00/40 tag 1 ncq 262144 in
[4421039.130772]          res 41/40:00:f8:d2:47/00:00:06:00:00/40 Emask 0x409 (media error) <F>
[4421039.146855] ata1.00: status: { DRDY ERR }
[4421039.151064] ata1.00: error: { UNC }
[4421039.154758] ata1: hard resetting link
[4421039.667234] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[4421039.887286] ata1.00: configured for UDMA/133
[4421039.891777] ata1: UNC RTF LBA Restored
[4421039.895745] ata1: EH complete

Quelques secondes plus tard, j'ai reçu le terrible Volume 1 has crashedcourrier de mon appareil.

- Avertissement: assurez-vous de remplacer le nom de l'appareil par le vôtre et ne copiez et collez pas simplement ces commandes, car cela pourrait aggraver les choses! -

Après avoir arrêté smb, j'ai pu remonter la partition en lecture seule et exécuter e2fsk avec badblocks check ( -c):

umount /dev/md2
e2fsck -C 0 -v -f -c /dev/md2

(on pourrait également utiliser e2fsck -C 0 -p -v -f -c /dev/md2pour fonctionner aussi sans surveillance que possible, bien que cela n'ait pas fonctionné dans mon cas, car les erreurs devaient être corrigées manuellement. J'ai donc dû redémarrer e2fsck. Conclusio: -p n'a pas beaucoup de sens dans cas d'erreur disque)

Bien que e2fsck ait pu corriger les erreurs et que smartctl n'ait plus montré d'augmentation de Raw_Read_Error_Rate, le volume ne montait toujours pas en mode lecture-écriture par le périphérique. DSM montre toujours "le volume s'est écrasé"

J'ai donc ouvert un ticket avec support. Il a fallu un certain temps pour que les choses commencent, mais à la fin ils l'ont corrigé en reconstruisant la matrice RAID avec:

synospace --stop-all-spaces
syno_poweroff_task -d 
mdadm -Sf /dev/md2
mdadm -AfR /dev/md2 /dev/sda3

Assurez-vous de vérifier les noms de vos appareils ( /dev/mdXet /dev/sdaX) avant de faire quoi que ce soit. cat /proc/mdstataffichera les informations pertinentes.