Bitrot, como a ideia de um único bit virado sem ser detectado, é provavelmente um mito baseado numa leitura errada da especificação comum do HDD de 1 bit ilegível a cada 1014 bits (ou às vezes 1015). Essa é uma estatística que se refere a bits que não podem ser lidos de todo. Talvez isso signifique que você recebe um setor de 512 bytes ilegíveis a cada 400 PB. Talvez os fabricantes de discos rígidos estejam simplesmente se referindo ao seu setor padrão não legível que aparece no SMART. A idéia de que um único bit pode virar e de alguma forma deslizar por cada camada de verificação de paridade de hardware e software é bastante implausível e eu nunca vi nenhum dado empírico ou uma única instância documentada dele.

Mas existem outros tipos de apodrecimento de dados que podem acontecer em vários níveis. Mas porquê falar de teorias e anedotas? Nós somos datahoarders, certo?

Peguei 70 TB de dados (cerca de 300.000 arquivos) e armazenei duas cópias em conjuntos separados de discos rígidos. Um conjunto foi para o armazenamento a frio, o outro conjunto foi utilizado activamente e movido/copiado entre diferentes unidades e sistemas de ficheiros. O conjunto em câmaras frigoríficas era girado uma vez por ano para evitar que o fluido dos rolamentos se assentasse. O conjunto ativo foi movido/copiado na sua totalidade talvez 5 vezes no total (digamos, 350 TB de transferências). Toda a RAM era não-ECC. Os acionamentos eram modelos de consumo em uma mistura de todas as marcas. O conjunto ativo passou um ano em ZFS sob FreeBSD (quando eu estava me sentindo particularmente paranóico sobre o bitrot e queria arquivos CRCs), o resto do tempo em NTFS sob Windows 7.

Depois de 7 anos, eu fiz uma verificação MD5 em ambos os conjuntos de dados. Havia 12 arquivos que não combinavam.

Arquivo 1 – Arquivo de dados do jogo, 2 KB. Tamanho idêntico, conteúdo significativamente diferente, e a cópia ativa tinha uma data mais recente. Parece um arquivo de cache do jogo e estava sujeito a modificações pelo próprio jogo. Sem danos.

Arquivo 2 – Arquivo de backup do Steam, 832 MB. Tamanho idêntico, conteúdo significativamente diferente, e a cópia ativa era 2 horas mais nova. Parece que foi simplesmente uma cópia de segurança mais recente que eu fiz. Sem danos.

Arquivo 3 – Vídeo, 399 MB. A cópia de segurança tem os primeiros 64K substituídos por nulos, e não é reproduzida. Tamanho e data idênticos.

Arquivo 4 – Vídeo, 19 MB. A cópia de segurança tem os primeiros 64K substituídos por uma secção de um texto que já esteve no meu bloco de notas, e não toca. Tamanho idêntico e data.

Arquivo 5 – Vídeo, 11.7 GB. Os arquivos diferem em 232 bytes no offset 9.693.699.010. Ambos contêm dados comprimidos indistinguíveis. Ambos os vídeos reproduzem.

Arquivo 6 – Vídeo, 2,9 GB. Os arquivos diferem em 251 bytes no offset 1.039.651.777. Ambos contêm dados compactados indistinguíveis. Ambos os vídeos são reproduzidos. Tamanho e data idênticos.

Arquivo 7 – Vídeo, 9.4 GB. Os arquivos diferem em 47 bytes no offset 3.976.714.817. Ambos contêm dados comprimidos indistinguíveis. Ambos os vídeos são reproduzidos. Tamanho e data idênticos.

Arquivo 8 – Vídeo, 4.6 GB. Os arquivos diferem em 232 bytes no offset 627.313.318. Ambos contêm dados comprimidos indistinguíveis. Ambos os vídeos são reproduzidos. Tamanho e data idênticos.

Arquivo 9 – Vídeo, 6.2 GB. Os arquivos diferem em 104 bytes no offset 1.496.829.600. Ambos contêm dados compactados indistinguíveis. Ambos os vídeos são reproduzidos. Tamanho e data idênticos.

Arquivo 10 – Vídeo, 8.5 GB. Os arquivos diferem em 512 bytes no offset 6.517.833.728. Ambos contêm dados comprimidos indistinguíveis. Ambos os vídeos são reproduzidos. Tamanho e data idênticos.

Arquivo 11 – Vídeo, 1 GB. Cópia ativa tem 54.784 bytes corrompidos no offset 684.589.056. Dados corrompidos incluem grandes pedaços de nulos, bytes de repetição, e seções de texto incluindo “root_dataset”, “sync_bplist”, “vdev” e “zpool create” que parecem ser relacionados a ZFS. Tamanho e data idênticos.

Arquivo 12 – Vídeo, 817 MB. Cópia ativa tem 43.520 bytes corrompidos no offset 418.578.432. Os dados corrompidos são do mesmo tipo dos encontrados no Arquivo 11. Tamanho e data idênticos.

Então nós temos 4 tipos de corrupção de dados aqui.

Arquivos 1 e 2 não têm realmente corrupção, eles simplesmente falharam em corresponder porque foram modificados.

Arquivos 3 e 4 tiveram exatamente 65.536 bytes substituídos no início do arquivo com algumas coisas aparentemente aleatórias da memória. Não tenho uma explicação para isso, mas deve ter acontecido quando o backup foi feito porque a versão ativa ainda era boa. Pode ter sido porque eu usei o SuperCopier, que provavelmente não está completamente livre de bugs. Uma vez eu o vi sobrescrever um arquivo porque o nome longo de um arquivo na fila correspondia ao nome de arquivo 8.3 de um arquivo no destino, mas esse é um caso bem raro. Eu não tenho certeza.

Arquivos 5-10 têm todos o mesmo tipo de corrupção. Um pequeno pedaço de dados contíguos em um lugar aleatório no arquivo foi alterado para uma seqüência de dados de aparência similar. É muito pequeno para ser detectado pela reprodução, então eu não sei qual é a boa cópia. Não faço ideia do que causou isto.

Arquivos 11 e 12 têm claramente danos por estarem armazenados sob ZFS. Eu fazia um scrub todas as semanas e o FreeBSD sempre encontrava algo “errado” e o consertava. Não estava claro para mim o que eram esses erros ou porque eles ocorreram, mas isso me deu uma vibração ruim. Mudei para o FreeBSD em primeiro lugar para os CRCs de arquivos do ZFS, mas depois de um tempo comecei a pensar que se o NTFS estivesse recebendo arquivos corruptos em todos os lugares, o mundo inteiro saberia disso. Mas a principal razão pela qual eu mudei de volta para o Windows foi porque eu não gostava da interface do FreeBSD.

Eu encontrei um 5º tipo de corrupção. A maioria dos antigos drives de 1.5TB da Seagate em câmara fria começou a desenvolver setores ruins. Isto foi detectado quando eu executei a verificação anual de spin-up, e os drives foram substituídos antes que qualquer dado neles fosse danificado.

Eu ainda mantenho um registro MD5 hash dos meus backups, mas eu não me preocupo mais com o bitrot. Eu não acredito que haja um fenômeno que inverta secretamente bits individuais aqui e ali. Se fosse real, eu deveria ter visto appox 28 bits isolados entre os sets.

Para conselhos práticos, eu recomendo manter um backup externo de tudo mais um backup extra de coisas importantes como fotos de família. Periodicamente certifique-se de que os seus backups podem ser restaurados. Eu também recomendo gerar listas de arquivos para que você tenha uma maneira de saber o que precisa ser restaurado quando há uma falha na unidade, e hashes de arquivos para que você possa detectar casos raros de corrupção de arquivos. Eu não recomendo RAID para nada relacionado a backups.

Eu pessoalmente acho que a estratégia de backup 3-2-1 é um pouco pesada para ser usada em todos os casos – Eu não vou manter 3 cópias de alguma ISO.

antiga do Linux.