Ajudar a recuperar um array raid5

0

Um pouco de fundo primeiro. Eu armazeno um monte de dados em um array NAS Thecus N4200Pro. Eu tinha obtido um relatório que uma das 4 unidades na matriz estava mostrando erros inteligentes, então eu troquei a unidade ofensiva (# 4) e ele começou a trabalhar reconstrução. Cerca de 60% na reconstrução de uma das outras unidades na matriz cai, # 1 neste caso. Ótimo .. Eu desliguei e tentei trocar de volta no original # 4 para ver se ele voltaria. Sem dados. Então eu fecho e troco # 1 & # 2 para ver se ele pode se recuperar com a unidade ruim trocada e recolocar o # 4 com a metade reconstruída # 4. Em retrospecto, isso foi ruim. Eu deveria ter desligado após o primeiro e clonado todos os discos originais de lá. O dispositivo inicializa novamente e, claro, o ataque não é montado, mostrando apenas os discos 3 e 4, sendo marcados como sobressalentes. Neste ponto, eu fecho tudo e puxo todos os discos e clona-os, certificando-me de acompanhar a ordem dos números. Eu coloquei todos os 4 discos clonados na minha caixa de 16.04 LTS desatualizada na ordem correta de disco e inicializei. Todos os 4 discos aparecem e mostram as partições em Discos. Ele mostra um array raid5 e um array raid1 também. O array raid1 é a informação do sistema para o NAS, não está realmente preocupado com isso. O array raid5 é o que eu estou interessado em todos os meus dados, mas não consigo acessar nada nele. Então, hora de começar a cavar.

Primeiro eu corri cat /proc/mdstat para ver as matrizes-

jake@ubuntu-box:~$ cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] 
[raid10] 
md0 : active raid1 sdd1[3]
  1959884 blocks super 1.0 [4/1] [___U]

md1 : inactive sdd2[3](S) sdc2[2](S) sdb2[1](S) sda2[0](S)
  3899202560 blocks

unused devices: <none>

Ok, vê dois arrays. Então, nós obtemos os detalhes no md1 a partir de: mdadm --detail /dev/md1

jake@ubuntu-box:~$ sudo mdadm --detail /dev/md1
/dev/md1:
    Version : 0.90
 Raid Level : raid0
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent


      State : inactive


       UUID : e7ab07c3:b9ffa9ae:377e3cd3:a8ece374
     Events : 0.14344


Number   Major   Minor   RaidDevice


   -       8       50        -        /dev/sdd2
   -       8       34        -        /dev/sdc2
   -       8       18        -        /dev/sdb2
   -       8        2        -        /dev/sda2[/CODE]

Hrmm .. isso é estranho. mostrando o ataque como raid0, o que não é o caso. Ok, vamos verificar cada partição individual com: mdadm --examine /dev/sdXX

Disco 1

jake@ubuntu-box:~$ sudo mdadm --examine /dev/sda2/
dev/sda2:
      Magic : a92b4efc
    Version : 0.90.00
       UUID : e7ab07c3:b9ffa9ae:377e3cd3:a8ece374
 Creation Time : Thu Aug 18 14:30:36 2011
 Raid Level : raid5
 Used Dev Size : 974800000 (929.64 GiB 998.20 GB)
 Array Size : 2924400000 (2788.93 GiB 2994.59 GB)
 Raid Devices : 4
 Total Devices : 4
 Preferred Minor : 1


Update Time : Tue Mar 13 14:00:33 2018
      State : clean
Active Devices : 3
Working Devices : 4
Failed Devices : 1
Spare Devices : 1
   Checksum : e52c5f8 - correct
     Events : 20364


     Layout : left-symmetric
 Chunk Size : 64K


  Number   Major   Minor   RaidDevice State
this     0       8        2        0      active sync   /dev/sda2


0     0       8        2        0      active sync   /dev/sda2
1     1       8       18        1      active sync   /dev/sdb2
2     2       8       34        2      active sync   /dev/sdc2
3     3       0        0        3      faulty removed
4     4       8       50        4      spare   /dev/sdd2

Disco 2

jake@ubuntu-box:~$ sudo mdadm --examine /dev/sdb2/
dev/sdb2:
      Magic : a92b4efc
    Version : 0.90.00
       UUID : e7ab07c3:b9ffa9ae:377e3cd3:a8ece374
Creation Time : Thu Aug 18 14:30:36 2011
 Raid Level : raid5
Used Dev Size : 974800000 (929.64 GiB 998.20 GB)
 Array Size : 2924400000 (2788.93 GiB 2994.59 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1


Update Time : Tue Mar 13 14:56:30 2018
      State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 1
Spare Devices : 1
   Checksum : e597e42 - correct
     Events : 238868


     Layout : left-symmetric
 Chunk Size : 64K


  Number   Major   Minor   RaidDevice State
this     1       8       18        1      active sync   /dev/sdb2


 0     0       0        0        0      removed
 1     1       8       18        1      active sync   /dev/sdb2
 2     2       8       34        2      active sync   /dev/sdc2
 3     3       0        0        3      faulty removed
 4     4       8       50        4      spare   /dev/sdd2

Disco 3

jake@ubuntu-box:~$ sudo mdadm --examine /dev/sdc2/
dev/sdc2:
      Magic : a92b4efc
    Version : 0.90.00
       UUID : e7ab07c3:b9ffa9ae:377e3cd3:a8ece374
Creation Time : Thu Aug 18 14:30:36 2011
 Raid Level : raid5
Used Dev Size : 974800000 (929.64 GiB 998.20 GB)
 Array Size : 2924400000 (2788.93 GiB 2994.59 GB)
Raid Devices : 4
Total Devices : 3
Preferred Minor : 1


Update Time : Tue Mar 13 15:10:07 2018
      State : clean
Active Devices : 1
Working Devices : 2
Failed Devices : 2
Spare Devices : 1
   Checksum : e598570 - correct
     Events : 239374


     Layout : left-symmetric
 Chunk Size : 64K


  Number   Major   Minor   RaidDevice State
this     2       8       34        2      active sync   /dev/sdc2


0     0       0        0        0      removed
1     1       0        0        1      faulty removed
2     2       8       34        2      active sync   /dev/sdc2
3     3       0        0        3      faulty removed
4     4       8       50        4      spare   /dev/sdd2

e disco 4

jake@ubuntu-box:~$ sudo mdadm --examine /dev/sdd2/
dev/sdd2:
      Magic : a92b4efc
    Version : 0.90.00
       UUID : e7ab07c3:b9ffa9ae:377e3cd3:a8ece374
Creation Time : Thu Aug 18 14:30:36 2011
 Raid Level : raid5
Used Dev Size : 974800000 (929.64 GiB 998.20 GB)
 Array Size : 2924400000 (2788.93 GiB 2994.59 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 1


Update Time : Tue Mar 13 11:03:10 2018
      State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
   Checksum : e526d87 - correct
     Events : 14344


     Layout : left-symmetric
 Chunk Size : 64K


  Number   Major   Minor   RaidDevice State
this     3       8       50        3      active sync   /dev/sdd2


 0     0       8        2        0      active sync   /dev/sda2
 1     1       8       18        1      active sync   /dev/sdb2
 2     2       8       34        2      active sync   /dev/sdc2
 3     3       8       50        3      active sync   /dev/sdd2

Então - números mágicos e UUID são todos bons entre o conjunto. Os eventos estão todos fora de sintonia porque tentou reconstruir o # 4 substituído como reserva em vez de apenas reconstruir # 4

O disco 4 tem as informações corretas para o ataque e o seqüenciamento, já que era o drive que eu puxei originalmente e não recebi nada reescrito. Discos 1-3 estão mostrando em vários estados de caos de trocar as coisas ao redor.

Então, duas perguntas -

Um - Por que é exibido como raid0 no mdadm --detail

Dois - É possível atualizar as informações dos três primeiros discos que recebi do mdadm --examine /dev/sdd2 para que ele veja tudo como deveria, em vez do cluster que eu inadvertidamente fiz dele. Eu penso se eu puder encontrar uma maneira de atualizar as informações para as partições ou discos que o RAID deve remontar corretamente e reconstruir-se para que eu possa acessar meus dados

Qualquer ideia seria útil, já que cheguei ao ponto de conseguir descobrir isso sozinho e fazer muitas pesquisas.

Obrigado antecipadamente.

Jake

    
por psykokid 16.03.2018 / 02:01

2 respostas

0

Você disse:

About 60% into the rebuild one of the other drives in the array drops out

Este é um risco conhecido com o RAID-5 e é uma das razões pelas quais o RAID-5 não é considerado seguro para uso atualmente. Se duas unidades falharem ao mesmo tempo em uma matriz RAID-5, os dados serão irrecuperáveis. Infelizmente, a reconstrução de uma matriz em que uma unidade falhou pode causar estresse suficiente para as outras unidades, o que aumenta bastante a probabilidade de que outra unidade falhe durante a reconstrução. Quanto mais tempo a reconstrução (ou seja, quanto maiores as unidades, e quanto mais ocupadas estão fazendo outro trabalho real), mais provável é que isso aconteça.

Isso é especialmente verdadeiro se o conjunto RAID estiver em uso ativo por vários anos e os discos estiverem próximos do fim de vida esperado. Ou se todas as unidades da matriz forem da mesma execução de produção e tiverem falhas semelhantes (se houver um "lote defeituoso") ou uma vida útil semelhante esperada.

Devido à maneira como os dados são divididos nas unidades em uma matriz RAID-5 de 4 discos (ou seja, 3 discos para separar dados, 1 disco para paridade), quando duas unidades falham, pelo menos um terço todos os arquivos estarão ausentes . Isso é semelhante ao que acontece com a distribuição RAID-0 se uma ou mais unidades falharem - as partes dos arquivos distribuídos na (s) unidade (s) com falha desapareceram.

O RAID-6 melhora um pouco ao permitir que duas unidades falhem antes que todos os dados sejam perdidos, mas sofre o mesmo problema se três unidades falharem simultaneamente.

O RAID-1 é mais seguro porque se uma unidade morre, você pode recuperar os dados da outra unidade (ou de outras unidades se você espelhar para mais de uma unidade). Se todas as unidades de um conjunto de espelhos falharem, você perderá tudo.

O RAID-10 é semelhante ao RAID-1. Ainda é vulnerável se todas as unidades de um conjunto de espelhos morrerem simultaneamente. O RAID-10 pode sobreviver a uma falha de duas unidades, mas APENAS se as unidades com falha não estiverem no mesmo conjunto de espelhos. Por exemplo, id tem unidades a, b, c, d com dois pares espelhados (a + b e c + d) e qualquer combinação de duas unidades de pares diferentes (isto é, a + c, a + d, b + c ou b + d) pode falhar sem perder seus dados, mas se a + b ou c + d falhar, seus dados serão perdidos.

Com o RAID-1 e o RAID-10, o risco pode ser reduzido com mais unidades em cada conjunto espelhado. por exemplo. um drive de 6 RAID-10 pode ser configurado como + b, c + d, e + f (três pares espelhados, capacidade total = número de drives / 2) ou a + b + c e d + e + f (dois espelhados trigêmeos, capacidade total = número de unidades / 3)

Assim, todos os níveis de RAID têm modos de falha que podem resultar em perda de dados catastrófica.

A principal coisa a lembrar de tudo isso é:

O RAID NÃO É UM SUBSTITUTO DE BACKUPS REGULARES

    
por 16.03.2018 / 03:02
0

Então eu tentei algumas coisas. Primeiro parei o ataque depois de reiniciar a máquina esta manhã:

jake@ubuntu-box:~$ sudo mdadm -S /dev/md1
mdadm: stopped /dev/md1

Então, eu tento montar usando o uuid para o array:

jake@ubuntu-box:~$ sudo mdadm --assemble /dev/md1 --
uuid=e7ab07c3:b9ffa9ae:377e3cd3:a8ece374
mdadm: /dev/md1 assembled from 1 drive - not enough to start the array.

Ok, é o que eu esperava. Então, vamos tentar forçar:

jake@ubuntu-box:~$ sudo mdadm --assemble /dev/md1 --force --
uuid=e7ab07c3:b9ffa9ae:377e3cd3:a8ece374
mdadm: forcing event count in /dev/sdb2(1) from 238868 upto 239374
mdadm: forcing event count in /dev/sda2(0) from 20364 upto 239374
mdadm: /dev/md1 assembled from 3 drives - not enough to start the array.

Hrmm .. que deve ter funcionado. Vamos tentar remontar manualmente chamando as partições individuais para o ataque:

jake@ubuntu-box:~$ sudo mdadm --assemble /dev/md1 /dev/sda2 /dev/sdb2 
/dev/sdc2 /dev/sdd2 --force
mdadm: /dev/md1 has been started with 3 drives (out of 4).

BINGO! Parece que começou com 3 das 4 unidades. Bom o suficiente, isso significa que eu posso acessar meus dados! Vamos verificar os detalhes apenas para risos:

jake@ubuntu-box:~$ sudo mdadm --detail /dev/md1/dev/md1:
        Version : 0.90
  Creation Time : Thu Aug 18 14:30:36 2011
     Raid Level : raid5
     Array Size : 2924400000 (2788.93 GiB 2994.59 GB)
  Used Dev Size : 974800000 (929.64 GiB 998.20 GB)
   Raid Devices : 4
  Total Devices : 3
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Tue Mar 13 14:00:33 2018
          State : clean, degraded 
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : e7ab07c3:b9ffa9ae:377e3cd3:a8ece374
         Events : 0.239374

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       8       18        1      active sync   /dev/sdb2
       2       8       34        2      active sync   /dev/sdc2
       6       0        0        6      removed

Estou copiando dados enquanto falamos. Então, não os dados não eram irrecuperáveis - só precisava saber os comandos certos para forçar a invasão a remontar.

    
por 16.03.2018 / 18:19

Tags