私は 3 つのハード ディスクを持っています。次の段落では、/dev/sda、/dev/sdb、および /dev/sdc という名前で、新しいものが最初に来ています。注: /dev/sdc には、1 つのプライマリ パーティション /dev/sdc1、1 つの拡張パーティション /dev/sd2、および 3 つの論理パーティション /dev/sdc5、/dev/sdc6、および /dev/sda7 があります。
/dev/sda5 と /dev/sdb5 を使用して劣化した RAID 5 デバイス /dev/md0 を作成し (RAID に /dev/sdc5 を追加して通常の状態にする予定)、/dev/md0 を LVM の唯一の pv として使用し、ext4 ファイル システム /dev/mapper/vg0-lv0 を使用して lv を作成しました。
残念ながら、LVM を調べて操作しているときに、/dev/sdc1 を削除した後に実行しましたdd if=/dev/zero of=/dev/sdc1 bs=64M count=10。そのため、実際にはゼロが /dev/sdc2 に書き込まれ、/dev/sdc2 に保存されているパーティション テーブルの一部と /dev/sdc5 の先頭部分が壊れていました。
これに気付いたとき、私はすぐに次のように dd 経由で /dev/sdc のイメージを作成しましたdd if=/dev/sdc of=/mount-point-of-vg0-lv0/sdc.img。
数日後、ようやく /dev/sdc のデータを復旧する時間ができました。実際には、バックアップのない唯一のパーティションである /dev/sdc7 だけです。イメージ ファイル sdc.img を使用して testdisk を実行し、そのクイック検索機能を使用してパーティション テーブルを再構築し、/dev/loop0 に losetup しました。/dev/loop0p7 (/dev/sdc7 のイメージ) が復旧してマウント可能になり、すべてのファイルは正常のようです。次に、find /mount-point-of-loop0p7 -type f -exec md5sum {} \; > sdc7_img.md5sum/dev/loop0p7 のすべてのファイルの MD5 チェックサム リストを作成するために実行しました。
物理 /dev/sdc デバイスを扱う場合、testdisk のクイック検索ではすべてのパーティションが見つかりませんが、ディープ検索では見つかります。次に、同様のコマンドを使用して、物理 /dev/sdc7 上のすべてのファイルの MD5 チェックサム リスト sdc7.md5sum を作成しました。これを sdc7_image.md5sum と比較すると、4 つのファイルが異なることがわかりました。手動で比較すると、各ファイルの違いは 1 バイトだけであることがわかりました。また、1 つのファイルの名前に CRC32 が含まれているため、物理 /dev/sdc7 のファイルが正しいことが確認できます。
そこで私の質問は、なぜこのような奇妙なことが起こったのかということです。すでに実行して、fsck.ext4 -c -c /dev/mapper/vg0-lv0不良ブロックがないことを確認しました。1.2TB のデータで 4 バイトの違いは非常に小さな割合ですが、今後 /dev/mapper/vg0-lv0 にデータを保存することに自信が持てません。
更新: すべての操作は、Windows 7 で実行されている VirtualBox 4.1.16 で実行されている最新の ArchLinux で実行されたことを述べておきます。/dev/sda、/dev/sdb、および /dev/sdc はすべて、を介して物理ハード ディスクにリンクされていますVBoxManage internalcommands createrawvmdk。VirtualBox は、物理 /dev/sdc7 に対して md5sum を実行中にエラー VERR_ACCESS_DENIED のみを報告しましたが、Win7 を介して物理ディスクをオフラインにした後はdiskpart、それ以上のエラーは発生しませんでした。
答え1
起こった可能性のあることがいくつかあります。まず、ディスクをイメージ化する前に sdc7 をアンマウントしたとは書いていないので、その時点でデータが書き込まれていた可能性があります。しかし、そうではなかったと推測します。そうでなければ、質問はしないでしょう。「まずディスクをイメージ化します」というあなたの反応を非難することはできません。それはかなり良い反応です。ただし、再起動する前に、カーネルのメモリにパーティション テーブルがまだ残っていたことに注意してください/proc/partitions。確認してください。
最初に確認すべきことは、メモリ エラーです。RAM が不良である可能性があります。データは間違いなく RAM を複数回通過しています。ECC メモリが搭載されていないと想定していますが、おそらくこのエラーを検出できるはずです。
ハードディスクにもエラーはあります。いくつかのランダムな消費者向けハードドライブの仕様書を見ると、100 Tbit あたり 1 と書かれています。1.2 TB を少なくとも数回コピーしたので (ソースから読み取り、コピー先から読み取り)、読み取りは 19 Tbit 程度になります。これに 1 ビットのエラーがあるのはあり得ます。(残念ながら、仕様書には書き込みのエラー率は記載されていません)。
1 バイトの破損には何か理由がありましたか?cmp -l変化するバイトを教えていただけますか。たとえば、ページ内のオフセットが常に同じ (ページ サイズはおそらく 4K) で、ビットも常に同じであれば、ほぼ確実に RAM に欠陥があることがわかります。常に同じビット、またはオフセットだけであったとしても、それはかなり決定的です (また、4 つのファイルすべてに CRC32 がありましたか、それとも 1 つだけですか?)