Bitrot, als het idee van een enkele omgedraaide bit die onopgemerkt blijft, is waarschijnlijk een mythe die is gebaseerd op een verkeerde lezing van de gemeenschappelijke HDD-specificatie van 1 onleesbare bit om de 1014 bits (of soms 1015). Dat is een statistiek die verwijst naar bits die helemaal niet kunnen worden gelezen. Misschien betekent het dat je elke 400 PB een onleesbare 512 byte sector krijgt. Misschien verwijzen de fabrikanten van de harde schijf gewoon naar de standaard onleesbare sector die in SMART verschijnt. Het idee dat een enkele bit kan flippen en op de een of andere manier door elke laag van hardware en software pariteitscontrole kan glippen is behoorlijk ongeloofwaardig en ik heb nog nooit enige empirische gegevens of een enkel gedocumenteerd geval ervan gezien.
Maar er zijn andere soorten gegevensrot die op verschillende niveaus kunnen gebeuren. Maar waarom praten over theorieën en anekdotes? We zijn toch datahoarders?
Ik nam 70 TB aan gegevens (ongeveer 300.000 bestanden) en sloeg twee kopieën op aparte sets harde schijven op. Eén set ging naar de koude opslag, de andere set werd actief gebruikt en verplaatst/gekopieerd tussen verschillende schijven en bestandssystemen. De set in de koude opslag werd één keer per jaar gedraaid om te voorkomen dat de lagervloeistof zou bezinken. De actieve set werd in zijn geheel misschien 5 keer verplaatst/gekopieerd in totaal (zeg, 350 TB aan overdrachten). Alle RAM was niet-ECC. De schijven waren consumentenmodellen, een mix van alle merken. De actieve set stond een jaar in ZFS onder FreeBSD (toen ik me bijzonder paranoïde voelde over bitrot en CRC’s van bestanden wilde hebben), de rest van de tijd in NTFS onder Windows 7.
Na 7 jaar voerde ik een MD5-controle uit op beide datasets. Er waren 12 bestanden die niet overeenkwamen.
Bestand 1 – Spel data bestand, 2 KB. Identieke grootte, significant verschillende inhoud, en de actieve kopie had een nieuwere datum. Het lijkt op een spel cache bestand en was onderhevig aan wijzigingen door het spel zelf. Geen schade.
Bestand 2 – Steam back-up bestand, 832 MB. Identieke grootte, significant andere inhoud, en de actieve kopie was 2 uur nieuwer. Het lijkt erop dat het gewoon een nieuwere backup was die ik maakte. Geen schade.
Bestand 3 – Video, 399 MB. Backup kopie heeft eerste 64K vervangen door nullen, en speelt niet af. Identieke grootte en datum.
Bestand 4 – Video, 19 MB. Bij de reservekopie is de eerste 64K vervangen door een gedeelte van een tekst die ooit op mijn kladblok stond, en speelt niet af. Identieke grootte en datum.
Bestand 5 – Video, 11.7 GB. De bestanden verschillen 232 bytes op offset 9,693,699,010. Beide bevatten niet te onderscheiden gecomprimeerde data. Beide video’s spelen af.
Bestand 6 – Video, 2.9 GB. De bestanden verschillen met 251 bytes op offset 1.039.651.777. Beide bevatten niet te onderscheiden gecomprimeerde data. Beide video’s spelen af. Identieke grootte en datum.
Bestand 7 – Video, 9.4 GB. Bestanden verschillen met 47 bytes op offset 3,976,714,817. Beide bevatten niet te onderscheiden gecomprimeerde data. Beide video’s spelen af. Identieke grootte en datum.
Bestand 8 – Video, 4.6 GB. Bestanden verschillen met 232 bytes op offset 627.313.318. Beide bevatten niet te onderscheiden gecomprimeerde data. Beide video’s spelen af. Identieke grootte en datum.
Bestand 9 – Video, 6.2 GB. Bestanden verschillen 104 bytes op offset 1.496.829.600. Beide bevatten niet te onderscheiden gecomprimeerde data. Beide video’s spelen af. Identieke grootte en datum.
Bestand 10 – Video, 8.5 GB. De bestanden verschillen 512 bytes op offset 6.517.833.728. Beide bevatten niet te onderscheiden gecomprimeerde data. Beide video’s spelen af. Identieke grootte en datum.
Bestand 11 – Video, 1 GB. Actieve kopie heeft 54.784 corrupte bytes op offset 684.589.056. Corrupte data bevat grote stukken nulls, herhalende bytes, en delen van tekst inclusief “root_dataset”, “sync_bplist”, “vdev” en “zpool create” die ZFS gerelateerd lijken te zijn. Identieke grootte en datum.
Bestand 12 – Video, 817 MB. Actieve kopie heeft 43.520 corrupte bytes op offset 418.578.432. Corrupte data is van hetzelfde type als gevonden in bestand 11. Identieke grootte en datum.
Dus we hebben 4 soorten data corruptie hier.
Bestanden 1 en 2 hebben niet echt corruptie, ze komen gewoon niet overeen omdat ze gewijzigd zijn.
Bestanden 3 en 4 hadden precies 65.536 bytes vervangen aan het begin van het bestand met blijkbaar wat willekeurig spul uit het geheugen. Ik heb hier geen verklaring voor, maar het moet gebeurd zijn toen de backup werd gemaakt, want de actieve versie was nog goed. Het kan ook komen doordat ik SuperCopier gebruikte, dat waarschijnlijk niet helemaal bug-vrij is. Eén keer heb ik gezien dat het een bestand overschreef omdat de lange bestandsnaam van een bestand in de wachtrij overeenkwam met de 8.3 bestandsnaam van een bestand op de bestemming, maar dat is een vrij zeldzaam geval. Ik weet het niet zeker.
Bestanden 5-10 hebben allemaal dezelfde soort corruptie. Een klein stukje aaneengesloten data op een willekeurige plaats in het bestand is veranderd in een zelfde soort data. Het is te klein om te zien bij het afspelen, dus ik weet niet welke de goede kopie is. Geen idee wat dit veroorzaakt heeft.
Bestanden 11 en 12 hebben duidelijk schade van onder ZFS opgeslagen te zijn. Ik voerde elke week een scrub uit en FreeBSD vond altijd wel iets “fout” en herstelde het. Het was me niet duidelijk wat deze fouten waren of waarom ze optraden, maar het gaf me een slecht gevoel. Ik schakelde over naar FreeBSD in de eerste plaats voor de CRC’s van ZFS, maar na een tijdje begon ik te denken dat als NTFS overal corrupte bestanden zou krijgen, de hele wereld dat zou weten. Maar de belangrijkste reden dat ik terug ben gegaan naar Windows was omdat de FreeBSD interface me niet beviel.
Ik kwam wel een 5e soort corruptie tegen. De meeste van de oude Seagate 1.5TB schijven in de koude opslag begonnen slechte sectoren te ontwikkelen. Dit werd ontdekt toen ik de jaarlijkse spin-up controle uitvoerde, en de schijven werden vervangen voordat er gegevens beschadigd waren.
Ik houd nog steeds een MD5 hash record bij van mijn back-ups, maar ik maak me geen zorgen meer over bitrot. Ik geloof niet dat er een fenomeen is dat stiekem individuele bits hier en daar omdraait. Als het echt was, had ik ongeveer 28 geïsoleerde omgedraaide bits moeten zien tussen de sets.
Voor praktisch advies, raad ik aan om een offsite back-up van alles te houden plus een extra back-up van belangrijke dingen zoals familiefoto’s. Controleer regelmatig of uw back-ups kunnen worden hersteld. Ik raad ook aan om bestandslijsten te maken, zodat je weet wat er hersteld moet worden als er een schijf kapot gaat, en hashes van bestanden, zodat je zeldzame gevallen van corruptie kunt opsporen. Ik raad RAID niet aan voor alles wat met backups te maken heeft.
Ik denk persoonlijk dat de 3-2-1 backup strategie een beetje te zwaar is om in alle gevallen te gebruiken – ik ga niet 3 kopieën bewaren van een of andere oude Linux ISO.