Bitrot, jakožto myšlenka jednoho převráceného bitu, který zůstane nedetekován, je pravděpodobně mýtus založený na špatné interpretaci běžné specifikace HDD 1 nečitelný bit na každých 1014 bitů (nebo někdy 1015). To je statistika, která se týká bitů, které nelze přečíst vůbec. Možná to znamená, že každých 400 PB je nečitelný sektor o velikosti 512 bajtů. Možná výrobci pevných disků jednoduše odkazují na váš standardní nečitelný sektor, který se zobrazuje ve SMART. Představa, že se jeden bit může převrátit a nějak proklouznout přes všechny vrstvy hardwarové a softwarové kontroly parity, je dost nepravděpodobná a nikdy jsem neviděl žádná empirická data ani jediný zdokumentovaný případ.
Jsou ale i jiné typy hniloby dat, ke kterým může docházet na různých úrovních. Ale proč mluvit o teoriích a anekdotách? Jsme přece datoví skladníci, ne?“
Vzal jsem 70 TB dat (asi 300 000 souborů) a uložil dvě kopie na samostatné sady pevných disků. Jedna sada šla do studeného úložiště, druhá sada byla aktivně používána a přesouvána/kopírována mezi různými disky a souborovými systémy. Sada v chladicím úložišti se jednou ročně roztočila, aby se neusazovala ložisková kapalina. Aktivní sada byla vcelku přesunuta/kopírována možná celkem pětkrát (řekněme 350 TB přenosů). Veškerá paměť RAM byla jiná než ECC. Disky byly spotřebitelské modely v kombinaci všech značek. Aktivní sada strávila jeden rok v ZFS pod FreeBSD (když jsem se cítil obzvlášť paranoidní ohledně bitrotu a chtěl CRC souborů), zbytek času v NTFS pod Windows 7.
Po 7 letech jsem provedl kontrolu MD5 na obou sadách dat. Neshodovalo se 12 souborů.
Soubor 1 – soubor s herními daty, 2 KB. Stejná velikost, výrazně odlišný obsah a aktivní kopie měla novější datum. Vypadá jako soubor herní mezipaměti a byl předmětem modifikace samotnou hrou. Bez poškození.
Soubor 2 – Záložní soubor služby Steam, 832 MB. Identická velikost, výrazně odlišný obsah a aktivní kopie byla o 2 hodiny novější. Vypadá to, že to byla jednoduše novější záloha, kterou jsem vytvořil. Žádné poškození.
Soubor 3 – Video, 399 MB. Záložní kopie má prvních 64K nahrazeno nulou a nepřehrává se. Identická velikost a datum.
Soubor 4 – Video, 19 MB. Záložní kopie má prvních 64K nahrazeno částí textu, který byl kdysi v mé schránce poznámkového bloku, a nepřehrává se. Identická velikost a datum.
Soubor 5 – Video, 11,7 GB. Soubory se liší o 232 bajtů na offsetu 9 693 699 010. Oba obsahují nerozlišitelná komprimovaná data. Obě videa se přehrávají.
Soubor 6 – Video, 2,9 GB. Soubory se liší o 251 bajtů na offsetu 1 039 651 777. Oba obsahují nerozlišitelná komprimovaná data. Obě videa se přehrávají. Identická velikost a datum.
Soubor 7 – Video, 9,4 GB. Soubory se liší o 47 bajtů na offsetu 3 976 714 817. Oba obsahují nerozlišitelná komprimovaná data. Obě videa se přehrávají. Identická velikost a datum.
Soubor 8 – Video, 4,6 GB. Soubory se liší o 232 bajtů na offsetu 627 313 318. Oba obsahují nerozlišitelná komprimovaná data. Obě videa se přehrávají. Identická velikost a datum.
Soubor 9 – Video, 6,2 GB. Soubory se liší o 104 bajty na offsetu 1 496 829 600. Oba obsahují nerozlišitelná komprimovaná data. Obě videa se přehrávají. Stejná velikost a datum.
Soubor 10 – Video, 8,5 GB. Soubory se liší o 512 bajtů na offsetu 6 517 833 728. Oba obsahují nerozlišitelná komprimovaná data. Obě videa se přehrávají. Identická velikost a datum.
Soubor 11 – Video, 1 GB. Aktivní kopie má 54 784 poškozených bajtů na offsetu 684 589 056. Poškozená data obsahují velké kusy nul, opakující se bajty a části textu včetně „root_dataset“, „sync_bplist“, „vdev“ a „zpool create“, které zřejmě souvisejí se systémem ZFS. Identická velikost a datum.
Soubor 12 – Video, 817 MB. Aktivní kopie má 43 520 poškozených bajtů na offsetu 418 578 432. Poškozená data jsou stejného typu jako v souboru 11. Identická velikost a datum.
Takže zde máme 4 typy poškození dat.
Soubory 1 a 2 ve skutečnosti nemají poškození, pouze se nepodařilo je porovnat, protože byly upraveny.
Soubory 3 a 4 měly na začátku souboru nahrazeno přesně 65 536 bajtů zřejmě nějakými náhodnými věcmi z paměti. Vysvětlení pro to nemám, ale muselo se to stát při vytváření zálohy, protože aktivní verze byla stále dobrá. Mohlo to být způsobeno tím, že jsem použil SuperCopier, který asi není úplně bez chyb. Jednou jsem viděl, že přepsal soubor, protože dlouhý název jednoho souboru ve frontě se shodoval s názvem souboru 8.3 v cíli, ale to je dost vzácný případ. Nevím to jistě.
Soubory 5-10 mají všechny stejný typ poškození. Malý kousek souvislých dat na náhodném místě souboru se změnil na podobně vypadající řetězec dat. Je příliš malý na to, aby se dal zjistit přehráním, takže nevím, která kopie je ta správná. Netuším, co to způsobilo.
Soubory 11 a 12 jsou zjevně poškozené tím, že byly uloženy pod ZFS. Každý týden jsem spouštěl scrub a FreeBSD vždy našlo něco „špatného“ a opravilo to. Nebylo mi jasné, co je to za chyby a proč se objevují, ale měl jsem z toho špatný pocit. Na FreeBSD jsem přešel především kvůli CRC souborů v ZFS, ale po nějaké době jsem si řekl, že kdyby se v NTFS všude objevovaly poškozené soubory, věděl by o tom celý svět. Ale hlavním důvodem, proč jsem přešel zpět na Windows, bylo to, že se mi nelíbilo rozhraní FreeBSD.
Setkal jsem se s pátým typem poškození. Na většině starých 1,5TB disků Seagate v chladírně se začaly objevovat vadné sektory. Bylo to zachyceno při každoroční kontrole roztočení a disky byly vyměněny dříve, než na nich došlo k poškození jakýchkoli dat.
Stále uchovávám záznam MD5 hash záloh, ale o bitrot se už nestarám. Nevěřím, že existuje jev, který tu a tam tajně převrací jednotlivé bity. Kdyby to bylo skutečné, měl bych mezi sadami vidět aproximaci 28 izolovaných převrácených bitů.
Praktická rada: doporučuji uchovávat zálohu všeho mimo pracoviště plus další zálohu důležitých věcí, jako jsou rodinné fotografie. Pravidelně se ujistěte, že zálohy lze obnovit. Doporučuji také vytvářet seznamy souborů, abyste v případě poruchy disku věděli, co je třeba obnovit, a hashe souborů, abyste mohli odhalit vzácné případy poškození souborů. RAID nedoporučuji pro nic, co souvisí se zálohováním.
Osobně si myslím, že strategie zálohování 3-2-1 je trochu těžkopádná na to, aby se používala ve všech případech – přece nebudu uchovávat 3 kopie nějakého starého ISO Linuxu.
.