Substituir uma unidade com falha num array mdadm no Ubuntu

A informação neste post baseia-se no Ubuntu 18.04 e na versão do mdadm incluída nos seus repositórios; No momento em que escrevo as v4.1-RC1. Pode ou não ser válida para outras versões.

Recentemente tive uma falha súbita de disco no meu servidor de ficheiros doméstico, que consiste em nove discos num array MDADM RAID-6. Isso é sempre assustador, mas tive a sorte de conseguir rapidamente um disco de substituição que já tinha sido entregue no dia seguinte para poder começar a reconstrução.

Admito que fui um pouco mão de vaca quando configurei o servidor de ficheiros originalmente; apenas dois dos discos são discos NAS reais (Seagate IronWolf), enquanto os restantes são discos de secretária (Seagate Barracuda). Não surpreendentemente, era um dos discos de secretária que tinha desistido (depois de quase três anos de serviço, no entanto). Estava completamente morto; depois de o mover para uma caixa USB de secretária, tudo o que consegui foi um som de clique inquietante e nem o Ubuntu 20.04 nem o Windows 10 conseguiram detetá-lo.

Enfim, vamos à peça de substituição (e sim, o disco novo que comprei era um IronWolf, lição aprendida) – por mais assustador que seja perder um disco num array a funcionar, é ainda mais assustador se não souberes o procedimento correto para o substituir. Não é a primeira vez que tenho de substituir um disco avariado num array mdadm, mas felizmente é tão raro que normalmente tenho de procurar os comandos corretos. Desta vez decidi criar o meu próprio pequeno guia para referência futura.

Portanto, antes de mais, quando recebes o temido e-mail de evento de falha do mdadm, tens de identificar qual disco falhou. Claro que vai dizer-te o nome do dispositivo (no meu caso /dev/sdf), mas provavelmente não é óbvio qual é o disco físico, pois esses nomes podem mudar quando a máquina é arrancada.

Se nem sequer tiver a certeza de qual o nome do dispositivo falhou, pode usar o seguinte comando para descobrir (substituir /dev/md0 pelo seu dispositivo RAID):

Como já foi referido, no meu caso foi /dev/sdf, por isso vamos continuar com isso.

Depois, pode tentar encontrar o número de série do disco avariado emitindo este comando:

(se o smartctl não for encontrado, tens de instalar o pacote smartmontools no Ubuntu)

O número de série pode então ser comparado com os números de série na etiqueta física dos discos para determinar qual deles falhou.

Desta vez, no entanto, não tive tanta sorte. O disco estava completamente descarregado e até se recusou a fornecer dados SMART ou outros, incluindo o número de série.

Como tinha acesso físico ao servidor (que é realmente necessário se for substituir um disco físico, suponho ;-)) e o servidor estava realmente a funcionar quando o disco falhou (e continuava a funcionar bem graças à redundância do RAID-6), optei pelo método muito primitivo, mas na verdade muito eficaz e óbvio, de simplesmente copiar um ficheiro grande para o servidor e ver qual a luz do disco rígido que não piscaria. Em poucos segundos identifiquei o culpado.

Agora, antes de retirar o disco físico, é boa ideia informar formalmente o mdadm desta intenção, emitindo este comando (substitua os nomes dos dispositivos pelos seus próprios, conforme apropriado):

Em caso de sucesso, o mdadm responde com uma mensagem a dizer que "removeu o disco" em quente, aparentemente porque o dispositivo RAID virtual está realmente a correr nesse momento.

Se falhar com uma mensagem de erro semelhante a "dispositivo ou recurso ocupado", pode ser que o mdadm não tenha registado o disco como tendo falhado completamente. Para que isso aconteça, emita este comando (mais uma vez, lembre-se de substituir os nomes dos dispositivos pelos seus próprios, conforme apropriado):

Depois disso, deves conseguir remover o dispositivo do array com o comando anterior.

Agora é altura de realmente substituir o disco. Se tiveres mesmo, mesmo – mesmo – a certeza de que a tua máquina e o controlador suportam hot swap, podes fazer isto sem desligar a máquina. Esse seria o caminho a seguir em sistemas críticos de produção a correr em hardware real e adequado para servidores, que se sabe com certeza que consegue lidar com isso. No entanto, o meu servidor de ficheiros doméstico baseia-se numa motherboard de secretária de consumo com alguns controladores SATA semi-sem nome nos slots PCIe para fornecer mais portas SATA.

Embora o SATA geralmente deva suportar hot swapping, não estava disposto a arriscar nada nesta configuração, por isso optei por desligar a máquina enquanto substituía o disco.

Antes disso, é boa ideia comentar o dispositivo RAID no ficheiro /etc/fstab para que o Ubuntu não tente montá-lo automaticamente no próximo arranque, pois pode bloquear e forçar-te a entrar em modo de recuperação devido à degradação do array RAID. Isso pode não ser um grande problema se for um sistema de secretária, mas eu uso este servidor sem headless, sem monitor ou teclado ligados, por isso isto seria um pouco incómodo.

Depois de arrancar a máquina com o disco novo e brilhante instalado, use LSBLK ou outro meio para o identificar. Se não alteraste mais nada, provavelmente (mas não necessariamente) terá o mesmo nome do disco que substituiste. No meu caso, sim, por isso o novo também se chama /dev/sdf.

Como o meu array é baseado em partições e não em dispositivos físicos, precisei de copiar a tabela de partições de um disco funcional para o novo disco para garantir que são exatamente iguais. Se executares o teu array em dispositivos físicos, podes saltar este passo.

Usei o sgdisk para este propósito, copiando a tabela de partições de /dev/sdc para /dev/sdf. Certifica-te de substituir os nomes dos dispositivos para corresponderem ao teu, conforme apropriado.

Repara na ordem aqui: primeiro colocas o "para" a conduzir! Isto é um pouco contraintuitivo para mim, mas certifica-te de que acertas para não teres outra falha de disco no array ;-)

Depois, para evitar conflitos de UUIDs, gerar novos UUIDs para o novo disco:

E agora, finalmente, chegou a altura de adicionar o novo disco à matriz e iniciar a equipa de reconstrução! (Ok, não é propriamente uma festa, é na verdade um processo bastante lento e desconcertante, pois não queres mesmo que outro disco avarie neste momento. A cerveja pode ajudar, no entanto)

De qualquer forma, para adicionar o novo disco ao array, emita este comando (novamente, certifique-se de substituir os nomes dos dispositivos pelos seus próprios, conforme apropriado):

Se tudo correr bem, o disco será adicionado ao array sem problemas. Acredito que na verdade é adicionado como "hot spare" por defeito, mas como este array está sem um disco (aquele que falhou), é imediatamente colocado em uso e o processo de reconstrução começa.

Podes estar atento assim:

Isto provavelmente vai demorar algum tempo; no meu servidor modesto (baseado sobretudo em hardware de consumo e discos de secretária, atenção) conseguia atingir pouco menos de 100 MB/s. Tenha em mente que isto é RAID-6, por isso há muitos cálculos de paridade envolvidos numa reconstrução; um RAID-10 teria sido muito mais rápido. Esta máquina em particular tem um CPU AMD A10 9700E quad core (o "E" significa que é um modelo eficiente em termos energéticos com infra-clock, ou seja, não muito rápido), só para te dar uma ideia do que esperar. Com os nove discos de 8 TB na minha configuração, a reconstrução completa demorou pouco mais de 24 horas.

Durante a reconstrução, podes montar o sistema de ficheiros no array e usá-lo normalmente, se quiseres, mas prefiro deixar a reconstrução até terminar. Tenha em mente que, se um disco falhar, outro pode seguir em breve, por isso quer que a reconstrução seja feita o mais rápido possível, pois não quer que outro disco avarie durante esse período. Por isso, não sobrecarregue com outras IOs que não sejam estritamente necessárias.

Quando estiver pronto, adiciona-o de volta ao teu ficheiro /etc/fstab, reinicia e aproveita os teus ficheiros :-)