A correção mais importante nesta fonte é que a matriz não permaneceu como um RAID confirmado em que «um disco falhou». Depois de o utilizador arrancar com cada unidade separadamente, ambas funcionavam individualmente. Ao voltar a ligar ambas as unidades, produziu [UU] em /proc/mdstat, o que significa que ambos os membros do RAID 1 estavam presentes e sincronizados nesse momento.
A discussão expandiu-se depois para a instabilidade de SATA/ligação/alimentação, falhas de USB/monitor, arranques em modo de emergência, erros de NFS e o ZimaOS recorrer ao outro slot do sistema. Os dados foram recuperados, mas a fonte nunca prova uma causa final única. Não transforme isto num tutorial simples de «substitua o disco X».
Não clique em Quebrar ou Formatar enquanto ainda for possível recuperar os dados
O primeiro conselho da comunidade estava correto neste ponto de segurança: se os dados forem importantes e o estado real da matriz for desconhecido, as ações destrutivas na interface podem dificultar a recuperação. Faça primeiro uma cópia de segurança dos dados legíveis.
Cada disco funcionou quando testado isoladamente
O autor original desligou as unidades uma de cada vez e afirmou que cada uma permitia um sistema/caminho de dados utilizável. Isso enfraqueceu imediatamente a suposição de que um dos discos tinha avariado fisicamente.
Voltar a ligar ambos produziu uma matriz md [UU] saudável
O estado publicado mostrava md0 : active raid1 ... [2/2] [UU]. Nesse momento, a camada md do Linux considerava ambos os membros presentes.
Por isso, a discussão posterior passou a centrar-se na estabilidade dos cabos, das portas SATA, do controlador, dos adaptadores/backplanes e da alimentação, em vez de se focar apenas nos metadados do RAID.
A instabilidade de SATA/alimentação pode fazer-se passar por uma falha do RAID
Mais tarde, a fonte relatou falhas mais abrangentes que afetavam o comportamento de SATA, USB e do ecrã. As sugestões da comunidade incluíam substituir os cabos SATA, testar portas diferentes, evitar divisores/adaptadores marginais e realizar testes de carga, observando a ocorrência de reinícios de E/S.
Tratava-se de diagnósticos da comunidade, não de um defeito de hardware confirmado pela IceWhale.
Os problemas posteriores do modo de emergência/NFS eram uma camada separada
Após alterações nos cabos e reinícios, o sistema entrou no modo de emergência e apresentou falhas relacionadas com NFS/RPC. As tentativas da comunidade para limpar o estado do NFS ou desativá-lo não resultaram numa reparação confirmada.
Não se deve inferir que o NFS causou a inacessibilidade original do RAID; surgiu mais tarde, num sistema que já apresentava uma instabilidade mais abrangente.
O sistema também recorreu ao outro slot do ZimaOS
O utilizador relatou ter arrancado a partir do Bloco/Partição B em vez da A. O ZimaOS atual utiliza duas partições do sistema para recuperação, pelo que a ativação da alternativa pode indicar que uma das partições do sistema falhou nas verificações de integridade/arranque, e não que os dados do utilizador no RAID tenham desaparecido.
Consulte o modelo atual de recuperação de duas partições do ZimaOS.
O ZimaOS atual tem um fluxo de trabalho oficial de reparação RAID 1
O ZimaOS 1.4.4 adicionou a reparação RAID1 para matrizes degradadas/danificadas e corrigiu a indisponibilidade, durante a recuperação, de discos utilizados anteriormente.
Utilize a funcionalidade oficial de reparação RAID1 antes de aplicar comandos manuais antigos de mutação do mdadm.
Os metadados RAID são mais resilientes nas versões mais recentes do ZimaOS
O ZimaOS 1.6.0 adicionou um mecanismo de gravação de metadados RAID concebido para voltar a identificar e montar automaticamente a matriz original após a reinstalação do sistema operativo ou a substituição do dispositivo. Isto melhora o processo de recuperação em comparação com a era da fonte 1.5.x.
Ordem de recuperação atual mais segura
- Não formate nem desfaça a matriz.
- Identifique os modelos/números de série dos discos e o estado atual do RAID com diagnósticos só de leitura.
- Faça imediatamente uma cópia de segurança dos dados acessíveis.
- Verifique os cabos, as portas, a alimentação, o SMART e os registos de E/S/reposição do kernel.
- Utilize a interface atual de reparação RAID quando a matriz estiver realmente degradada.
- Trate a recuperação da partição do sistema separadamente da recuperação dos dados RAID.
A conversa de recuperação acabou por chegar às opções de reposição/recuperação do ZimaOS
Um estado md [UU] significa que ambos os membros RAID 1 estavam presentes naquele momento
Depois de voltar a ligar ambos os discos, a origem mostrava a matriz ativa com dois membros e [UU]. Isso era uma forte evidência de que o próprio espelho tinha sido remontado com êxito naquele momento.
Não explica por que motivo a matriz tinha anteriormente parecido inacessível, nem por que motivo a instabilidade posterior de SATA/USB/monitor continuou.
Os diagnósticos só de leitura são mais seguros do que os comandos manuais de reparação do mdadm
A comunidade pediu informações sobre o conjunto e o estado antes de sugerir alterações. Essa é a ordem correta: identificar quais os dispositivos que pertencem ao conjunto, se este está ativo/degradado e o que o kernel reporta antes de adicionar/remover membros ou recriar metadados.
Não copie um mdadm --create, um comando de montagem forçada ou de limpeza do superbloco de outro caso Linux para um RAID que contém a única cópia dos seus dados.
Copie os dados importantes assim que o conjunto ficar legível
O utilizador da fonte recuperou o acesso. Nesse momento, a prioridade deve ser copiar os dados insubstituíveis para um armazenamento independente antes de continuar as experiências com cabos, controladores, ranhuras do sistema, NFS ou a reinstalação.
O RAID 1 oferece redundância, mas um anfitrião/controlador instável pode tornar ambos os membros indisponíveis ao mesmo tempo.
Quando surgem problemas de SATA, USB e ecrã em simultâneo, alargue o diagnóstico
Os sintomas posteriores já não correspondiam a uma situação simples de falha de um único disco. A deteção intermitente de SATA, o comportamento do USB e os problemas do monitor/arranque podem apontar para cablagem, alimentação, controlador, firmware da placa-mãe ou outra instabilidade da plataforma.
Teste cabos e uma fonte de alimentação comprovadamente funcionais e simplifique a configuração de hardware antes de reconstruir repetidamente o RAID.
A recuperação da ranhura do sistema e a recuperação do RAID são distintas
A ZimaOS pode arrancar a partir de ranhuras de sistema alternativas para a recuperação do sistema operativo. Reverter para a ranhura B pode reparar ou contornar um problema da ranhura do sistema operativo, mas isso, por si só, não repara um conjunto degradado.
Utilize o modelo atual de recuperação do sistema da ZimaOS quando a ranhura do sistema operativo também estiver com problemas.
Desligue os discos de dados ao reinstalar o sistema operativo, se o plano de recuperação o exigir
A comunidade da fonte recomendou isolar os discos RAID durante uma reinstalação limpa do sistema operativo, para reduzir a probabilidade de selecionar ou modificar a unidade errada. Se o suporte atual da IceWhale fornecer um plano de reinstalação, identifique todos os discos e preserve primeiro os metadados e as cópias de segurança do armazenamento.
Perguntas frequentes sobre a recuperação do RAID 1
Na fonte, foi algum disco definitivamente dado como avariado?
Não. Mais tarde, ambos os discos funcionaram de forma independente e o conjunto apresentou [UU] quando voltou a ser ligado.
A fonte identificou uma causa-raiz final?
Não. Os problemas de RAID, instabilidade de SATA/alimentação, arranque do NFS e das ranhuras do sistema operativo sobrepuseram-se.
A ZimaOS atual permite reparar o RAID1?
Sim. A IceWhale adicionou um procedimento oficial de reparação do RAID1 na versão 1.4.4.
