Pesquisa de site

Como recuperar dados e reconstruir RAIDs de software com falha - Parte 8


Nos artigos anteriores desta série RAID você passou de zero a herói RAID. Revisamos várias configurações de software RAID e explicamos o essencial de cada uma, juntamente com os motivos pelos quais você escolheria uma ou outra, dependendo do seu cenário específico.

Neste guia, discutiremos como reconstruir uma matriz RAID de software sem perda de dados no caso de falha do disco. Para resumir, consideraremos apenas uma configuração de RAID 1 – mas os conceitos e comandos se aplicam a todos os casos.

Cenário de teste RAID

Antes de prosseguir, certifique-se de ter configurado um array RAID 1 seguindo as instruções fornecidas na Parte 3 desta série: Como configurar o RAID 1 (Espelho) no Linux.

As únicas variações em nosso caso atual serão:

1) uma versão diferente do CentOS (v7) daquela usada naquele artigo (v6.5) e
2) tamanhos de disco diferentes para /dev/sdb e /dev/sdc (8 GB cada).

Além disso, se o SELinux estiver ativado no modo de imposição, você precisará adicionar os rótulos correspondentes ao diretório onde montará o dispositivo RAID. Caso contrário, você encontrará esta mensagem de aviso ao tentar montá-lo:

Você pode corrigir isso executando:


restorecon -R /mnt/raid1

Configurando o monitoramento RAID

Há vários motivos pelos quais um dispositivo de armazenamento pode falhar (no entanto, os SSDs reduziram bastante as chances de isso acontecer), mas independentemente da causa, você pode ter certeza de que problemas podem ocorrer a qualquer momento e você precisa estar preparado para substituir o dispositivo com falha. parte e para garantir a disponibilidade e integridade dos seus dados.

Um conselho primeiro. Mesmo quando você pode inspecionar /proc/mdstat para verificar o status de seus RAIDs, existe um método melhor e mais rápido que consiste em executar mdadm no monitor + scan modo, que enviará alertas por e-mail para um destinatário predefinido.

Para configurar isso, adicione a seguinte linha em /etc/mdadm.conf:


MAILADDR user@<domain or localhost>

No meu caso:


MAILADDR gacanepa@localhost

Para executar mdadm no modo monitor + scan, adicione a seguinte entrada crontab como root:


@reboot /sbin/mdadm --monitor --scan --oneshot

Por padrão, o mdadm verificará os arrays RAID a cada 60 segundos e enviará um alerta se encontrar algum problema. Você pode modificar esse comportamento adicionando a opção --delay à entrada do crontab acima junto com a quantidade de segundos (por exemplo, --delay 1800 significa 30 minutos).

Finalmente, certifique-se de ter um Mail User Agent (MUA) instalado, como mutt ou mailx. Caso contrário, você não receberá nenhum alerta.

Em um minuto veremos como é um alerta enviado por mdadm.

Simulando e substituindo um dispositivo de armazenamento RAID com falha

Para simular um problema com um dos dispositivos de armazenamento na matriz RAID, usaremos as opções --manage e --set-faulty da seguinte forma:


mdadm --manage --set-faulty /dev/md0 /dev/sdc1  

Isso fará com que /dev/sdc1 seja marcado como defeituoso, como podemos ver em /proc/mdstat:

Mais importante ainda, vamos ver se recebemos um alerta por e-mail com o mesmo aviso:

Neste caso, você precisará remover o dispositivo da matriz RAID de software:


mdadm /dev/md0 --remove /dev/sdc1

Então você pode removê-lo fisicamente da máquina e substituí-lo por uma peça sobressalente (/dev/sdd, onde uma partição do tipo fd foi criada anteriormente):


mdadm --manage /dev/md0 --add /dev/sdd1

Felizmente para nós, o sistema começará a reconstruir automaticamente o array com a parte que acabamos de adicionar. Podemos testar isso marcando /dev/sdb1 como defeituoso, removendo-o do array e certificando-nos de que o arquivo tecmint.txt ainda esteja acessível em / mnt/raid1:


mdadm --detail /dev/md0
mount | grep raid1
ls -l /mnt/raid1 | grep tecmint
cat /mnt/raid1/tecmint.txt

A imagem acima mostra claramente que após adicionar /dev/sdd1 ao array em substituição a /dev/sdc1, a reconstrução dos dados foi realizada automaticamente pelo sistema sem intervenção da nossa parte.

Embora não seja estritamente obrigatório, é uma ótima ideia ter um dispositivo sobressalente à mão para que o processo de substituição do dispositivo defeituoso por uma unidade em boas condições possa ser feito rapidamente. Para fazer isso, vamos adicionar novamente /dev/sdb1 e /dev/sdc1:


mdadm --manage /dev/md0 --add /dev/sdb1
mdadm --manage /dev/md0 --add /dev/sdc1

Recuperando-se de uma perda de redundância

Conforme explicado anteriormente, o mdadm reconstruirá automaticamente os dados quando um disco falhar. Mas o que acontece se 2 discos do array falharem? Vamos simular esse cenário marcando /dev/sdb1 e /dev/sdd1 como defeituosos:


umount /mnt/raid1
mdadm --manage --set-faulty /dev/md0 /dev/sdb1
mdadm --stop /dev/md0
mdadm --manage --set-faulty /dev/md0 /dev/sdd1

Tentativas de recriar o array da mesma forma que foi criado neste momento (ou usando a opção --assume-clean) podem resultar em perda de dados, portanto deve ser deixado como último recurso.

Vamos tentar recuperar os dados de /dev/sdb1, por exemplo, para uma partição de disco semelhante (/dev/sde1 – observe que isso requer que você crie uma partição de digite fd em /dev/sde antes de continuar) usando ddrescue:


ddrescue -r 2 /dev/sdb1 /dev/sde1

Observe que até agora não tocamos em /dev/sdb ou /dev/sdd, as partições que faziam parte da matriz RAID.

Agora vamos reconstruir o array usando /dev/sde1 e /dev/sdf1:


mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sd[e-f]1

Observe que em uma situação real, você normalmente usará os mesmos nomes de dispositivos do array original, ou seja, /dev/sdb1 e /dev/sdc1 após o discos com falha foram substituídos por novos.

Neste artigo, optei por usar dispositivos extras para recriar o array com discos novos e evitar confusão com as unidades originais com falha.

Quando perguntado se deseja continuar escrevendo o array, digite Y e pressione Enter. O array deve ser iniciado e você poderá observar seu progresso com:


watch -n 1 cat /proc/mdstat

Quando o processo for concluído, você poderá acessar o conteúdo do seu RAID:

Resumo

Neste artigo revisamos como se recuperar de falhas de RAID e perdas de redundância. Porém, é preciso lembrar que esta tecnologia é uma solução de armazenamento e NÃO substitui os backups.

Os princípios explicados neste guia aplicam-se igualmente a todas as configurações de RAID, bem como aos conceitos que abordaremos no próximo e último guia desta série (gerenciamento de RAID).

Se você tiver alguma dúvida sobre este artigo, sinta-se à vontade para nos enviar uma mensagem usando o formulário de comentários abaixo. Estamos ansiosos para ouvir de você!