Bitrot, come l’idea di un singolo bit capovolto che non viene rilevato, è probabilmente un mito basato su una lettura errata della specifica comune HDD di 1 bit illeggibile ogni 1014 bit (o talvolta 1015). Quella è una statistica che si riferisce a bit che non possono essere letti affatto. Forse significa che si ha un settore illeggibile di 512 byte ogni 400 PB. Forse i produttori di dischi rigidi si stanno semplicemente riferendo al vostro settore illeggibile standard che viene mostrato in SMART. L’idea che un singolo bit possa capovolgersi e in qualche modo scivolare attraverso ogni strato di controllo di parità hardware e software è piuttosto implausibile e non ho mai visto alcun dato empirico o un singolo caso documentato di ciò.

Ma ci sono altri tipi di putrefazione dei dati che possono accadere a vari livelli. Ma perché parlare di teorie e aneddoti? Siamo dei datahoarders, giusto?

Ho preso 70 TB di dati (circa 300.000 file) e ne ho memorizzato due copie su set separati di hard disk. Un set è andato in archiviazione fredda, l’altro set è stato usato attivamente e spostato/copiato tra diversi drive e filesystem. Il set nell’archiviazione a freddo veniva fatto girare una volta all’anno per evitare che il fluido del cuscinetto si depositasse. Il set attivo veniva spostato/copiato nella sua interezza forse 5 volte in totale (diciamo 350 TB di trasferimenti). Tutta la RAM era non-ECC. Le unità erano modelli di consumo in un mix di tutte le marche. Il set attivo ha trascorso un anno in ZFS sotto FreeBSD (quando mi sentivo particolarmente paranoico su bitrot e volevo i CRC dei file), il resto del tempo in NTFS sotto Windows 7.

Dopo 7 anni, ho eseguito un controllo MD5 su entrambi i set di dati. C’erano 12 file che non corrispondevano.

File 1 – File di dati di gioco, 2 KB. Dimensioni identiche, contenuti significativamente diversi, e la copia attiva aveva una data più recente. Sembra un file di cache del gioco ed è stato soggetto a modifiche da parte del gioco stesso. Nessun danno.

File 2 – File di backup di Steam, 832 MB. Dimensioni identiche, contenuti significativamente diversi, e la copia attiva era più recente di 2 ore. Sembra che fosse semplicemente un backup più recente che ho fatto. Nessun danno.

File 3 – Video, 399 MB. La copia di backup ha i primi 64K sostituiti da null, e non funziona. Dimensione e data identiche.

File 4 – Video, 19 MB. La copia di backup ha i primi 64K sostituiti con una sezione di un testo che una volta era nei miei appunti, e non suona. Dimensione e data identiche.

File 5 – Video, 11,7 GB. I file differiscono di 232 byte all’offset 9.693.699.010. Entrambi contengono dati compressi indistinguibili. Entrambi i video giocano.

File 6 – Video, 2,9 GB. I file differiscono di 251 byte all’offset 1.039.651.777. Entrambi contengono dati compressi indistinguibili. Entrambi i video vengono riprodotti. Dimensione e data identiche.

File 7 – Video, 9,4 GB. I file differiscono di 47 byte all’offset 3.976.714.817. Entrambi contengono dati compressi indistinguibili. Entrambi i video vengono riprodotti. Dimensione e data identiche.

File 8 – Video, 4,6 GB. I file differiscono di 232 byte all’offset 627,313,318. Entrambi contengono dati compressi indistinguibili. Entrambi i video vengono riprodotti. Dimensione e data identiche.

File 9 – Video, 6,2 GB. I file differiscono di 104 byte all’offset 1.496.829.600. Entrambi contengono dati compressi indistinguibili. Entrambi i video vengono riprodotti. Dimensione e data identiche.

File 10 – Video, 8,5 GB. I file differiscono di 512 byte all’offset 6.517.833.728. Entrambi contengono dati compressi indistinguibili. Entrambi i video vengono riprodotti. Dimensione e data identiche.

File 11 – Video, 1 GB. La copia attiva ha 54.784 byte corrotti all’offset 684.589.056. I dati corrotti includono grandi pezzi di null, byte ripetuti e sezioni di testo tra cui “root_dataset”, “sync_bplist”, “vdev” e “zpool create” che sembrano essere correlati a ZFS. Dimensione e data identiche.

File 12 – Video, 817 MB. La copia attiva ha 43.520 byte corrotti all’offset 418.578.432. I dati corrotti sono dello stesso tipo di quelli trovati nel file 11. Dimensione e data identiche.

Quindi abbiamo 4 tipi di corruzione dei dati qui.

I file 1 e 2 non hanno davvero corruzione, hanno solo fallito la corrispondenza perché erano stati modificati.

I file 3 e 4 avevano esattamente 65.536 byte sostituiti all’inizio del file con apparentemente della roba casuale dalla memoria. Non ho una spiegazione per questo, ma deve essere successo quando il backup è stato fatto perché la versione attiva era ancora buona. Potrebbe essere stato perché ho usato SuperCopier, che probabilmente non è completamente privo di bug. Una volta l’ho visto sovrascrivere un file perché il nome lungo di un file in coda corrispondeva al nome 8.3 di un file a destinazione, ma è un caso piuttosto raro. Non lo so per certo.

I file 5-10 hanno tutti lo stesso tipo di corruzione. Un piccolo pezzo di dati contigui in un punto casuale del file è stato cambiato in una stringa di dati dall’aspetto simile. È troppo piccolo per essere rilevato in playback, quindi non so quale sia la copia buona. Non ho idea di cosa l’abbia causato.

I file 11 e 12 hanno chiaramente dei danni per essere stati memorizzati sotto ZFS. Ho fatto uno scrub ogni settimana e FreeBSD trovava sempre qualcosa di “sbagliato” e lo sistemava. Non mi era chiaro cosa fossero questi errori o perché si verificassero, ma mi dava una brutta sensazione. Sono passato a FreeBSD in primo luogo per i CRC dei file di ZFS, ma dopo un po’ ho iniziato a pensare che se NTFS avesse avuto file corrotti ovunque il mondo intero l’avrebbe saputo. Ma la ragione principale per cui sono tornato a Windows era perché non mi piaceva l’interfaccia FreeBSD.

Ho incontrato un quinto tipo di corruzione. La maggior parte dei vecchi dischi Seagate da 1,5 TB in magazzino a freddo ha iniziato a sviluppare settori danneggiati. Questo è stato rilevato quando ho eseguito il controllo annuale di spin-up, e i dischi sono stati sostituiti prima che qualsiasi dato su di essi fosse danneggiato.

Tengo ancora un record di hash MD5 dei miei backup, ma non mi preoccupo più del bitrot. Non credo che ci sia un fenomeno che segretamente capovolge singoli bit qua e là. Se fosse stato reale, avrei dovuto vedere circa 28 bit flippati isolati tra i set.

Per un consiglio pratico, consiglio di tenere un backup offsite di tutto più un backup extra di cose importanti come le foto di famiglia. Periodicamente assicuratevi che i vostri backup possano essere ripristinati. Raccomando anche di generare elenchi di file in modo da avere un modo di sapere cosa deve essere ripristinato quando c’è un guasto al disco, e gli hash dei file in modo da poter rilevare i rari casi di corruzione dei file. Non raccomando il RAID per qualsiasi cosa relativa ai backup.

Personalmente penso che la strategia di backup 3-2-1 sia un po’ pesante per essere usata in tutti i casi – non ho intenzione di tenere 3 copie di qualche vecchia ISO di Linux.