Por que a reconstrução de um RAID reinicia após a desconexão de um disco

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Why a RAID Rebuild Restarts After a Disk Disconnects - Zima Store Online

Uma reconstrução pode reiniciar após outro disco se desconectar porque o conjunto de membros confiáveis do array mudou novamente. O controlador pode descartar o progresso parcial e regenerar a redundância a partir de um novo ponto de consistência.

Uma breve desconexão não é inofensiva durante a operação degradada. A resposta correta é identificar qual membro com número de série caiu, preservar os registos, confirmar que o array ainda tem cópias válidas suficientes e parar de experimentar com cabos ou baías até que o estado atual de recuperação seja compreendido.

A Segunda Desconexão Cria um Novo Evento de Recuperação

Uma reconstrução baseia-se num conjunto específico de membros de origem e num disco alvo. Se outro membro de origem desaparecer, mesmo que brevemente, o array já não pode assumir que cada bloco já gravado no alvo corresponde ao conjunto ativo atual. As gravações também podem ter continuado enquanto esse membro estava ausente.

Os controladores lidam com isto de forma diferente. Alguns retomam a partir de um bitmap ou ponto de verificação; outros reiniciam uma reconstrução completa. A discussão sobre reconstrução após reconectar um disco mostra por que remover um membro altera o estado de tolerância a falhas mesmo quando o disco ainda contém a maior parte dos dados antigos.

Metadados Sujos Podem Fazer um Membro Antigo Parecer Obsoleto

Os membros do RAID normalmente armazenam metadados do array que identificam o seu papel e histórico de eventos. Quando um disco desaparece enquanto as gravações continuam, o seu conteúdo torna-se mais antigo do que o array ativo. Reconectá-lo não faz desaparecer essas gravações perdidas, pelo que o controlador deve reconciliar ou sobrescrever as regiões obsoletas.

Um membro do RAID removido temporariamente pode ser reconhecido pelos seus metadados, mas a implementação decide se pode reintegrar diretamente ou se precisa de sincronização. Não presuma que voltar à mesma baía mantém a confiança.

Por que o progresso pode voltar a zero

A percentagem muitas vezes descreve a passagem de recuperação atual, não um registo permanente de todos os blocos alguma vez copiados. Se um membro da fonte mudar de estado, o alvo for reatribuído ou o controlador reassemblar o array, a operação exibida pode reiniciar do zero mesmo que alguns blocos do alvo já correspondam.

No RAID por software, um novo evento degradado pode exigir uma ressincronização completa. Uma segunda reconstrução completa do RAID1 documentada demonstra que, uma vez que um array md entra em estado degradado, pode sincronizar todo o membro em vez de confiar num estado parcial anterior.

Não remova outro disco para testar a teoria

Durante uma reconstrução, cada fonte restante faz parte do único caminho para reconstruir os dados em falta. Remover outro membro para identificação pode exceder a tolerância a falhas do nível RAID ou criar versões concorrentes dos dados. Localize discos pelo número de série e indicadores do invólucro, não por remoção experimental.

Pare os testes de hot-swap até que o array esteja saudável ou copiado para armazenamento seguro. Se suspeitar de um cabo ou baía, recolha primeiro o registo de eventos e planeie uma única alteração controlada com o sistema em estado de repouso quando o hardware não suportar explicitamente serviço online.

Verifique se a reconstrução realmente reiniciou

Compare mais do que a percentagem. Registe o nome da operação, número de série do alvo, contagem de membros da fonte, número do evento ou geração, blocos processados, velocidade atual e tempo estimado de conclusão. Um controlador pode mudar de reconstrução para inicialização de paridade, verificação ou verificação de consistência em segundo plano.

Campo	Mesma operação	Novo evento de recuperação
Número de série do alvo	Inalterado	Diferente ou reclassificado
Blocos processados	Continua a subir	Volta ao início
Conjunto de membros	Estável	Outro disco ausente ou readicionado
Mensagem de registo	Retomar ou continuar	Abortar, reiniciar, reassemblar, nova reconstrução
Estado do array	Degradado/reconstrução	Mais degradado, estrangeiro ou a recuperar

Se o conjunto de membros mudou, trate a nova percentagem como um evento novo. Se apenas a interface foi reiniciada enquanto os contadores continuam, pode ser um problema de visualização em vez de progresso perdido.

Quando um reinício é menos importante do que a queda de um disco

Um reinício planeado não invalida necessariamente uma reconstrução gerida pelo controlador. Muitos controladores mantêm estado suficiente para retomar com segurança. O evento mais grave é perder outro disco de origem ou introduzir uma configuração externa durante ou após o reinício.

Um reinício durante uma reconstrução pode ser recuperável, mas a conclusão segura depende do estado do controlador após a inicialização. Nunca inicialize ou importe uma configuração externa apenas porque a percentagem reiniciou.

O Que Fazer Imediatamente

Pausa as escritas não essenciais e capture os registos do array, do invólucro e do sistema operativo.
Mapeie cada membro ativo, em falta, em reconstrução e sobressalente para um número de série físico.
Confirme que o nível RAID ainda tem membros de origem válidos suficientes para reconstruir os dados.
Verifique os contadores SMART e de erros de ligação no disco que se desligou e no seu caminho de conexão.
Deixe uma reconstrução estável correr sem experiências adicionais com cabos, baias, reinícios ou cargas de trabalho.

Se outra fonte reportar setores ilegíveis ou desconexões repetidas, priorize copiar dados insubstituíveis ou criar imagens dos membros em vez de forçar repetidamente uma reconstrução.

Perguntas Frequentes

Reconectar o mesmo disco vai sempre reiniciar a reconstrução?

Não. Alguns controladores podem reintegrá-lo ou retomar a partir de um bitmap. Outros consideram o membro obsoleto e iniciam a sincronização novamente. O registo de eventos e os dados de geração do membro decidem qual o caso ocorrido.

Uma percentagem de reinício significa que o novo disco foi apagado novamente?

Nem sempre. Pode significar que o controlador iniciou uma nova passagem ou mudou o tipo de operação. Não deduza perda de dados apenas pela percentagem; inspecione a identidade do alvo e as mensagens de evento.

Posso continuar a usar aplicações durante a reconstrução reiniciada?

Pode ser suportado um uso leve, mas reduza escritas evitáveis e trabalhos sensíveis à latência. O array já mostrou um segundo evento de conectividade, por isso a estabilidade e a proteção dos dados têm prioridade sobre o rendimento normal.

A Resposta Prática

Uma reconstrução reinicia porque as suposições de consistência mudaram quando outro membro se desligou. Estabilize o caminho do hardware, verifique o conjunto de origem e permita uma recuperação ininterrupta em vez de testar o array enquanto degradado.