Como recuperar um array mdadm no Synology NAS com drive no estado “E”?

Question

A Synology tem uma versão personalizada do driver md e conjunto de ferramentas mdadm que adiciona um sinalizador 'DriveError' à estrutura de sinalizadores rdev- > no kernel.

Efeito líquido - se você tiver a infelicidade de obter uma falha de matriz (primeira unidade), combinada com um erro em uma segunda unidade - a matriz entra no estado de não permitir a reparação / reconstrução da matriz, embora as leituras do drive estão funcionando bem.

Neste ponto, eu não estou realmente preocupado com esta questão do ponto de vista da matriz THIS, já que eu já tirei o conteúdo e estou tentando reconstruir, mas mais de querer ter um caminho de resolução para este no futuro, já que é a segunda vez que fui mordido por ele, e sei que vi outros perguntando coisas semelhantes em fóruns.

O suporte da Synology foi menos do que útil (e principalmente não responsivo), e não compartilhará nenhuma informação sobre como lidar com os ataques na caixa.

Conteúdo 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>

Status de um 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

Como você pode ver - / dev / sda5 foi adicionado novamente à matriz. (Foi o disco que falhou completamente) - mas mesmo que o md veja o disco como um sobressalente, ele não irá reconstruí-lo. / dev / sde5 neste caso é o drive do problema com o estado (E) DiskError.

Eu tentei parar o dispositivo md, força de reagrupamento, remoção / leitura de sda5 do dispositivo / etc. Nenhuma mudança no comportamento.

Consegui recriar completamente o array com o seguinte comando:

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

que trouxe o array de volta a este estado:

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]

Depois, adicionei novamente / dev / sda5:

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

após o qual iniciou uma reconstrução:

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

Observe a posição da unidade "ausente" correspondente à posição exata do slot ausente.

Quando isso terminar, acho que provavelmente vou puxar a unidade questionável e fazer com que ela seja reconstruída novamente.

Estou procurando alguma sugestão para saber se existe uma maneira "menos assustadora" de fazer esse reparo - ou se alguém passou por essa experiência com um array Synology e sabe como forçá-lo a reconstruir além de usar o md dispositivo off-line e recriando a matriz do zero.

    

Answer 1

Apenas uma adição à solução que encontrei depois que experimentei o mesmo problema. Eu segui dSebastien

Descobri que esse método de recriar o array funcionou melhor do que o método acima. No entanto, após recriar a matriz, o volume ainda não estava sendo exibido na interface da web. Nenhum dos meus LUNs estava aparecendo. Basicamente mostrando uma nova matriz com nada configurado. Entrei em contato com o suporte da Synology e eles remeteram para corrigir o problema. Infelizmente, eles remotaram enquanto eu estava longe do console. Consegui capturar a sessão e analisei o que eles fizeram. Enquanto tentava recuperar alguns dos meus dados, a unidade caiu novamente, e eu estava de volta na mesma situação. Eu recriei o array como no blog do dSebastien e, em seguida, examinei a sessão de sinologia para executar sua atualização. Depois de executar os comandos abaixo, minha matriz e LUNs apareceram na interface da web e consegui trabalhar com eles. Eu tenho praticamente zero experiência em linux, mas estes foram os comandos que realizei na minha situação. Espero que isso possa ajudar alguém, mas por favor, use isso por sua conta e risco. Seria melhor entrar em contato com o suporte da Synology e fazê-los corrigir isso para você, pois essa situação pode ser diferente da sua

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 

    

Answer 2

Outra adição: acertei um problema muito parecido com o meu dispositivo de um disco / RAID nível 0.

O suporte Synology foi muito útil e restaurou o meu dispositivo. Veja o que aconteceu, espero que isso ajude os outros:

Meu disco tinha lido erros em um bloco em particular, as mensagens no log do sistema ( dmesg ) eram:

[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

Alguns segundos depois, recebi o terrível Volume 1 has crashed mail do meu dispositivo.

- Aviso: certifique-se de substituir o nome do dispositivo pelo seu e não copie e cole esses comandos, pois isso pode piorar as coisas! -

Após parar o smb, consegui montar novamente a partição somente leitura e executar o e2fsk com verificação de badblocks ( -c ):

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

(também é possível usar e2fsck -C 0 -p -v -f -c /dev/md2 para executar o mais desacompanhado possível, embora isso não funcione no meu caso, porque os erros tiveram que ser corrigidos manualmente. Então tive que reiniciar o e2fsck. Conclusio: -p doesn não faz muito sentido em caso de erro de disco)

Embora o e2fsck consiga corrigir os erros, o smartctl também não mostrou mais aumento em Raw_Read_Error_Rate, o volume ainda não seria montado no modo de leitura / gravação pelo dispositivo. O DSM ainda mostrou "volume com falha"

Então eu abri um ticket com suporte. Demorou um pouco para colocar as coisas em primeiro lugar, mas no final eles consertaram reconstruindo a matriz RAID com:

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

Verifique os nomes dos seus dispositivos ( /dev/mdX e /dev/sdaX ) antes de fazer qualquer coisa. cat /proc/mdstat mostrará as informações relevantes.