Bitrot は、反転した 1 つのビットが検出されないという考え方で、おそらく 1014 ビット（または時には 1015 ビット）に 1 つの読み取り不能ビットという共通の HDD 仕様の誤読に基づく神話でしょう。 これは、まったく読み取れないビットを指す統計です。 もしかしたら、400PBごとに512バイトの読めないセクターが発生するという意味かもしれません。 ハードディスク・ドライブ・メーカーは、SMARTに表示される標準的な読み取り不可能なセクタを指しているのかもしれません。 1 つのビットが反転して、ハードウェアとソフトウェアのパリティ チェックのすべてのレイヤーをすり抜けるという考えは、かなりありえないことで、私は経験的なデータや文書化された例を見たことがありません。 しかし、なぜ理論や逸話を語るのか？ 私たちはデータ ホルダーですよね。

私は 70 TB のデータ (約 30 万ファイル) を取り、2 つのコピーを別々のハード ドライブ セットに保存しました。 1 つのセットはコールド ストレージに、もう 1 つのセットはアクティブに使用され、異なるドライブとファイルシステム間で移動/コピーされました。 コールドストレージにあるセットは、ベアリング液が沈殿しないように年に1回スピンアップしていました。 アクティブなセットは、合計で5回ほど全体が移動/コピーされました（たとえば、350TBの転送）。 RAMはすべて非ECC。 ドライブはあらゆるブランドのコンシューマーモデルを使用しました。 アクティブなセットは、FreeBSD の ZFS で 1 年間 (bitrot について特に偏執的で、ファイルの CRC を求めていたとき)、残りは Windows 7 の NTFS で過ごしました。

7 年後、両方のデータ セットで MD5 チェックを実行しました。 一致しないファイルが 12 個ありました。

File 1 – ゲーム データ ファイル、2 KB。 サイズが同じで、内容が大幅に異なり、アクティブなコピーの方が日付が新しい。 ゲームのキャッシュファイルのようで、ゲーム自身によって修正されることがあったようです。 ダメージなし。

File 2 – Steam バックアップファイル、832 MB。 サイズは同一、内容は大きく異なり、アクティブなコピーの方が2時間新しい。 単に新しいバックアップを作成しただけのようです。 ダメージはありません。

File 3 – ビデオ、399 MB。 バックアップ・コピーでは、最初の64Kがヌルに置き換えられており、再生されません。 サイズと日付は同じです。

File 4 – Video, 19 MB. バックアップ コピーは、最初の 64K が、かつて私のメモ帳のクリップボードにあったテキストのセクションに置き換えられており、再生されません。 サイズと日付は同じです。

File 5 – Video, 11.7 GB。 オフセット 9,693,699,010 で 232 バイトの違いがあります。 どちらも見分けがつかないほどの圧縮データが含まれています。

File 6 – Video, 2.9 GB. ファイルは、オフセット 1,039,651,777 で 251 バイト異なります。 どちらも区別のつかない圧縮データが含まれています。 どちらのビデオも再生されます。 サイズと日付が同じです。

File 7 – Video, 9.4 GB。 オフセット3,976,714,817で47バイトの差があります。 どちらも見分けがつかないほどの圧縮データが含まれています。 どちらの動画も再生されます。 サイズと日付が同じです。

File 8 – Video, 4.6 GB. オフセット627,313,318で232バイトの差でファイルが異なります。 どちらも見分けがつかないほどの圧縮データが含まれています。 どちらの動画も再生されます。 サイズと日付が同じです。

File 9 – Video, 6.2 GB。 オフセット1,496,829,600で104バイトの差でファイルが異なります。 どちらも見分けがつかないほど圧縮されたデータが入っています。 どちらの動画も再生されます。 サイズと日付が同じです。

File 10 – Video, 8.5 GB。 オフセット6,517,833,728で512バイトだけファイルが異なります。 どちらも見分けがつかないほどの圧縮データが含まれています。 どちらのビデオも再生されます。 サイズと日付が同じです。

File 11 – Video, 1 GB. アクティブコピーには、オフセット 684,589,056 で 54,784 バイトの破損があります。 破損データには、大きな NULL チャンク、繰り返しバイト、および ZFS に関連すると思われる “root_dataset”、”sync_bplist”、”vdev” および “zpool create” を含むテキスト セクションが含まれます。 サイズと日付が同じです。

File 12 – Video, 817 MB。 アクティブコピーには、オフセット 418,578,432 で 43,520 の破損したバイトがあります。 破損データはファイル 11 で見つかったものと同じタイプです。 ファイル 1 と 2 は実際には破損しておらず、変更されたために一致しませんでした。

ファイル 3 と 4 は、ファイルの開始時に 65,536 バイトがメモリからのランダムなものに置き換えられました。 これについての説明はありませんが、アクティブなバージョンはまだ良かったので、バックアップが作成されたときに起こったのでしょう。 SuperCopierを使ったからかもしれないが、おそらく完全にバグがないわけではないだろう。 一度だけ、キューの中のあるファイルの長いファイル名がコピー先のファイルの8.3ファイル名と一致したため、ファイルを上書きしてしまったのを見たが、これはかなりレアケースであろう。 確かなことはわかりません。

Files 5-10 はすべて同じタイプの破損があります。 ファイルのランダムな場所にある連続したデータの小さな断片が、似たような外観のデータ列に変更されてしまいました。 再生で検出するには小さすぎるため、どれが正常なコピーなのかわかりません。

File 11 と 12 は、明らかに ZFS で保存されたことによる損傷があります。 私は毎週スクラブを実行し、FreeBSD は常に何か「間違っている」ものを見つけてはそれを修正していました。 これらのエラーが何なのか、なぜ発生するのか、私にははっきりしませんでしたが、悪い雰囲気が漂っていました。 私はそもそも ZFS のファイル CRC のために FreeBSD に乗り換えたのですが、しばらくして、もし NTFS がいたるところで壊れたファイルを取得していたら、世界中がそれを知っているだろうと思うようになりました。 しかし、私が Windows に戻った主な理由は、FreeBSD のインターフェイスが好きではなかったからです。

私は、5 番目のタイプの破損に遭遇しました。 コールド ストレージにある古い Seagate 1.5TB ドライブのほとんどに不良セクタが発生し始めました。 これは、私が年次スピンアップチェックを実行したときに発見され、ドライブ上のデータが破損する前に交換されました。 個々のビットをあちこちで密かに反転させるような現象があるとは思えないからです。

実用的なアドバイスとして、すべてのオフサイトバックアップと家族の写真などの重要なものの追加バックアップを維持することをお勧めします。 定期的にバックアップが復元可能であることを確認してください。 また、ドライブに障害が発生したときに、何を復元する必要があるかを知るための方法として、ファイル リストの作成、および、まれにファイルが破損していることを検出するためのファイル ハッシュの作成もお勧めします。 バックアップに関連するものには RAID はお勧めしません。

私自身は、3-2-1 バックアップ戦略はすべてのケースで使用するには少し強引だと考えています – 古い Linux ISO のコピーを 3 つ保持するつもりはありません。