Miklix

Substituir uma unidade com falha num array mdadm no Ubuntu

Publicado: 15 de fevereiro de 2025 às 22:02:30 UTC

Se estiver na terrível situação de ter uma falha de unidade num array RAID mdadm, este artigo explica como substituí-la correctamente num sistema Ubuntu.


Esta página foi traduzida automaticamente do inglês para a tornar acessível ao maior número possível de pessoas. Infelizmente, a tradução automática ainda não é uma tecnologia aperfeiçoada, pelo que podem ocorrer erros. Se preferir, pode ver a versão original em inglês aqui:

Replacing a Failed Drive in an mdadm Array on Ubuntu

As informações deste post são baseadas no Ubuntu 18.04 e na versão do mdadm incluída nos seus repositórios; no momento da escrita v4.1-rc1. Pode ou não ser válido para outras versões.

Recentemente, tive uma falha repentina de unidade no meu servidor de ficheiros doméstico, que consiste em nove unidades numa matriz RAID-6 mdadm. Isto é sempre assustador, mas felizmente consegui encontrar rapidamente uma unidade de substituição que foi entregue no dia seguinte, para que pudesse iniciar a reconstrução.

Admito que fui um pouco forreta quando configurei o servidor de ficheiros originalmente; apenas duas das unidades são unidades NAS reais (Seagate IronWolf), enquanto as restantes são unidades de secretária (Seagate Barracuda). Não é de estranhar que tenha sido uma das unidades de desktop que avariou (após quase três anos de serviço). Estava completamente morto; depois de o mover para uma caixa USB de secretária, tudo o que ouvi foi um som de clique enervante e nem o Ubuntu 20.04 nem o Windows 10 conseguiram detectá-lo.

Bem, vamos à peça de substituição (e sim, o novo disco que comprei era um IronWolf, lição aprendida) - por mais assustador que seja perder um disco num array em execução, é ainda mais assustador se não souber o procedimento correcto para o substituir. Não é a primeira vez que preciso de substituir uma unidade com defeito num array mdadm, mas felizmente é tão raro que normalmente tenho de procurar os comandos correctos. Desta vez decidi criar o meu próprio pequeno guia para referência futura.

Assim, antes de mais, quando receber o temido e-mail de falha do mdadm, precisa de identificar qual a unidade que falhou. Claro que lhe dirá o nome do dispositivo (no meu caso, /dev/sdf), mas provavelmente não é óbvio qual é realmente a unidade física, uma vez que estes nomes podem mudar quando a máquina é iniciada.

Se não tiver a certeza de qual o nome de dispositivo que falhou, pode utilizar o seguinte comando para descobrir (substitua /dev/md0 pelo seu dispositivo RAID):

mdadm -–query -–detail /dev/md0

Como referido, no meu caso era /dev/sdf, por isso vamos continuar com isso.

Assim, pode tentar encontrar o número de série da unidade com falha emitindo este comando:

smartctl -–all /dev/sdf | grep -i 'Serial'

(se o smartctl não for encontrado, é necessário 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 das unidades para descobrir qual delas falhou.

Desta vez, porém, não tive tanta sorte. A unidade estava completamente morta e recusou-se mesmo a fornecer dados SMART ou outros, incluindo o número de série.

Como tinha acesso físico ao servidor (o que realmente precisa se for substituir um disco físico, penso eu ;-)) e o servidor estava realmente a funcionar quando o disco falhou (e continuou a funcionar bem graças à redundância RAID-6), utilizei o método primitivo, mas altamente eficaz e óbvio, de simplesmente copiar um ficheiro grande para o servidor e observar qual a luz do HDD que não piscava. Em poucos segundos, identifiquei o culpado.

Agora, antes de remover a unidade física, é uma boa ideia informar formalmente o mdadm sobre esta intenção, emitindo este comando (substitua os nomes dos dispositivos pelos seus, conforme apropriado):

mdadm -–manage /dev/md0 -–remove /dev/sdf1

Em caso de sucesso, o mdadm responderá com uma mensagem a dizer que "removeu a quente" a unidade, aparentemente porque o dispositivo RAID virtual está a ser executado no momento.

Se falhar com uma mensagem de erro semelhante a "dispositivo ou recurso ocupado", pode ser que o mdadm não tenha registado a unidade para ter falhado completamente. Para tal, emita este comando (mais uma vez, lembre-se de substituir os nomes dos dispositivos pelos seus, conforme apropriado):

mdadm --manage /dev/md0 --fail /dev/sdf

Depois disso, poderá remover o dispositivo do array com o comando anterior.

Agora é altura de realmente substituir a unidade. Se tiver realmente, realmente - tipo, realmente - a certeza de que a sua máquina e o seu controlador suportam a troca a quente, pode fazê-lo sem desligar a máquina. Esta seria a forma de o fazer em sistemas de produção críticos que funcionam em hardware de servidor real e adequado, que sabe que pode lidar com isso. O meu servidor de ficheiros doméstico é baseado numa placa-mãe de desktop de nível doméstico com alguns controladores SATA semi-nomeado nos slots PCIe para fornecer mais portas SATA.

Embora o SATA suporte geralmente a troca a quente, não estava disposto a arriscar nada nesta configuração, pelo que optei por desligar a máquina enquanto substituía a unidade.

Antes de o fazer, é uma boa ideia comentar o dispositivo RAID no ficheiro /etc/fstab para que o Ubuntu não tente montá-lo automaticamente no próximo arranque, porque pode falhar e forçá-lo a entrar no modo de recuperação devido à matriz RAID degradada. Isto pode não ser um grande problema se for um sistema de desktop, mas eu executo este servidor sem monitor ou teclado ligado, por isso isto seria um pouco trabalhoso.

Depois de arrancar a máquina com a nova unidade instalada, utilize o lsblk ou algum outro meio para a identificar. Se não alterou nada, provavelmente (mas não necessariamente ) o nome da unidade que substituiu será o mesmo. No meu caso, sim, pelo que 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 uma unidade de trabalho para a nova unidade para ter a certeza de que eram exatamente iguais. Se executar o seu array em dispositivos físicos, pode ignorar este passo.

Utilizei o sgdisk para este efeito, copiando a tabela de partições de /dev/sdc para /dev/sdf. Certifique-se de que substitui os nomes dos dispositivos para corresponder aos seus, conforme apropriado.

Note a ordem aqui: você lista a unidade "para" primeiro! Isto é um pouco contra-intuitivo para mim, mas certifique-se de que o faz correctamente para não ocorrer outra falha de unidade no array ;-)

sgdisk -R /dev/sdf /dev/sdc

Assim, para evitar conflitos de UUID, gere novos UUID para a nova unidade:

sgdisk -G /dev/sdf

E agora chegou finalmente a altura de adicionar a nova unidade ao array e começar a festa de reconstrução! (Ok, não é bem uma festa, na verdade é um processo bastante lento e enervante, uma vez que não quer mesmo que outro drive falhe neste momento. A cerveja pode ajudar, no entanto)

De qualquer forma, para adicionar a nova unidade ao array, emita este comando (mais uma vez, certifique-se de que substitui os nomes dos dispositivos pelos seus, conforme apropriado):

mdadm -–manage /dev/md0 -–add /dev/sdf1

Se tudo correr bem, a unidade será adicionada ao array sem problemas. Creio que é adicionado como um "hot spare" por defeito, mas como este array não tem disco (aquele que falhou), é imediatamente colocado em utilização e o processo de reconstrução será iniciado.

Pode ficar de olho assim:

watch cat /proc/mdstat

Isso provavelmente levará algum tempo; no meu humilde servidor (baseado principalmente em hardware de nível de consumidor e unidades de desktop, atenção), conseguiu atingir pouco menos de 100 MB/s. Tenha em conta que este é RAID-6, pelo que existem 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 quad core AMD A10 9700E (o "E" significa que é um modelo com um clock mais baixo e baixo consumo de energia, ou seja, não é super rápido), só para dar uma ideia do que esperar. Com as nove unidades de 8 TB na minha configuração, a reconstrução completa demorou pouco mais de 24 horas.

Durante a reconstrução, pode montar o sistema de ficheiros no array e utilizá-lo normalmente, se desejar, mas prefiro deixar a reconstrução tratar disso até que esteja concluída. Tenha em mente que se uma unidade falhar, outra poderá falhar em breve, por isso quer que a reconstrução seja feita o mais rapidamente possível, pois não quer realmente que outra unidade falhe durante a mesma. Por isso, não o sobrecarregue com outras E/S que não sejam estritamente necessárias.

Quando terminar, adicione-o novamente ao seu ficheiro /etc/fstab, reinicie e desfrute dos seus ficheiros :-)

Partilhar no BlueskyPartilhar no FacebookPartilhar no LinkedInPartilhar no TumblrPartilhar em XPartilhar no LinkedInFixar no Pinterest

Mikkel Bang Christensen

Sobre o autor

Mikkel Bang Christensen
Mikkel é o criador e proprietário do miklix.com. Tem mais de 20 anos de experiência como programador informático/desenvolvedor de software profissional e trabalha atualmente a tempo inteiro para uma grande empresa europeia de TI. Quando não está a escrever no blogue, dedica o seu tempo livre a um vasto leque de interesses, passatempos e actividades, que podem, em certa medida, refletir-se na variedade de tópicos abordados neste sítio Web.