Bitrot, ca idee a unui singur bit răsturnat care trece nedetectat, este probabil un mit bazat pe o interpretare greșită a specificației comune a HDD-urilor de 1 bit ilizibil la fiecare 1014 biți (sau uneori 1015). Aceasta este o statistică care se referă la biții care nu pot fi citiți deloc. Poate că înseamnă că primești un sector nelizibil de 512 octeți la fiecare 400 PB. Poate că producătorii de hard disk-uri se referă pur și simplu la sectorul standard nelizibil care apare în SMART. Ideea că un singur bit poate să se întoarcă și să se strecoare cumva prin toate straturile de verificare a parității hardware și software este destul de puțin plauzibilă și nu am văzut niciodată date empirice sau un singur caz documentat în acest sens.

Dar există și alte tipuri de putrezire a datelor care se pot întâmpla la diferite niveluri. Dar de ce să vorbim de teorii și anecdote? Suntem datahoarders, nu-i așa?

Am luat 70 TB de date (aproximativ 300.000 de fișiere) și am stocat două copii pe seturi separate de hard disk-uri. Un set a intrat în stocare la rece, celălalt set a fost folosit în mod activ și a fost mutat/copiat între diferite unități și sisteme de fișiere. Setul din stocarea la rece a fost rotit o dată pe an pentru a împiedica lichidul de rulment să se depună. Setul activ a fost mutat/copiat în întregime poate de 5 ori în total (să zicem, 350 TB de transferuri). Toată memoria RAM a fost non-ECC. Unitățile de discuri erau modele de consum dintr-un mix de toate mărcile. Setul activ a petrecut un an în ZFS sub FreeBSD (când mă simțeam deosebit de paranoic în legătură cu bitrot și doream CRC-urile fișierelor), iar restul timpului în NTFS sub Windows 7.

După 7 ani, am efectuat o verificare MD5 pe ambele seturi de date. Au existat 12 fișiere care nu se potriveau.

File 1 – Fișier de date de joc, 2 KB. Dimensiune identică, conținut semnificativ diferit, iar copia activă avea o dată mai nouă. Pare a fi un fișier cache de joc și a fost supus modificării chiar de către joc. Nu există pagube.

File 2 – Fișier de rezervă Steam, 832 MB. Dimensiune identică, conținut semnificativ diferit, iar copia activă era cu 2 ore mai nouă. Se pare că a fost pur și simplu un backup mai nou pe care l-am făcut. Nicio pagubă.

File 3 – Video, 399 MB. Copie de rezervă are primii 64K înlocuiți cu nuli și nu redă. Dimensiune și dată identice.

File 4 – Video, 19 MB. Copia de rezervă are primii 64K înlocuiți cu o secțiune a unui text care a fost cândva în clipboardul meu de notepad, și nu redă. Dimensiune și dată identice.

File 5 – Video, 11,7 GB. Fișierele diferă cu 232 de octeți la offset-ul 9,693,699,010. Ambele conțin date comprimate imposibil de distins. Ambele videoclipuri rulează.

File 6 – Video, 2,9 GB. Fișierele diferă cu 251 de octeți la decalajul 1.039.651.777. Ambele conțin date comprimate nediferențiate. Ambele videoclipuri rulează. Dimensiune și dată identice.

File 7 – Video, 9,4 GB. Fișierele diferă cu 47 de octeți la offset 3,976,714,817. Ambele conțin date comprimate imposibil de distins. Ambele videoclipuri rulează. Dimensiune și dată identice.

File 8 – Video, 4,6 GB. Fișierele diferă cu 232 octeți la offset 627,313,318. Ambele conțin date comprimate imposibil de distins. Ambele videoclipuri rulează. Dimensiunea și data identice.

File 9 – Video, 6,2 GB. Fișierele diferă cu 104 octeți la offsetul 1.496.829.600. Ambele conțin date comprimate nediferențiate. Ambele videoclipuri rulează. Dimensiune și dată identice.

File 10 – Video, 8,5 GB. Fișierele diferă cu 512 octeți la offset 6,517,833,728. Ambele conțin date comprimate imposibil de distins. Ambele videoclipuri rulează. Dimensiune și dată identice.

File 11 – Video, 1 GB. Copia activă are 54.784 octeți corupți la offset 684.589.056. Datele corupte includ bucăți mari de nuli, octeți care se repetă și secțiuni de text, inclusiv „root_dataset”, „sync_bplist”, „vdev” și „zpool create”, care par a fi legate de ZFS. Dimensiune și dată identice.

Fila 12 – Video, 817 MB. Copia activă are 43.520 de octeți corupți la offset 418.578.432. Datele corupte sunt de același tip cu cele găsite în fișierul 11. Mărime și dată identice.

Acum avem 4 tipuri de corupție a datelor aici.

Filele 1 și 2 nu au cu adevărat corupție, pur și simplu nu au reușit să se potrivească pentru că au fost modificate.

Filele 3 și 4 au avut exact 65.536 de octeți înlocuiți la începutul fișierului cu niște chestii aparent aleatorii din memorie. Nu am o explicație pentru acest lucru, dar trebuie să se fi întâmplat atunci când a fost făcută copia de rezervă, deoarece versiunea activă era încă bună. S-ar putea să fi fost din cauză că am folosit SuperCopier, care probabil nu este complet lipsit de erori. O singură dată am văzut că a suprascris un fișier deoarece numele de fișier lung al unui fișier din coada de așteptare se potrivea cu numele de fișier 8.3 al unui fișier de la destinație, dar acesta este un caz destul de rar. Nu știu sigur.

Filele 5-10 au toate același tip de corupție. O mică bucată de date contiguă într-un loc aleatoriu din fișier a fost schimbată cu un șir de date cu aspect similar. Este prea mică pentru a fi detectată prin redare, așa că nu știu care este copia bună. Nu am idee ce a cauzat acest lucru.

Filele 11 și 12 au în mod clar deteriorări din cauza stocării sub ZFS. Am rulat un scrub în fiecare săptămână și FreeBSD găsea întotdeauna ceva „greșit” și îl repara. Nu mi-a fost clar ce erau aceste erori sau de ce au apărut, dar mi-a dat o senzație proastă. Am trecut la FreeBSD în primul rând pentru CRC-urile fișierelor din ZFS, dar după un timp m-am gândit că, dacă NTFS primea fișiere corupte peste tot, întreaga lume ar fi aflat despre asta. Dar motivul principal pentru care am trecut înapoi la Windows a fost că nu mi-a plăcut interfața FreeBSD.

Am întâlnit un al 5-lea tip de corupție. Cele mai multe dintre vechile unități Seagate de 1,5TB din stocarea la rece au început să dezvolte sectoare defecte. Acest lucru a fost detectat atunci când am efectuat verificarea anuală a rotirii, iar unitățile au fost înlocuite înainte ca datele de pe ele să fie deteriorate.

Încă păstrez o înregistrare hash MD5 a copiilor mele de rezervă, dar nu-mi mai fac griji cu privire la bitrot. Nu cred că există un fenomen care să răstoarne în secret biți individuali ici și colo. Dacă ar fi fost real, ar fi trebuit să văd appox 28 de biți răsturnați izolat între seturi.

Pentru un sfat practic, vă recomand să păstrați o copie de rezervă offsite a tuturor lucrurilor, plus o copie de rezervă suplimentară a lucrurilor importante, cum ar fi fotografiile de familie. Periodic, asigurați-vă că backup-urile pot fi restaurate. De asemenea, vă recomand să generați liste de fișiere, astfel încât să aveți o modalitate de a ști ce trebuie restaurat atunci când există o defecțiune a unității, și hașuri de fișiere, astfel încât să puteți detecta cazurile rare de corupție a fișierelor. Nu recomand RAID pentru nimic legat de copiile de rezervă.

Personal cred că strategia de backup 3-2-1 este puțin cam greoaie pentru a fi folosită în toate cazurile – nu am de gând să păstrez 3 copii ale unor vechi ISO-uri Linux.

.