Bitrot, jako idea pojedynczego odwróconego bitu pozostającego niewykrytym, jest prawdopodobnie mitem opartym na błędnym odczytaniu powszechnej specyfikacji HDD, mówiącej o 1 bicie nieczytelnym na każde 1014 bitów (lub czasami 1015). Jest to statystyka odnosząca się do bitów, których nie można w ogóle odczytać. Być może oznacza to, że co 400 PB trafia się nieczytelny sektor o rozmiarze 512 bajtów. Być może producenci dysków twardych odnoszą się po prostu do standardowego nieczytelnego sektora, który jest wyświetlany w systemie SMART. Pomysł, że pojedynczy bit może się obrócić i w jakiś sposób prześlizgnąć się przez każdą warstwę sprzętowego i programowego sprawdzania parzystości, jest dość nieprawdopodobny i nigdy nie widziałem żadnych danych empirycznych ani pojedynczego udokumentowanego przypadku tego zjawiska.
Ale są też inne rodzaje gnicia danych, które mogą się zdarzyć na różnych poziomach. Ale po co mówić o teoriach i anegdotach? Jesteśmy datahoarders, prawda?
Wziąłem 70 TB danych (około 300 000 plików) i przechowywałem dwie kopie na oddzielnych zestawach dysków twardych. Jeden zestaw trafił do zimnego magazynu, drugi zestaw był aktywnie wykorzystywany i przenoszony/kopiowany pomiędzy różnymi dyskami i systemami plików. Zestaw w zimnym magazynie był obracany raz do roku, aby zapobiec osadzaniu się płynu w łożyskach. Aktywny zestaw był przenoszony/kopiowany w całości może z 5 razy w sumie (powiedzmy 350 TB transferu). Cała pamięć RAM była nie-ECC. Napędy były modelami konsumenckimi wszystkich marek. Aktywny zestaw spędził jeden rok w ZFS pod FreeBSD (kiedy miałem szczególną paranoję na punkcie bitrot i chciałem CRC plików), resztę czasu w NTFS pod Windows 7.
Po 7 latach przeprowadziłem kontrolę MD5 na obu zestawach danych. Było 12 plików, które się nie zgadzały.
Plik 1 – Plik danych gry, 2 KB. Identyczny rozmiar, znacząco różna zawartość, a aktywna kopia miała nowszą datę. Wygląda jak plik pamięci podręcznej gry i podlegał modyfikacjom przez samą grę. Brak uszkodzeń.
Plik 2 – Plik kopii zapasowej Steam, 832 MB. Identyczny rozmiar, znacząco różna zawartość, a aktywna kopia była o 2 godziny nowsza. Wygląda na to, że była to po prostu nowsza kopia zapasowa, którą wykonałem. Brak uszkodzeń.
Plik 3 – Video, 399 MB. Kopia zapasowa ma pierwsze 64K zastąpione zerami i nie odtwarza się. Identyczny rozmiar i data.
Plik 4 – Wideo, 19 MB. Kopia zapasowa ma pierwsze 64K zastąpione fragmentem tekstu, który był kiedyś w moim schowku w notatniku, i nie odtwarza się. Identyczny rozmiar i data.
Plik 5 – wideo, 11,7 GB. Pliki różnią się o 232 bajty na offsecie 9,693,699,010. Oba zawierają nieodróżnialne skompresowane dane. Oba filmy są odtwarzane.
Plik 6 – Film, 2,9 GB. Pliki różnią się o 251 bajtów na offsecie 1,039,651,777. Oba zawierają nieodróżnialne skompresowane dane. Oba filmy są odtwarzane. Identyczny rozmiar i data.
Plik 7 – Wideo, 9,4 GB. Pliki różnią się o 47 bajtów na offsecie 3,976,714,817. Oba zawierają nieodróżnialne skompresowane dane. Oba filmy są odtwarzane. Identyczny rozmiar i data.
Plik 8 – Wideo, 4,6 GB. Pliki różnią się o 232 bajty na offsecie 627,313,318. Oba zawierają nieodróżnialne skompresowane dane. Oba filmy są odtwarzane. Identyczny rozmiar i data.
Plik 9 – Wideo, 6,2 GB. Pliki różnią się o 104 bajty przy offsecie 1,496,829,600. Oba zawierają nieodróżnialne skompresowane dane. Oba filmy są odtwarzane. Identyczny rozmiar i data.
Plik 10 – Wideo, 8,5 GB. Pliki różnią się o 512 bajtów przy offsecie 6,517,833,728. Oba zawierają nieodróżnialne skompresowane dane. Oba filmy są odtwarzane. Identyczny rozmiar i data.
Plik 11 – Wideo, 1 GB. Aktywna kopia ma 54 784 uszkodzonych bajtów w przesunięciu 684 589 056. Uszkodzone dane zawierają duże fragmenty zer, powtarzające się bajty i fragmenty tekstu, w tym „root_dataset”, „sync_bplist”, „vdev” i „zpool create”, które wydają się być związane z ZFS. Identyczny rozmiar i data.
Plik 12 – Video, 817 MB. Aktywna kopia ma 43,520 uszkodzonych bajtów w miejscu 418,578,432. Uszkodzone dane są tego samego typu jak te znalezione w pliku 11. Identyczny rozmiar i data.
Więc mamy tu 4 rodzaje uszkodzeń danych.
Pliki 1 i 2 tak naprawdę nie są uszkodzone, po prostu nie pasują do siebie, ponieważ zostały zmodyfikowane.
Pliki 3 i 4 miały dokładnie 65 536 bajtów zastąpionych na początku pliku najwyraźniej jakimiś losowymi rzeczami z pamięci. Nie mam na to wyjaśnienia, ale musiało się to stać podczas tworzenia kopii zapasowej, ponieważ aktywna wersja była nadal dobra. Mogło to być spowodowane tym, że używałem SuperCopiera, który prawdopodobnie nie jest całkowicie wolny od błędów. Raz widziałem, jak nadpisał plik, ponieważ długa nazwa pliku w kolejce pasowała do 8.3 nazwy pliku w miejscu docelowym, ale to dość rzadki przypadek. Nie wiem na pewno.
Pliki 5-10 wszystkie mają ten sam typ uszkodzenia. Mały fragment ciągłych danych w losowym miejscu pliku został zmieniony na podobnie wyglądający ciąg danych. Jest on zbyt mały, aby wykryć go podczas odtwarzania, więc nie wiem, która kopia jest tą dobrą. Nie mam pojęcia co to spowodowało.
Pliki 11 i 12 wyraźnie mają uszkodzenia spowodowane przechowywaniem w ZFS. Robiłem scrub co tydzień i FreeBSD zawsze znajdowało coś „nie tak” i naprawiało to. Nie było dla mnie jasne, czym były te błędy ani dlaczego się pojawiały, ale dawało mi to zły nastrój. Przesiadłem się na FreeBSD przede wszystkim ze względu na CRC plików w ZFS, ale po pewnym czasie doszedłem do wniosku, że gdyby NTFS miał wszędzie uszkodzone pliki, cały świat by o tym wiedział. Ale głównym powodem, dla którego przerzuciłem się z powrotem na Windowsa, było to, że nie podobał mi się interfejs FreeBSD.
Napotkałem piąty rodzaj uszkodzenia. Większość starych dysków Seagate 1,5 TB w chłodni zaczęła rozwijać bad sektory. Zostało to wykryte podczas corocznej kontroli rozruchu i dyski zostały wymienione, zanim jakiekolwiek dane na nich zostały uszkodzone.
Wciąż przechowuję zapis MD5 hash moich kopii zapasowych, ale nie martwię się już o bitrot. Nie wierzę w istnienie zjawiska, które potajemnie przerzuca pojedyncze bity tu i tam. Gdyby to było prawdziwe, powinienem był zobaczyć appox 28 izolowanych odwróconych bitów pomiędzy zestawami.
Jeśli chodzi o praktyczne porady, polecam trzymanie offsite kopii zapasowej wszystkiego plus dodatkowej kopii zapasowej ważnych rzeczy, takich jak zdjęcia rodzinne. Okresowo upewniaj się, że kopie zapasowe można przywrócić. Zalecam również generowanie list plików, aby wiedzieć, co należy przywrócić, gdy dysk ulegnie awarii, oraz haseł plików, aby wykryć rzadkie przypadki uszkodzenia plików. Nie zalecam RAID do niczego związanego z kopiami zapasowymi.
Ja osobiście uważam, że strategia tworzenia kopii zapasowych 3-2-1 jest zbyt ciężka do zastosowania we wszystkich przypadkach – nie zamierzam trzymać 3 kopii jakiegoś starego ISO Linuksa.