Reconstrução RAID em Curso, mas Erros de I/O a Aumentar: O Que Fazer

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.

Se os erros de I/O continuarem a aumentar durante uma reconstrução NAS, reduza as escritas e trate o membro sobrevivente ou o caminho de ligação como instável. Uma percentagem em progresso não torna seguro ignorar o aumento das falhas de leitura.

O objetivo imediato é preservar dados legíveis e identificar se os erros são falhas de mídia, reinicializações de ligação ou um alvo defeituoso. Guarde registos e números de série, confirme o estado do backup e evite reiniciar repetidamente a reconstrução enquanto o conjunto de origem se deteriora.

Erros Crescentes Sobrepõem-se à Barra de Progresso

Uma percentagem de reconstrução responde a quanto do alvo foi processado. Não responde se todas as leituras na origem tiveram sucesso. Compare contadores cumulativos de leitura, escrita, soma de verificação, mídia e timeout de comando em intervalos regulares.

Quando a reconstrução avança enquanto os erros também aumentam, o array pode estar a reconstruir a maioria dos blocos, mas a falhar em regiões específicas. Uma leitura falhada na origem pode importar mais do que milhares de leituras bem-sucedidas quando o nível RAID não tem cópia restante para esse bloco.

Identifique Qual Dispositivo Está a Produzir os Erros

Mapeie cada identificador de registo para um número de série físico. Determine se os erros vêm do membro antigo sobrevivente, do novo alvo ou de um caminho de controlador partilhado. Um erro de escrita no alvo e um erro de leitura na origem exigem decisões diferentes.

Os dados de saúde do disco ajudam a priorizar a investigação. O uso operacional da Backblaze de cinco atributos de aviso SMART foca a atenção nos indicadores de realocação, incorretíveis, timeout, pendentes e offline-incorretíveis, em vez de confiar numa única etiqueta geral de saúde.

Separe Erros de Mídia de Erros de Ligação

Sectores pendentes ou incorretíveis indicam mídia ilegível. O aumento de UDMA CRC, reinicializações de transporte e destacamentos repetidos indicam mais frequentemente um problema no cabo, backplane, ponte, alimentação ou caminho do controlador. Ambos podem interromper a reconstrução, mas trocar discos não resolverá um problema de ligação partilhada.

Uma explicação do contagem de erros UDMA CRC distingue erros de transferência na interface de danos no prato. Guarde a contagem bruta, corrija uma variável de conexão e verifique se o contador continua a aumentar.

Não Continue a Reiniciar uma Reconstrução com Falha

Cada reinício completo relê os membros sobreviventes e pode sobrecarregar as mesmas regiões frágeis sem produzir um resultado melhor. Se a operação abortar repetidamente perto do mesmo endereço ou um segundo disco falhar, pare as tentativas rotineiras de reparação.

Uma reconstrução bloqueada por erros na fonte demonstra o limite central: quando a única fonte boa tem uma leitura irrecuperável, o array não tem outro local para obter os dados em falta. Opções forçadas não podem recriar conteúdo desconhecido.

Escolha entre Continuar, Copiar e Criar Imagem

Condição Direção preferida Porquê
Erros estáveis, reconstrução em progresso Monitorize com carga reduzida A recuperação pode completar normalmente
Erros de ligação aumentam, mídia estável Estabilize o cabo/baía/controlador A falha pode estar fora do disco
Erros na mídia de origem aumentam Copie primeiro os dados críticos legíveis A redundância restante está a enfraquecer
Abortos repetidos na mesma faixa Pare as tentativas cegas de reconstrução Área persistente ilegível
Segundo membro desconecta-se ou falha Considere o fluxo de trabalho de criação de imagem/recuperação O array pode exceder a tolerância a falhas

Se os dados forem insubstituíveis e o backup não estiver verificado, criar imagens dos membros legíveis pode ser mais seguro do que permitir outra reconstrução automática. Um fluxo de trabalho orientado para recuperação de falha do segundo disco durante a reconstrução enfatiza a paragem das tentativas de reparação intensivas em escrita quando o conjunto sobrevivente está instável.

Reduza o Trabalho em Primeiro Plano Sem Ocultar o Incidente

Pare backups, indexação de mídia, downloads, máquinas virtuais e outras escritas evitáveis. Mantenha apenas os serviços necessários para copiar dados críticos ou monitorizar o array. Reduzir a carga de trabalho pode diminuir a fila e facilitar a interpretação do momento dos erros.

Não limpe registos, reinicie contadores SMART ou reinicie repetidamente antes de capturar evidências. Uma reinicialização pode alterar nomes de dispositivos e apagar a sequência que mostra qual membro falhou primeiro.

O Que Capturar Antes de Desligar

  • Estado do array, nível RAID, funções dos membros, alvo da reconstrução e contadores exatos de progresso
  • Cada modelo de disco, número de série, baía, porta do controlador e identificador atual do dispositivo
  • Eventos do kernel ou controlador cobrindo a primeira falha até ao último erro de E/S
  • Valores brutos SMART de mídia, tempo limite, temperatura e erros de interface
  • Lista de ficheiros ou intervalos de blocos ilegíveis e o estado da última cópia de segurança verificada

Este registo suporta um teste controlado de cabo, substituição de disco, clonagem ou recuperação profissional sem adivinhar qual membro continha os dados mais recentes.

Exigir um Seguimento Estável Após Qualquer Intervenção

Após substituir um cabo, mover um disco com número de série confirmado ou reduzir a carga de trabalho, reinicie apenas a linha de base de comparação relevante e observe se há recorrência. Uma melhoria temporária não prova que a falha subjacente desapareceu.

O array deve completar a recuperação, voltar à totalidade dos membros e passar numa verificação de integridade posterior sem novos erros de E/S. Até que as três condições se mantenham sob uma carga de trabalho representativa normal, mantenha o incidente aberto com segurança e retenha os registos capturados.

Perguntas Frequentes

Posso deixar a reconstrução terminar se aparecerem apenas alguns erros?

Só quando os erros forem compreendidos, estáveis e os dados estiverem copiados. O aumento dos erros de leitura da fonte ou reinicializações repetidas são um sinal de escalada mesmo quando a percentagem alvo continua a subir.

Devo substituir o disco com a contagem SMART mais alta?

Não automaticamente. Confirme se os erros seguem o disco com número de série ou permanecem na sua baía e caminho de conexão. Substituir o membro errado durante a operação degradada pode destruir a fonte válida restante.

Pode uma reconstrução concluída ainda conter ficheiros danificados?

Sim. Algumas implementações podem concluir enquanto reportam setores irrecuperáveis ou ficheiros afetados. Reveja sempre o relatório final de erros e execute uma verificação de integridade após o array voltar a um estado estável.

A Condição de Paragem

Quando os erros de E/S aumentam durante a reconstrução, proteja os dados legíveis antes de tentar concluir. Continue apenas depois de provar que o conjunto de origem e o caminho de conexão estão estáveis o suficiente para fornecer todos os blocos restantes.

Suporte e Dicas

Mais para Ler

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.