Bitrot, som idén om att en enda omvänd bit inte upptäcks, är troligen en myt som bygger på en felaktig tolkning av den vanliga specifikationen för hårddiskar om en oläsbar bit var 1014:e bit (eller ibland 1015). Det är en statistik som avser bitar som inte kan läsas alls. Kanske betyder det att du får en oläsbar sektor på 512 byte var 400 PB. Kanske tillverkarna av hårddiskar helt enkelt hänvisar till din standard oläsbara sektor som visas i SMART. Tanken att en enda bit kan vända och på något sätt smita igenom alla lager av paritetskontroller av hårdvara och mjukvara är ganska osannolik och jag har aldrig sett några empiriska data eller ett enda dokumenterat exempel på det.
Men det finns andra typer av datarot som kan inträffa på olika nivåer. Men varför prata teorier och anekdoter? Vi är väl datahanterare?
Jag tog 70 TB data (cirka 300 000 filer) och lagrade två kopior på separata uppsättningar hårddiskar. Den ena uppsättningen gick till kallförvaring, den andra uppsättningen användes aktivt och flyttades/kopierades runt mellan olika hårddiskar och filsystem. Den uppsättning som låg i kylförvaret snurrades upp en gång om året för att lagervätskan inte skulle sätta sig. Den aktiva uppsättningen flyttades/kopierades runt i sin helhet kanske fem gånger totalt (låt oss säga 350 TB överföringar). Allt RAM-minne var icke-ECC. Drivrutinerna var konsumentmodeller i en blandning av alla märken. Den aktiva uppsättningen tillbringade ett år i ZFS under FreeBSD (när jag kände mig särskilt paranoid när det gällde bitrot och ville ha filernas CRC), resten av tiden i NTFS under Windows 7.
Efter 7 år körde jag en MD5-kontroll på båda uppsättningarna av data. Det fanns 12 filer som inte stämde överens.
Fil 1 – Speldatafil, 2 KB. Identisk storlek, betydligt annorlunda innehåll och den aktiva kopian hade ett nyare datum. Den ser ut som en spelcachefil och var föremål för ändringar av själva spelet. Ingen skada.
Fil 2 – Steam backup-fil, 832 MB. Identisk storlek, betydligt annorlunda innehåll och den aktiva kopian var 2 timmar nyare. Ser ut som om det helt enkelt var en nyare säkerhetskopia som jag gjorde. Ingen skada.
Fil 3 – Video, 399 MB. Säkerhetskopian har de första 64K ersatta med nollor och spelar inte upp. Identisk storlek och datum.
Fil 4 – Video, 19 MB. Säkerhetskopian har de första 64K ersatts med en del av en text som en gång fanns i mitt klippblock i anteckningsblocket, och spelas inte upp. Identisk storlek och datum.
Fil 5 – Video, 11,7 GB. Filerna skiljer sig åt med 232 bytes vid offset 9 693 699 010. Båda innehåller komprimerade data som inte går att särskilja. Båda videorna spelas upp.
Fil 6 – Video, 2,9 GB. Filerna skiljer sig åt med 251 byte vid offset 1 039 651 777. Båda innehåller komprimerade data som inte går att särskilja. Båda videorna spelas upp. Identisk storlek och datum.
Fil 7 – Video, 9,4 GB. Filerna skiljer sig åt med 47 bytes vid offset 3,976,714,817. Båda innehåller oskiljbara komprimerade data. Båda videorna kan spelas upp. Identisk storlek och datum.
Fil 8 – Video, 4,6 GB. Filerna skiljer sig åt med 232 bytes vid offset 627,313,318. Båda innehåller oskiljbara komprimerade data. Båda videorna kan spelas upp. Samma storlek och datum.
Fil 9 – Video, 6,2 GB. Filerna skiljer sig åt med 104 byte vid offset 1 496 829 600. Båda innehåller oskiljbara komprimerade data. Båda videorna kan spelas upp. Identisk storlek och datum.
Fil 10 – Video, 8,5 GB. Filerna skiljer sig åt med 512 bytes vid offset 6,517,833,728. Båda innehåller oskiljbara komprimerade data. Båda videorna spelas upp. Identisk storlek och datum.
Fil 11 – Video, 1 GB. Den aktiva kopian har 54 784 korrupta bytes vid offset 684 589 056. Korrupta data innehåller stora delar av nollor, upprepade bytes och textavsnitt inklusive ”root_dataset”, ”sync_bplist”, ”vdev” och ”zpool create” som verkar vara ZFS-relaterade. Identisk storlek och datum.
Fil 12 – Video, 817 MB. Den aktiva kopian har 43 520 korrupta bytes vid offset 418 578 432. Korrupta data är av samma typ som i fil 11. Identisk storlek och datum.
Så vi har 4 typer av datakorruption här.
Filer 1 och 2 har egentligen ingen korruption, de kunde bara inte matcha eftersom de hade ändrats.
Filer 3 och 4 hade exakt 65 536 bytes ersatta i början av filen med tydligen några slumpmässiga saker från minnet. Jag har ingen förklaring till detta, men det måste ha hänt när säkerhetskopian gjordes eftersom den aktiva versionen fortfarande var bra. Det kan ha berott på att jag använde SuperCopier, som förmodligen inte är helt felfritt. En gång såg jag att den skrev över en fil eftersom det långa filnamnet på en fil i kön stämde överens med 8.3-filnamnet på en fil på destinationen, men det är ett ganska sällsynt fall. Jag vet inte säkert.
Filer 5-10 har alla samma typ av korruption. En liten bit sammanhängande data på en slumpmässig plats i filen ändrades till en liknande datasträng. Den är för liten för att upptäckas genom uppspelning så jag vet inte vilken som är den goda kopian. Ingen aning om vad som orsakade detta.
Filer 11 och 12 har uppenbarligen skador från att ha lagrats under ZFS. Jag körde en scrub varje vecka och FreeBSD hittade alltid något ”fel” och fixade det. Det stod inte klart för mig vad dessa fel var eller varför de uppstod, men det gav mig en dålig känsla. Jag bytte till FreeBSD i första hand för ZFS:s fil-CRC:er, men efter ett tag började jag tänka att om NTFS fick korrupta filer överallt skulle hela världen få veta det. Men huvudskälet till att jag bytte tillbaka till Windows var att jag inte gillade FreeBSD-gränssnittet.
Jag stötte på en femte typ av korruption. De flesta av de gamla Seagate-diskarna på 1,5 TB i kallförvaringen började utveckla dåliga sektorer. Detta upptäcktes när jag körde den årliga spin-up-kontrollen, och enheterna byttes ut innan någon data på dem skadades.
Jag har fortfarande en MD5-hash-inspelning av mina säkerhetskopior, men jag oroar mig inte längre för bitrot. Jag tror inte att det finns ett fenomen som i hemlighet vänder på enskilda bitar här och där. Om det var verkligt borde jag ha sett ungefär 28 isolerade omvända bitar mellan uppsättningarna.
För praktiska råd rekommenderar jag att du har en extern säkerhetskopia av allting plus en extra säkerhetskopia av viktiga saker, t.ex. familjefoton. Kontrollera regelbundet att dina säkerhetskopior kan återställas. Jag rekommenderar också att du genererar fillistor så att du har ett sätt att veta vad som behöver återställas när det blir fel på en enhet, och filhashar så att du kan upptäcka sällsynta fall av filkorruption. Jag rekommenderar inte RAID för något som har med säkerhetskopiering att göra.
Personligen tycker jag att 3-2-1 säkerhetskopieringsstrategin är lite väl tungrodd för att användas i alla fall – jag tänker inte behålla tre kopior av någon gammal Linux-ISO.