Como Verificar Somatórios de Verificação Após Substituir um Disco com Falha

Verifique os dados após a substituição de um disco em dois níveis: complete o scrub ou verificação de consistência do próprio array, depois compare os checksums dos ficheiros com um manifesto criado antes da falha ou a partir de uma cópia de segurança confiável.

Uma reconstrução bem-sucedida prova que a redundância foi reconstruída, não que cada ficheiro foi comparado com um valor independente conhecido como bom. O melhor fluxo de trabalho preserva o manifesto original de checksums, verifica a camada de armazenamento, verifica ficheiros críticos e regista qualquer discrepância antes de retomar as escritas normais.

Termine a Reconstrução Antes de Iniciar a Verificação

Confirme primeiro que a substituição é um membro ativo, que o array já não está degradado, e que não houve aumento de erros de leitura, escrita, checksum ou mídia durante a reconstrução. Um alvo que permanece como reserva, pronto ou em reconstrução não está pronto para uma decisão final sobre a integridade dos dados.

Guarde o relatório final da reconstrução e os seriais dos dispositivos. Se a reconstrução registou setores ilegíveis num membro sobrevivente, não esconda esse evento com um ecrã de estado limpo. Um array reconstruído pode ainda conter perda ao nível do ficheiro quando os dados de origem não puderam ser lidos.

Execute a Operação Completa de Integridade do Array

Use a verificação completa suportada pela plataforma: um scrub ZFS ou Btrfs, uma verificação de paridade md, ou a verificação de consistência do controlador de hardware. Isto lê dados que o uso normal pode não tocar e compara-os com checksums, espelhos ou paridade conforme a implementação.

Um resilver e um scrub não são intercambiáveis. A diferença entre scrub e resilver é importante porque a substituição copia os dados necessários para o novo membro, enquanto um scrub examina o pool mais amplo à procura de erros silenciosos.

Use um Manifesto Pré-existente para Prova ao Nível do Ficheiro

Um hash de ficheiro é útil apenas quando pode ser comparado com um valor anterior confiável. Um checksum gerado após a substituição descreve o ficheiro atual, mas não pode provar que o conteúdo permaneceu inalterado desde antes da falha.

Para ficheiros Linux, a verificação do manifesto SHA-256 pode gerar e verificar uma lista com sha256sum. Guarde o manifesto noutro sistema ou numa cópia de segurança imutável para que um incidente de armazenamento não possa alterar silenciosamente tanto o ficheiro como o seu hash esperado.

Verifique um Conjunto Representativo Quando Não Existir Manifesto

Sem hashes anteriores, comece com dados insubstituíveis e estruturalmente sensíveis: dumps de base de dados, arquivos, imagens de máquinas virtuais, catálogos de fotos, contentores encriptados e ficheiros de mídia grandes. Abra ou teste o formato nativo além de calcular um novo hash.

Um resumo ao nível do diretório pode revelar alterações posteriores, mas não é uma referência histórica a menos que seja anterior ao incidente. Técnicas para um inventário de checksum de diretório também mostram por que a ordenação estável e caminhos consistentes são importantes quando muitos ficheiros estão incluídos.

Separe Verificações de Conteúdo das Verificações de Metadados

Hashes de conteúdo normalmente ignoram propriedade, permissões, carimbos de data/hora, ACLs, atributos estendidos, alocação esparsa e relações de hard-link. Um ficheiro pode passar no SHA-256 enquanto o comportamento da aplicação ainda muda porque os metadados foram perdidos ou restaurados de forma diferente.

Para serviços importantes, valide desde a aplicação para fora. Uma verificação de consistência da base de dados ou um teste de arquivo pode encontrar problemas lógicos que um checksum de bloco não detecta.

Investigue Cada Incompatibilidade Antes de a Reescrever

Não regenere imediatamente o manifesto após uma verificação falhada. Preserve o ficheiro incompatível, o resumo esperado, o resumo atual, o caminho, o tamanho, a hora da modificação e os registos de armazenamento. Determine se o ficheiro mudou legitimamente durante a operação degradada.

Uma verificação limpa de seguimento após a reparação é um limite útil: os erros corrigidos devem ser seguidos por outra execução completa que não reporte novos erros. Correções repetidas significam que a causa não foi resolvida.

Construa um Procedimento de Verificação Repetível

1. Congele ou minimize as gravações da aplicação e guarde o estado de reconstrução concluído.
2. Execute a limpeza ou verificação de consistência ao nível do array e guarde o relatório final.
3. Verifique o manifesto de soma de verificação confiável com o mesmo algoritmo e regras de caminho usados originalmente.
4. Valide formatos críticos de aplicação e compare metadados que os hashes de conteúdo omitem.
5. Execute novamente a verificação do armazenamento após qualquer reparação e exija um resultado limpo antes de fechar o incidente.

Armazene o novo relatório de incidente separadamente da linha base da soma de verificação. A linha base deve mudar apenas quando o conteúdo for alterado intencionalmente, não apenas porque um disco de substituição foi instalado.

Guarde uma Nova Linha Base Confiável

Depois de terminar a limpeza e as verificações dos ficheiros, exporte um novo manifesto, relatório do array e inventário dos membros. Identifique isto como a linha base pós-substituição em vez de sobrescrever a evidência anterior, pois ambas as versões ajudam a explicar qualquer discrepância posterior.

Agende a próxima limpeza de rotina e uma amostra menor de soma de verificação enquanto o incidente ainda é recente. Um acompanhamento precoce confirma que a substituição, o caminho do cabo e a redundância restaurada permanecem estáveis sob carga normal.

Perguntas Frequentes

O SHA-256 é melhor que o MD5 para verificações de corrupção acidental?

Ambos podem detetar alterações comuns, mas o SHA-256 é o padrão melhor para um novo manifesto e evita as fraquezas conhecidas de colisão do MD5. A consistência do algoritmo original é importante ao verificar um manifesto existente.

Pode uma limpeza bem-sucedida substituir um manifesto de soma de verificação?

Não. Uma limpeza verifica de acordo com o sistema de ficheiros ou metadados RAID que possui. Um manifesto independente compara o ficheiro atual com um valor armazenado fora do sistema de armazenamento afetado.

Deve cada ficheiro ser aberto manualmente?

Não. Faça o hash do conjunto protegido completo quando for prático, depois realize testes nativos de abertura ou de consistência em formatos de alto valor e numa amostra representativa de ficheiros comuns.

A verificação só está completa em ambas as camadas

Feche o incidente de substituição apenas depois de o array passar por uma operação completa de integridade e os ficheiros críticos corresponderem a referências externas confiáveis. Um número saudável de membros por si só não é um resultado de verificação de conteúdo.