Volumes com falha no RAID - como manipular?

Question

Eu tenho uma situação em um RAID que assumi responsabilidade recentemente e realmente poderia usar alguns conselhos. Espero não ter estragado muito.

Um par de servidores no cluster ad-hoc que estou administrando começou a relatar problemas de disco. Eu executei fsck em um, xfs_repair no outro. O primeiro parecia ser fixo, o segundo não relatava problemas. Eles poderiam ser montados como leitura-gravação e forneceriam erros de leitura em determinados arquivos.

Eu rastreei os discos de volta para um único RAID:

• JetStor 416iS
• 16 unidades de 750 GB
• Grupo de volume único com muitos volumes de dados, RAID 6

Olhando para a interface de administração do JetStor:

• duas unidades foram listadas como com falha
• 6 unidades listadas como defeituosas
• três volumes de usuários foram listados como com falha (dois são mais importantes para mim do que o outro)

Veja o que eu fiz:

1. Remontou todas as partições como somente leitura ou desmontou-as. (Mesmo que o suporte do JetStor disse que isso não é necessário. A unidade está fora da garantia, mas eles responderam a esta pergunta para mim)
2. Substituiu (hot-swap) as duas unidades com falha e permitiu que elas fossem reconstruídas.
3. Substituído (hot-swap) duas das unidades rotuladas como 'defeito' e permitem que elas sejam reconstruídas. Essas duas unidades foram associadas aos dois volumes de usuários com falha mais importantes no painel de administração do JetStor.
4. Criado um par de novos volumes de usuários para atuar como volumes de substituição maiores e atuar como armazenamento intermediário.
5. Tentei remontar os dois volumes com falha. Agora eles não vão montar nada.
6. A execução do xfs_repair em um agora gerava erros sobre superblocos ruins e algumas tentativas de reparo, e um despejo no diretório lost + found com muitos arquivos, mas não uma correção de um corrompido que eu esperava. Eu vou recuperar o que posso para este disco de backup e reconstruir o resto (ele mantém o catálogo para o meu sistema de backup, por isso yikes!)

Então, minha pergunta é sobre o segundo volume de usuários (tipo ext3). Eu não tentei repará-lo ainda b / c do que aconteceu com o volume xfs (ou seja, o despejo em lost + found). Eu tenho um backup parcial deste volume cobrindo os arquivos mais críticos, mas seria ótimo para obter todos os outros de volta (que não estavam corrompidos). Se os arquivos recuperados forem descartados para perdidos, será muito melhor do que nada, é claro.

Eu tentei fazer o dd, mas isso falhou em alguns shows (é um volume de 500GB):

dd if=/dev/sdf of=/homLocDump/sdfDump.img conv=noerror,sync 

dd: reading '/dev/sdf': Input/output error
15002344+0 records in
15002344+0 records out
7681200128 bytes (7.7 GB) copied, 493.416 seconds, 15.6 MB/s
dd: writing to '/homLocDump/sdfDump.img': Read-only file system
15002344+1 records in
15002344+0 records out
7681200128 bytes (7.7 GB) copied, 493.417 seconds, 15.6 MB/s

fsck mostra isso:

[root@shank ~]# fsck.ext3 -nv /dev/sdf
e2fsck 1.39 (29-May-2006)
Couldn't find ext2 superblock, trying backup blocks...
fsck.ext3: Bad magic number in super-block while trying to open /dev/sdf

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Eu tentei com as opções '-b', com os blocos 8193, 16384 e 32768, e depois mais superblocos para um bloco de 4k fs (estou assumindo que é 4k blockize como outros dispositivos neste sistema) mas consegui o mesmo. / p>

dumpe2fs:

[root@shank ~]# dumpe2fs /dev/sdf
dumpe2fs 1.39 (29-May-2006)
dumpe2fs: Bad magic number in super-block while trying to open /dev/sdf
Couldn't find valid filesystem superblock.

Posso até mesmo tentar fsck neste volume mais? Além da questão do superbloco, não tenho certeza agora sobre a adequação da execução do fsck em volumes raid.

É possível substituir temporariamente a unidade defeituosa antiga no RAID para obter um estado em que o volume possa ser montado e recuperar alguns arquivos?

Além disso, estou curioso sobre como um volume pode ficar ruim assim em um ataque - o ataque não deveria estar protegendo a integridade? Se duas unidades falharem no RAID 6, não é para tolerar isso?

    

Answer 1

Eu acho que é muito claro que sua matriz é essencialmente falha e, a menos que você tenha backups, uma boa parte de seus dados é perdida. Se você tiver backups, todos substituirão as unidades com falha e restaurarão dos backups. Se você não o fizer, e seus empregadores acharem que vale a pena, peça a uma empresa de recuperação de dados profissional que tente recuperar o que puder (e, pelo amor de Deus, pare de fazer qualquer coisa com essas unidades, pois isso só está piorando). , mas esta é uma opção bastante cara.

Neste ponto, a melhor coisa que você pode fazer, além de fazer backups e / ou ter profissionais tentando recuperar seus dados, é configurar sistemas e processos de monitoramento para garantir que você não acabe com uma falha array novamente, substituindo as unidades à medida que elas falham, em vez de depois que é tarde demais e muitas falharam na recuperação de todos os seus dados.

Eu também consideraria seriamente um trabalho em outro lugar. Um ambiente que foi permitido decair para esse tipo de estado é um inferno especial.

    

Answer 2

Neste ponto, está bem claro que seus volumes estão perdidos. Agora você tem uma decisão a tomar: O quanto você precisa desses dados?

• Se você tiver tempo e não se importar com mais perda de dados, sinta-se à vontade para continuar experimentando.

• Se você precisar muito, desligue toda a matriz. Marque as unidades em suas posições atuais. Marque também as unidades removidas durante as reconstruções de onde elas vieram. Chame um especialista em recuperação de dados como OnTrack e organize o envio da matriz para recuperação.

• Se você não precisa dos dados, sugiro que seja hora de recomeçar os backups. Mas certifique-se de substituir TODAS as unidades que retornaram erros. Enquanto você está nisso, examine os registros SMART de todas as unidades e substitua quaisquer que tenham mais erros do que os outros. Você provavelmente precisará excluir os volumes existentes.

A longo prazo, recomendo a reconfiguração do seu array. 16 drives em uma configuração RAID5 ou RAID6 são muitos. Eu recomendo dividir suas unidades em dois grupos de 8 em execução RAID6 e RAID0 sobre essas unidades. O JetStor pode fazer isso por você automaticamente e pode chamá-lo de RAID60.