Bitrot, som idéen om en enkelt vendt bit, der ikke bliver opdaget, er sandsynligvis en myte baseret på en fejllæsning af den almindelige HDD-specifikation på 1 ulæselig bit hver 1014 bit (eller nogle gange 1015). Det er en statistik, der henviser til bits, der slet ikke kan læses. Måske betyder det, at du får en ulæselig 512-byte sektor hver 400 PB. Måske henviser harddiskproducenterne blot til din standard ulæselige sektor, som dukker op i SMART. Tanken om, at en enkelt bit kan flippe og på en eller anden måde slippe igennem alle lag af hardware- og softwareparitetskontrol er temmelig usandsynlig, og jeg har aldrig set nogen empiriske data eller et eneste dokumenteret tilfælde af det.

Men der er andre typer af datarot, der kan ske på forskellige niveauer. Men hvorfor snakke teorier og anekdoter? Vi er datahoarders, ikke sandt?

Jeg tog 70 TB data (ca. 300.000 filer) og lagrede to kopier på separate sæt harddiske. Det ene sæt gik i kold opbevaring, det andet sæt blev brugt aktivt og flyttet/kopieret rundt mellem forskellige drev og filsystemer. Sættet på kold opbevaring blev drejet op en gang om året for at holde lagervæsken fra at sætte sig. Det aktive sæt blev flyttet/kopieret rundt i sin helhed måske 5 gange i alt (lad os sige 350 TB overførsler). Al RAM var ikke-ECC. Drevene var forbrugermodeller i en blanding af alle mærker. Det aktive sæt tilbragte et år i ZFS under FreeBSD (da jeg følte mig særligt paranoid over for bitrot og ønskede fil CRC’er), resten af tiden i NTFS under Windows 7.

Efter 7 år kørte jeg en MD5-kontrol på begge datasæt. Der var 12 filer, der ikke stemte overens.

Fil 1 – Spildatafil, 2 KB. Identisk størrelse, væsentligt forskelligt indhold, og den aktive kopi havde en nyere dato. Det ligner en spilcachefil og var genstand for ændringer af spillet selv. Ingen skade.

Fil 2 – Steam-backupfil, 832 MB. Identisk størrelse, væsentligt forskelligt indhold, og den aktive kopi var 2 timer nyere. Ser ud til, at det blot var en nyere sikkerhedskopi, som jeg lavede. Ingen skade.

Fil 3 – Video, 399 MB. Sikkerhedskopi har de første 64K erstattet med nulls, og afspilles ikke. Identisk størrelse og dato.

Fil 4 – Video, 19 MB. Sikkerhedskopi har de første 64K erstattet med en del af en tekst, der engang var i mit notepad-klipboard, og afspilles ikke. Identisk størrelse og dato.

Fil 5 – Video, 11,7 GB. Filerne adskiller sig med 232 bytes ved offset 9.693.699.010. Begge indeholder komprimerede data, der ikke kan skelnes fra hinanden. Begge videoer afspilles.

Fil 6 – Video, 2,9 GB. Filerne adskiller sig med 251 bytes ved offset 1.039.651.777. Begge indeholder komprimerede data, der ikke kan skelnes fra hinanden. Begge videoer afspilles. Identisk størrelse og dato.

Fil 7 – Video, 9,4 GB. Filerne adskiller sig med 47 bytes ved offset 3.976.714.817. Begge indeholder komprimerede data, der ikke kan skelnes fra hinanden. Begge videoer afspilles. Identisk størrelse og dato.

Fil 8 – Video, 4,6 GB. Filerne adskiller sig med 232 bytes ved offset 627.313.318. Begge indeholder komprimerede data, der ikke kan skelnes fra hinanden. Begge videoer afspilles. Samme størrelse og dato.

Fil 9 – Video, 6,2 GB. Filerne adskiller sig med 104 bytes ved offset 1.496.829.600. Begge indeholder komprimerede data, der ikke kan skelnes fra hinanden. Begge videoer afspilles. Identisk størrelse og dato.

Fil 10 – Video, 8,5 GB. Filerne adskiller sig med 512 bytes ved offset 6.517.833.728. Begge indeholder komprimerede data, der ikke kan skelnes fra hinanden. Begge videoer afspilles. Identisk størrelse og dato.

Fil 11 – Video, 1 GB. Aktiv kopi har 54.784 korrupte bytes ved offset 684.589.056. Korrupte data omfatter store stykker nul, gentagende bytes og tekstsektioner, herunder “root_dataset”, “sync_bplist”, “vdev” og “zpool create”, som ser ud til at være ZFS-relaterede. Identisk størrelse og dato.

Fil 12 – Video, 817 MB. Aktiv kopi har 43.520 korrupte bytes ved offset 418.578.432. Korrupte data er af samme type som dem, der blev fundet i fil 11. Identisk størrelse og dato.

Så vi har 4 typer af datakorruption her.

Filer 1 og 2 har ikke rigtig korruption, de passede bare ikke sammen, fordi de var blevet ændret.

Filer 3 og 4 havde præcis 65.536 bytes erstattet i starten af filen med tilsyneladende nogle tilfældige ting fra hukommelsen. Jeg har ikke nogen forklaring på dette, men det må være sket, da der blev taget en sikkerhedskopi, for den aktive version var stadig god. Det kan have været fordi jeg brugte SuperCopier, som nok ikke er helt fejlfri. En enkelt gang oplevede jeg, at den overskrev en fil, fordi det lange filnavn på en fil i køen passede med 8.3-filnavnet på en fil på destinationen, men det er et ret sjældent tilfælde. Jeg ved det ikke med sikkerhed.

Filer 5-10 har alle den samme type korruption. Et lille stykke sammenhængende data på et tilfældigt sted i filen blev ændret til en datastreng, der ligner hinanden. Den er for lille til at blive opdaget ved afspilning, så jeg ved ikke, hvilken der er den gode kopi. Jeg aner ikke, hvad der har forårsaget dette.

Filer 11 og 12 har tydeligvis skader fra at være gemt under ZFS. Jeg kørte en scrub hver uge, og FreeBSD ville altid finde noget “forkert” og rette det. Det var ikke klart for mig, hvad disse fejl var, eller hvorfor de opstod, men det gav mig et dårligt indtryk. Jeg skiftede i første omgang til FreeBSD på grund af fil CRC’erne i ZFS, men efter et stykke tid kom jeg til at tænke på, at hvis NTFS fik korrupte filer overalt, ville hele verden vide det. Men hovedårsagen til at jeg skiftede tilbage til Windows var, at jeg ikke kunne lide FreeBSD-grænsefladen.

Jeg stødte på en 5. type korruption. De fleste af de gamle Seagate 1.5TB-drev i kold opbevaring begyndte at udvikle dårlige sektorer. Dette blev opdaget, da jeg kørte den årlige spin-up kontrol, og drevene blev udskiftet, før nogen data på dem blev beskadiget.

Jeg holder stadig en MD5 hash-optegnelse af mine sikkerhedskopier, men jeg bekymrer mig ikke længere om bitrot. Jeg tror ikke på, at der er et fænomen, der i hemmelighed vender enkelte bits her og der. Hvis det var virkeligt, skulle jeg have set ca. 28 isolerede flippede bits mellem sættene.

For praktiske råd, anbefaler jeg at holde en offsite backup af alt plus en ekstra backup af vigtige ting som familiefotos. Sørg med jævne mellemrum for, at dine sikkerhedskopier kan gendannes. Jeg anbefaler også, at du genererer fillister, så du har en måde at vide, hvad der skal gendannes, når der er en drevfejl, og filhashes, så du kan opdage sjældne tilfælde af filkorruption. Jeg anbefaler ikke RAID til noget som helst i forbindelse med backups.

Jeg synes personligt, at 3-2-1 backup-strategien er lidt for tung at bruge i alle tilfælde – jeg har ikke tænkt mig at gemme 3 kopier af en gammel Linux-ISO.