Por que é que um conjunto RAID fica inativo após uma falha de energia?

Após uma falha de energia, um conjunto RAID pode permanecer inativo porque os seus metadados foram detetados, mas o sistema não conseguiu iniciá-lo de forma segura com os membros e o estado disponíveis.

O termo “inativo” descreve mais diretamente os arrays md do Linux, embora outras pilhas de armazenamento tenham falhas semelhantes de importação ou ativação. Verifique a deteção do dispositivo, os metadados dos membros, o estado sujo ou degradado, a configuração de arranque e falhas no caminho de energia antes de tentar um arranque forçado.

Compreender o que significa Inativo no RAID do Linux

Um array md inativo pode ter dispositivos e alguma configuração anexados enquanto recusa operações normais de I/O. Não é o mesmo que um array saudável que está apenas desmontado, e os comandos de montagem não podem reparar a etapa de ativação em falta.

Um estado de array inativo configurado mas não ativo, com I/O a retornar erros. Este estado permite que o sistema continue a descobrir ou reconfigurar membros sem fingir que o array está pronto.

Inspecione /proc/mdstat, os detalhes do array e o superbloco de cada membro antes de alterar o estado. O objetivo é perceber por que a ativação parou, não transformar “inativo” em “ativo” sem confirmar o conjunto de membros.

Um ou mais membros podem não ter reaparecido

Uma falha súbita pode expor um cabo de energia marginal, backplane, cabo SATA, porta do controlador ou disco que falha ao inicializar na próxima arranque. O array vê então menos membros do que os metadados indicam que deveriam estar presentes.

O mdadm normalmente compara os dispositivos disponíveis não sobressalentes com a contagem ativa esperada antes de iniciar. Um array pode permanecer parcialmente montado quando os dispositivos esperados estão em falta, mesmo que existam metadados suficientes para criar uma entrada de dispositivo md.

Desligue com segurança se for necessária uma inspeção do hardware, depois verifique os conectores, a rotação, a deteção do controlador, os números de série e os dados SMART. Restaure a conectividade em falta antes de escolher o arranque degradado, porque uma falha transitória no caminho pode ser mais fácil e segura de corrigir do que reconstruir o array.

Um desligamento não limpo pode deixar o array sujo

A perda de energia pode interromper as escritas antes que todos os membros e blocos de paridade atinjam um estado consistente. Os metadados do array registam então que uma ressincronização, reprodução do bitmap, reprodução do diário ou outra ação de consistência é necessária no próximo arranque.

O md do Linux suporta diferentes políticas de consistência após um desligamento inesperado, incluindo ressincronização completa, bitmap de intenção de escrita, diário e registo parcial de paridade. A política de consistência determina quanto trabalho é necessário antes que a redundância possa ser novamente confiável.

Um array sujo mas completo pode arrancar e ressincronizar normalmente. Um array sujo que também está degradado requer muito mais cautela, porque dados em falta e paridade incerta podem eliminar a informação necessária para uma reconstrução fiável.

Paridade suja e degradada pode desencadear uma recusa de segurança

O RAID 5 ou RAID 6 pode ser recusado no arranque quando está tanto sujo como com um membro em falta. A recusa protege contra um estado em que a paridade pode estar desatualizada e os dados ausentes não podem ser verificados contra outra cópia.

Existe uma proteção de arranque degradado sujo porque forçar essa combinação pode criar corrupção indetetável. Portanto, o arranque degradado forçado é uma decisão explícita do administrador e não um comportamento normal de arranque.

Não ultrapasse esta proteção até que o membro em falta, o estado do backup e o histórico de escrita sejam compreendidos. Restaure primeiro o caminho do dispositivo ou clone os membros com falha; se a recuperação tiver de continuar, minimize as escritas e verifique os ficheiros recuperados de forma independente.

A descoberta e configuração no arranque podem estar incompletas

Os discos podem estar todos saudáveis enquanto o arranque ainda não deteta o array porque a descoberta do dispositivo termina após a tentativa de montagem, a configuração não contém a identidade do array ou o initramfs contém definições RAID desatualizadas.

Um ficheiro de configuração RAID pode descrever dispositivos e arrays para que as ferramentas de arranque saibam o que procurar e montar. Registos de configuração do array precisos são especialmente importantes quando a descoberta automática não consegue inferir de forma fiável o conjunto pretendido.

Compare os UUIDs dos membros ativos com a configuração instalada e o ambiente de arranque. Corrija configurações desatualizadas apenas depois de confirmar a identidade real do array; gerar uma nova configuração a partir de um conjunto incompleto de membros pode tornar o próximo arranque consistentemente errado.

Metadados externos podem precisar do seu gestor em espaço de utilizador

Alguns arrays usam formatos de metadados externos geridos pelo espaço de utilizador em vez de serem totalmente geridos pelo kernel. Após uma falha abrupta, o processo do contentor ou monitor pode não ter concluído os reconhecimentos necessários para as alterações de estado dos membros.

Metadados geridos externamente podem suspender a atividade até que o espaço de utilizador reconheça um evento. Um conjunto de componentes inativo pode, portanto, refletir uma etapa de gestão em falta em vez de discos de dados com falha.

Identifique o formato dos metadados antes de aplicar comandos genéricos md. Formatos assistidos por firmware ou contentor podem requerer o monitor apropriado, utilitário do controlador ou fluxo de recuperação NAS para que as atualizações de metadados ocorram na ordem correta.

Recupere na ordem de menor risco

Comece com evidências apenas de leitura: liste dispositivos de bloco por ID estável, mapeie números de série para slots, examine os metadados dos membros, reveja os registos do arranque anterior e verifique se todos os discos esperados estão presentes. Não crie um novo array nem zere superblocos.

Tente a montagem normal da plataforma após corrigir a conectividade e configuração. Use modos apenas de leitura ou leitura automática quando suportados, e reserve as opções de execução degradada ou forçada para casos em que o membro em falta exato e o risco de consistência sejam compreendidos.

Após a recuperação, complete qualquer ressincronização ou limpeza, confirme os backups e investigue a causa da falha. Um UPS, energia e cablagem fiáveis, configuração RAID atual, IDs de dispositivo estáveis e alertas reduzem a probabilidade de que o próximo evento de energia apresente o mesmo estado inativo.