我有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（計劃將/dev/sdc5新增至RAID以將其轉為正常狀態），然後使用/dev/md0作為唯一的pv LVM，並使用ext4檔案系統/dev/mapper/vg0-lv0建立了一個lv。
不幸的是，在探索和使用 LVM 時，我dd if=/dev/zero of=/dev/sdc1 bs=64M count=10在刪除 /dev/sdc1 後運行。所以實際上零被寫入/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。 /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 個位元組的差異。而且因為一個檔案的名稱中有 CRC32，所以我可以確認物理 /dev/sdc7 中的檔案是正確的。
所以我的問題是，為什麼會發生這種奇怪的事情？我已經跑去fsck.ext4 -c -c /dev/mapper/vg0-lv0確認它沒有壞塊。 1.2TB資料中4個位元組的差異是很小的百分比，但這讓我對以後將資料儲存在/dev/mapper/vg0-lv0上沒有信心。
更新：我不得不提的是，所有操作都是在VirtualBox 4.1.16 中運行的最新ArchLinux 中完成的，該版本運行在Windows 7 中。與物理硬碟鏈接，通過VBoxManage internalcommands createrawvmdk。 VirtualBox 僅在對實體 /dev/sdc7 進行 md5sums 期間報告錯誤 VERR_ACCESS_DENIED，在透過diskpartWin7 使實體磁碟離線後，不再引發任何錯誤。
答案1
有幾件事可能發生。首先，您沒有提到在對磁碟進行映像之前卸載 sdc7，因此可能當時正在寫入資料。但我猜情況並非如此，否則你就不會問了。我不能責怪你的「首先，對磁碟進行映像」的反應，這是一個非常好的反應。儘管我注意到在重新啟動之前，內核在內存中仍然有分區表，請檢查/proc/partitions.
首先要檢查的是記憶體錯誤。你的內存可能很差。您的資料無疑會多次通過 RAM。我假設你沒有 ECC 內存，這可能會捕獲這個問題。
硬碟也有錯誤。看看一些隨機消費性硬碟的規格表，他們說每 100 Tbit 1 個。您至少複製了 1.2TB 幾次（從來源讀取，從目標讀取），所以這大約是 19 Tbit 讀取。有一點點錯誤是可信的。 （不幸的是，他們沒有給出規格表上寫入的錯誤率）。
單字節損壞背後有什麼規律或原因嗎？cmp -l可以告訴你變化的位元組。例如，如果頁面中的偏移量始終相同（頁面大小可能是 4K），並且總是相同的位，則幾乎可以肯定地表明 RAM 有缺陷。即使它總是相同的位元或相同的偏移量，這也是相當確定的（並且您是否對所有四個檔案都有 CRC32，還是只有一個檔案？）