Isto pode parecer uma forma redonda de gerir as coisas, mas descobri que a melhor forma ( mais eficaz com menos quantidade de recursos ) de gerir dados contra "durabilidade e corrupção de dados" é ambos têm gerenciado corretamente matrizes de discos e têm um esquema de backup e versionamento adequado.
As somas de verificação usadas pelos combos de matriz / sistema de arquivos ZFS e BTRFS podem ativamente encontrar a corrupção de dados sim, mas não necessariamente fornecem a "resposta" do que fazer sobre isso e você ainda pode precisar de seus backups para esse conjunto específico de dados. AND Scrubs em outros arrays pode encontrar a corrupção de dados também para garantir que seus arrays serão reconstruídos. Além disso, os backups de bateria e os bitmaps de intenção de gravação podem manipular o problema do furo de gravação. No geral, os sistemas de armazenamento modernos são extremamente robustos, se implementados corretamente, para lidar com os problemas que você realmente encontrará.
Se a corrupção de dados fosse um grande problema que os combos checksumming array / filesystem fossem a resposta, então TODAS as grandes firmas só usariam e verificariam somar combinações de matriz / sistema de arquivos e na realidade isso NÃO é o caso. Em vez disso, eles têm uma infraestrutura robusta com SANs e comutadores redundantes, backups de bateria, geradores, condicionadores de energia, sistemas de arquivos testados pelo tempo, matrizes bem gerenciadas e backups, backups, backups!
A realidade é que é extremamente raro o fato de que a pouca corrupção de dados conseguirá realmente causar um problema real; e isso acontece tão raramente que, pessoalmente, descobri que é melhor confiar na administração de sistemas adequada para atenuá-la e tentar ativamente gerenciar a própria corrupção de dados. Eu sei que nos últimos 20 anos eu tive alguns arquivos, geralmente arquivos de mídia, que aleatoriamente não funcionam e eu suponho que seja corrupção de dados. Mas nem uma vez eu tive um arquivo que realmente era necessário não funcionar, e se eu fizesse, eu iria apenas para meus backups para esse arquivo, e se isso não funcionasse, minha vida continuaria!
Além disso, não consigo pensar em um único arquivo que seria um fim para minha vida pessoal ou comercial; NENHUM. Um cliente chateado? Uma peça faltante de informação em um processo onde eu sou honesto e só preciso provar isso? Uma memória pessoal corrompida? Todos esses são coisas que eu preferiria evitar, mas todas essas coisas valem apenas uma quantia limitada do meu tempo e dinheiro para mitigar, já que a chance está próxima de 0, o que realmente acontecerá com a corrupção de dados ... NUNCA.
A questão é que, na minha opinião, a melhor coisa que você pode fazer para "Gerenciar a durabilidade dos dados / corrupção de arquivos" para configurações menores é:
- Execute seus arrays como isso faz sentido para suas circunstâncias
- Esfregue-os REGULARMENTE para ajudar a garantir recriações adequadas em caso de falha da unidade
- Use controladores de hardware apoiados por bateria ou bitmaps de intenção de gravação para matrizes de software
- Use matrizes de não paridade, se possível, para evitar falhas de reconstrução, se um URE ou algo acontecer entre scrubs
- E, acima de tudo, coloque em prática um esquema adequado de backup e versão.
A administração de sistemas essencial é o que lida com o problema de corrupção de dados.