Reconstruindo Raid-arrays

Question

Como posso reconstruir as matrizes de raids? Eu estou usando o Raid 1. Meu datacentar diz que precisa ser corrigido, primeiro eu pensei que é HDDs com defeito por causa do resultado da digitalização smartmoontools, mas não é.

comando:

cat / proc / mdstat

saída:

Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb1[1] sda1[0]
      2096064 blocks [2/2] [UU]

md1 : active raid1 sda2[0]
      524224 blocks [2/1] [U_]

md2 : active raid1 sda3[0]
      729952192 blocks [2/1] [U_]

unused devices: <none>

Preciso de:

# mdadm /dev/md1 -r /dev/sdb2
# mdadm /dev/md2 -r /dev/sdb3
# mdadm /dev/md3 -r /dev/sdb4

e depois

# mdadm /dev/md1 -a /dev/sdb2
# mdadm /dev/md2 -a /dev/sdb3
# mdadm /dev/md3 -a /dev/sdb4 

Perderei dados ou meu servidor ficará off-line?

Aqui está a saída para fdisk -l

Disk /dev/sda: 750.1 GB, 750156374016 bytes
64 heads, 32 sectors/track, 715404 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               2        2048     2096128   fd  Linux raid autodetect
/dev/sda2            2049        2560      524288   fd  Linux raid autodetect
/dev/sda3            2561      715404   729952256   fd  Linux raid autodetect

Disk /dev/sdb: 750.1 GB, 750156374016 bytes
64 heads, 32 sectors/track, 715404 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               2        2048     2096128   fd  Linux raid autodetect
/dev/sdb2            2049        2560      524288   fd  Linux raid autodetect
/dev/sdb3            2561      715404   729952256   fd  Linux raid autodetect

Disk /dev/md2: 747.4 GB, 747471044608 bytes
2 heads, 4 sectors/track, 182488048 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md2 doesn't contain a valid partition table

Disk /dev/md1: 536 MB, 536805376 bytes
2 heads, 4 sectors/track, 131056 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md1 doesn't contain a valid partition table

Disk /dev/md0: 2146 MB, 2146369536 bytes
2 heads, 4 sectors/track, 524016 cylinders
Units = cylinders of 8 * 512 = 4096 bytes

Disk /dev/md0 doesn't contain a valid partition table

Aqui está a saída para smartctl -A / dev / sdb

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   111   100   006    Pre-fail  Always       -       38042073
  3 Spin_Up_Time            0x0003   100   100   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       7
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   073   060   030    Pre-fail  Always       -       24494887
  9 Power_On_Hours          0x0032   091   091   000    Old_age   Always       -       7935
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       7
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       4
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   062   052   045    Old_age   Always       -       38 (Min/Max 34/41)
194 Temperature_Celsius     0x0022   038   048   000    Old_age   Always       -       38 (0 26 0 0 0)
195 Hardware_ECC_Recovered  0x001a   032   026   000    Old_age   Always       -       38042073
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       101494372179726
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       3317006641
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       2924590852

    

Answer 1

Esse drive sdb parece não estar longe de falhar. Embora ainda não tenha oficialmente falhado, ainda não tem muita vida.

195 Hardware_ECC_Recovered  0x001a   032   026   000    Old_age   Always       -       38042073

Esta unidade teve um grande número de erros de leitura recuperáveis . O que significa que reconstruiu com sucesso os dados usando correção de erros. No entanto, está chegando ao ponto em que é mais provável que em breve ele tenha um erro de leitura irrecuperável , em que não é possível reconstruir dados com êxito em uma seção danificada ou com falha do disco. Nesse ponto, não há nada que você possa fazer e você terá que substituir a unidade.

Se a sua reconstrução continuar parando, no mesmo local, é totalmente possível que a unidade já tenha falhado nesse ponto nos pratos e não esteja reportando isso. As unidades de classe de desktop irão parar e tentar por minutos ou mesmo horas para ler um setor em particular se falharem na primeira vez, o que leva a esse tipo de coisa. E você provavelmente tem essa unidade neste "servidor" ...

Neste ponto, você deve ter essa unidade substituída proativamente, já que ela falhará em breve, se ainda não foi possível.

    

Answer 2

Parece que apenas uma metade do espelho está faltando. Portanto, não deve haver problema. Mas a questão é por que os sumbirrors (sdbX) estão faltando? Talvez seja uma boa ideia verificá-los antes de ligá-los aos espelhos.

mdadm --manage /dev/md1 --add /dev/sdb2
mdadm --manage /dev/md2 --add /dev/sdb3
mdadm --manage /dev/md3 --add /dev/sdb4

    

Answer 3

Quando você tem dois volumes espelhados usando o RAID1, cada cópia tem um "contador de atividades" que é atualizado quando algo é alterado dentro da cópia: dessa forma, o sistema é capaz de entender qual é o mais atualizado em caso de um acidente ou outras coisas que derrubam um dos dois.

Ressincronização significa que a mais atual é copiada sobre a mais antiga, que "perdeu a sincronização". Portanto, um disco rígido off-line ou defeituoso forçará o array a entrar no "modo degradado" (apenas uma cópia on-line, sem redundância).

A partir de um modo degradado, você pode recuperar forçando uma ressincronização para que a única partição ativa seja clonada para aquela que você tenha levado de volta ao trabalho ou substituindo o disco defeituoso e fornecendo o novo espaço para a matriz, que será clonada. da mesma forma descrita anteriormente.

Ambos os métodos manterão seus dados intactos, a menos que você faça algo impróprio para as configurações ou para as "boas" partições que ainda estão ativas =)

Eu acho que é uma boa idéia fazer backup de suas configurações de ataque antes mesmo de pensar em mexer com elas =)

Quanto aos valores SMART, eles parecem bem para mim, além do Hardware_ECC_Recovered, que também é discutido em outras respostas.

De qualquer forma, evite considerar o único valor que você vê lá, e também verifique em qual ritmo ele está mudando. Eu já tive valores estranhos em uma unidade, mas eles não ficaram piores, eles eram estáveis. Por outro lado, bons valores SMART não são prova de um disco perfeito: na minha opinião, pode ser bom verificar o desgaste do disco devido ao uso / envelhecimento, mas eles podem fazer pouco para evitar falhas súbitas (por exemplo, aquelas causadas por estresse mecânico, superaquecimento, etc. - pense em um cooler com falha na sala do servidor ..)

Boa sorte! =)