Restaura o volume RAID1 perdido no Synology com mdam

Question

Vários dias atrás eu encontrei meu DS412 + em estado fatal. Volume1 caiu, o volume do sistema também. Além disso, o Volume2 desapareceu do sistema! Parece que o Volume1 não tinha espaço livre e não pode transferir dados de alguns blocos ruins para um novo local e isso prejudica os dados do sistema. (é apenas uma teoria).

Consegui devolver o Volume1 à vida usando os procedimentos descritos aqui (%código%). BTW tem que mencionar o novo comando e2fsck, mdadm reassemble que simplifica o processo!

Depois, restaurei o volume do sistema usando o Synology GUI. Tudo começou a funcionar bem, exceto que não posso restaurar o Volume2. Era matriz RAID1 composta por dois discos do mesmo tamanho. Este é um extrato de syno_poweroff_task da data imediatamente anterior ao acidente:

<space path="/dev/md3" reference="/volume2" >
    <device>
        <raid path="/dev/md3" uuid="927afd83:*" level="raid1" version="1.2">
            <disks>
                <disk status="normal" dev_path="/dev/sdc3" model="WD30EFRX-68AX9N0        " serial="WD-*" partition_version="7" slot="1">
                </disk>
                <disk status="normal" dev_path="/dev/sdd3" model="WD30EFRX-68AX9N0        " serial="WD-*" partition_version="7" slot="0">
                </disk>
            </disks>
        </raid>
    </device>
    <reference>
        <volume path="/volume2" dev_path="/dev/md3">
        </volume>
    </reference>

Membros RAID (/ dev / sdc3 e / dev / sdd3) ainda estão em seus lugares, e parece que eles estão OK, pelo menos / dev / sdc3.

DiskStation> mdadm --misc --examine /dev/sdc3
/dev/sdc3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 600cff1e:0e27a96d:883007c3:610e73ef
           Name : DiskStation:3  (local to host DiskStation)
  Creation Time : Thu Mar 19 22:21:08 2015
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 5851088833 (2790.02 GiB 2995.76 GB)
     Array Size : 5851088512 (2790.02 GiB 2995.76 GB)
      Used Dev Size : 5851088512 (2790.02 GiB 2995.76 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : f0b910a0:1de7081f:dd65ec22:a2a16d58

    Update Time : Thu Mar 19 22:21:08 2015
       Checksum : a09b6690 - correct
         Events : 0

   Device Role : Active device 0
   Array State : A. ('A' == active, '.' == missing)

Eu tentei muitos truques com o mdadm, em muitas formas como esta:

mdadm -v --assemble /dev/md3 /dev/sdc3 /dev/sdd3
mdadm --verbose --create /dev/md3 --level=1 --raid-devices=2 /dev/sdc3 /dev/sdd3 --force
mdadm --verbose --create /dev/md3 --level=1 --raid-devices=2 /dev/sdc3 missing

Todos eles resultando em algo assim:

mdadm: ADD_NEW_DISK for /dev/sdc3 failed: Invalid argument

Existe alguma chance de restaurar o volume RAID? Ou há alguma chance de restaurar dados do volume? Por exemplo, montando / dev / sdc3 membro diretamente?

Mais informações sobre o mdadm:

DiskStation> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid1 sdb3[0]
      2925544256 blocks super 1.2 [1/1] [U]

md1 : active raid1 sdb2[0] sdc2[1]
      2097088 blocks [4/2] [UU__]

md0 : active raid1 sdb1[2] sdc1[0]
      2490176 blocks [4/2] [U_U_]

    

Answer 1

Eventualmente (depois de dias de exploração) consegui forçar o array a trabalhar e a copiar os dados.

Primeiro, a causa foi setores defeituosos do disco - suponho que na área de superbloco raid e / ou tabela de partições.

Em segundo lugar, eu tive que usar dmesg para ver erros durante mdadm --assemble ou mdadm --create :

 [Thu Mar 19 23:27:04 2015] end_request: I/O error, dev sdc, sector 9437194

Então eu dei os seguintes passos para me livrar da situação. Lembre-se de que não há garantia de que esse modo esteja correto em todos os detalhes e, provavelmente, o pode levar à perda de dados , mas isso me ajudou.

Setores ruins

Primeiro de tudo, eu cuido dos setores ruins do disco (não sei por que eles não foram automaticamente remapeados). E provavelmente isso causou alguns problemas com dados em outro disco para.

Verificados vários setores em torno da falha um:

hdparm --read-sector 9437191 /dev/sdc
...
hdparm --read-sector 9437195 /dev/sdc
....
hdparm --read-sector 9437199 /dev/sdc

E, em seguida, consertou os ruins:

hdparm --yes-i-know-what-i-am-doing --write-sector 9437198 /dev/sdc

Tabela de partição / dev / sdc

Em seguida, eu queria restaurar e verificar a tabela de partição sdc: usei testdisk , que não faz parte da distribuição padrão Synology, mas poderia ser instalado a partir de [Synocommunity repository][1] . Após a instalação, ele pode ser acessado pelo console por /usr/local/testdisk/bin/testdisk .

1. Selecione um disco e, em seguida, o mapa de partições [EFI GPT].
2. Analisar e pesquisa rápida. Encontrou várias partições.

TestDisk 7.0-WIP, Data Recovery Utility, January 2015
Christophe GRENIER 
http://www.cgsecurity.org

Disk /dev/sdc - 3000 GB / 2794 GiB - CHS 364801 255 63
     Partition               Start        End    Size in sectors
 D MS Data                      256    4980607    4980352 [1.41.10-2219]
 P Linux Raid                   256    4980735    4980480 [md0]
 D Linux Swap               4980736    9174895    4194160
>P Linux Raid               4980736    9175039    4194304 [md1]
 P Linux Raid               9437184 5860523271 5851086088 [DiskStation:3]

3. Marcado todas as partições do Linux Raid as P (primárias), o mercado restante como D (excluído). Escreva a tabela de partições.

Eventualmente - partprobe /dev/sdc para atualizar a tabela de partições do sistema (sem necessidade de reinicializar).

mdadm

Agora, tornou-se possível restaurar o superbloco de ataque.

mdadm --zero-superblock /dev/sdc3 

Isso me ajudou a limpar as informações antigas e provavelmente danificadas sobre o RAID Array. Eu acho que essa ação é perigosa em muitos casos.

mdadm --create /dev/md3 --verbose --assume-clean --metadata=1.2 --level=1 --raid-devices=2 /dev/sdc3 missing 

Mas no meu caso, ele restaurou um raid1 com 1 disco disponível e sem perda de dados.

Não sei qual foi o motivo, mas o tamanho do sistema de arquivos (ext4) no md3 foi ligeiramente diferente em comparação ao tamanho físico de md3. Então eu corro:

resize2fs /dev/md3

E verificação do sistema de arquivos:

fsck.ext4 -f -C 0 /dev/md3

E agora tornou-se possível montar o array:

mount -t ext4 -o ro /dev/sdc3 /volume2

Então eu copiei com sucesso todos os dados.