Como você pode forçar o software raid do Linux a não desabilitar um disco para recuperação?

1

Estou tentando recuperar dados de um array RAID5. 2 dos meus 4 discos falharam inesperadamente ao mesmo tempo. Eu sou capaz de iniciar o array, forçando-o.

mdadm --assemble --scan --force

O array inicia o ckean mas é degradado

root@omv:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Wed Apr 18 22:03:46 2012
     Raid Level : raid5
     Array Size : 8790795264 (8383.56 GiB 9001.77 GB)
  Used Dev Size : 2930265088 (2794.52 GiB 3000.59 GB)
   Raid Devices : 4
  Total Devices : 3
    Persistence : Superblock is persistent

    Update Time : Mon Aug 25 23:50:44 2014
          State : clean, degraded
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 512K

           Name : omv:data  (local to host omv)
           UUID : 157604ce:9206dd99:c8d249be
         Events : 21524

    Number   Major   Minor   RaidDevice State
       4       8       16        0      active sync   /dev/sdb
       1       0        0        1      removed
       2       8       32        2      active sync   /dev/sdc
       3       8       48        3      active sync   /dev/sdd

Eu prossigo para montar o sistema de arquivos no modo somente leitura. Os erros de leitura acabam resultando no dispositivo sendo descartado da matriz. Existe uma maneira que eu possa forçá-lo a não cair? Eu gostaria de poder copiar o que eu puder.

[  190.250032] end_request: I/O error, dev sdc, sector 1234525616
[  190.250082] raid5:md0: read error not correctable (sector 1234525616 on sdc).
[  190.250086] raid5: Disk failure on sdc, disabling device.
[  190.250088] raid5: Operation continuing on 2 devices.
[  190.250195] ata5: EH complete
[  190.366679] Buffer I/O error on device md0, logical block 462946358
[  190.366723] lost page write due to I/O error on md0
[  192.873263] ata5.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x0
[  192.873308] ata5.00: irq_stat 0x40000008
[  192.873348] ata5.00: failed command: READ FPDMA QUEUED
[  192.873392] ata5.00: cmd 60/10:00:00:dc:3c/00:00:57:00:00/40 tag 0 ncq 8192 in
[  192.873394]          res 41/40:10:00:dc:3c/00:00:57:00:00/00 Emask 0x409 (media error) <F>
[  192.873476] ata5.00: status: { DRDY ERR }
[  192.873514] ata5.00: error: { UNC }
    
por Marinus 26.08.2014 / 00:23

2 respostas

2

Você deve capturar imagens de todas as unidades de membros RAID com uma ferramenta como dd_rescue e, em seguida, montar um volume RAID com essas imagens.

Dessa forma, você não sobrecarrega os discos rígidos com falha e tem a melhor chance de recuperar dados.

    
por 26.08.2014 / 09:26
0

O problema é que o sistema de arquivos ext2 / 3/4 não sabe nada do dispositivo subjacente. Se houver um bloqueio ruim em alguns dos dispositivos de ataque, ele causará 2 resultados diferentes e independentes:

  1. o subsistema raid desativará todo o disco e colocará o array no modo degradado
  2. o sistema de arquivos assinará um erro de leitura (no caso de um espelho, nem sempre é assim).

Eu tenho uma opinião, que é considerada principalmente herética nos círculos de "administradores de sistemas profissionais". Nesta opinião,

  1. um disco com alguns blocos ruins não vem do diabo,
  2. Se você tem 45634563563456 bom setor em um disco rígido, talvez você consiga lidar com os 3 ruins entre eles.

O problema é que o mecanismo de ataque subjacente também não sabe nada sobre os blocos defeituosos no disco. Ele tentará sincronizar até mesmo os blocos ruins.

Se você tiver um ataque, a solução mais simples seria obter um novo disco rígido. Este também pode ser usado para outras tarefas, mas não para invasões. O sistema de arquivos ext2 / 3/4 tem um bom tratamento de blocos defeituosos.

Se você quiser usar mais como um dispositivo de membro raid, é possível, embora não tão simples. Nesse caso, você pode fazer uma solução complicada baseada em lvm - algumas podem manipular e gerenciar volumes, mesmo em um disco com blocos defeituosos. Sugiro que você tente usar o módulo de realocação de blocos defeituosos do mapeador de dispositivos .

    
por 26.08.2014 / 10:40