Esta resposta é uma combinação daquela de @ lechlukasz e @ db48x , incorporando também alguns pontos feitos nos comentários, bem como alguns dos meus próprios pensamentos.
O caminho simples a seguir é uma abordagem combinada de sistema de arquivos e metadados separados.
Ao usar um sistema de arquivos que faz hash e validação de dados dinamicamente, como ZFS ou Btrfs (observe que, embora tenham sido feitos grandes avanços, o Btrfs não é considerado pronto para uso de produção no momento), você pode estar razoavelmente Certifique-se de que, se os dados puderem ser lidos no disco sem o erro do sistema operacional, os dados lidos foram gravados no disco da maneira pretendida pelo sistema de arquivos. Ao executar operações periódicas de "limpeza", todos os dados são lidos e verificados com base na idéia do sistema de arquivos de como deveria ser.
No entanto, isso protege apenas contra corrupção no disco (blocos ilegíveis, erros definitivos de gravação de hardware, gravações inválidas que danificam partes dos dados diretamente no dispositivo de bloco etc.). Ele não protege contra um erro de software, operação incorreta do usuário ou software mal-intencionado que funciona através dos recursos pretendidos do sistema operacional para trabalhar com arquivos, supondo que esses recursos estejam livres desses erros.
Para se proteger contra o último, você precisa de outra camada de proteção. A soma de verificação ou o hash de dados na perspectiva de um aplicativo de usuário ajudará a proteger contra muitos dos riscos mencionados acima, mas precisa ser executada separadamente (como uma ação de processo interna no software ou como um processo completamente separado).
Com o hardware de hoje e o que é prático para armazenar grandes quantidades de dados (discos rígidos de prato giratório em oposição a discos de estado sólido / SSDs), até mesmo algoritmos de hash complexos como o SHA1 serão amplamente ligados à E / S - ou seja, a velocidade na qual os dados são hash, será uma função da velocidade de leitura do sistema de armazenamento, e não da capacidade do processador do computador de calcular o hash. Fiz um experimento com a execução de um processo de hash MD5 no espaço do usuário com aproximadamente 150 GB de dados sobre o que em 2012 era um PC de nível intermediário, e ele foi concluído após o exercício do disco basicamente sem interrupção por cerca de 40 minutos. Ao aumentar esses números 100 vezes, você obterá os hashes MD5 de uma coleção de 15 TB em cerca de três dias no mesmo hardware. Adicionando taxa de transferência de leitura (que pode ser facilmente realizada, por exemplo,O RAID 0, por exemplo, é distribuído sem redundância, comumente usado para obter um desempenho mais alto de leitura / gravação, possivelmente em combinação com o RAID 1 que forma o RAID 10 ), o tempo para conclusão pode ser reduzido para a mesma quantidade de dados.
Ao combinar os dois, você obtém o melhor dos dois mundos: o sistema de arquivos garante que o que você recebeu ao ler o arquivo foi o que foi realmente escrito, e que um processo separado de verificação de correção pode ser executado em toda a coleção, garantindo que os dados armazenado ainda corresponde ao que foi ingerido no arquivo morto. Qualquer inconsistência entre os dois (o sistema de arquivos diz que o arquivo está OK, a verificação de correção diz que não) indicará um arquivo que foi modificado fora do modo de operação pretendido do arquivo, mas de dentro das instalações do sistema operacional, solicitando uma restauração de um secundário cópia (backup). Portanto, a verificação da fixidez pode ser executada em um intervalo de tempo mais longo, o que se torna essencial para arquivos muito grandes, mas ainda é garantido que todos os acessos online não sejam corrompidos no hardware se as leituras forem bem-sucedidas. Em princípio, o software de arquivamento pode contar com o sistema de arquivos para relatar inconsistências como erros de leitura e executar uma verificação de correção separada em segundo plano, pois o usuário está trabalhando com o arquivo e exibindo uma mensagem apropriada, indicando que o arquivo não corresponde ao que foi ingerido no arquivo. Usando um sistema de arquivos com hash em bloco, esse esquema teria um impacto mínimo no desempenho percebido, enquanto ainda assegurava que o conteúdo estivesse correto.