我有 3 个硬盘，以下分别命名为 /dev/sda、/dev/sdb 和 /dev/sdc，最新的排在最前面。注意：/dev/sdc 有一个主分区 /dev/sdc1、一个扩展分区 /dev/sd2 和 3 个逻辑分区 /dev/sdc5、/dev/sdc6 和 /dev/sda7。
我使用 /dev/sda5 和 /dev/sdb5 创建了一个降级的 RAID 5 设备 /dev/md0（计划将 /dev/sdc5 添加到 RAID 以使其恢复正常状态），然后使用 /dev/md0 作为 LVM 的唯一 pv，并创建了一个具有 ext4 文件系统的 lv /dev/mapper/vg0-lv0。
不幸的是，在探索和使用 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 上存储数据没有信心。
更新：我不得不提一下，所有操作都是在最新的 ArchLinux 中完成的，该 Linux 运行在 Windows 7 中的 VirtualBox 4.1.16 中。/dev/sda、/dev/sdb 和 /dev/sdc 都通过 链接到物理硬盘VBoxManage internalcommands createrawvmdk。VirtualBox 在对物理 /dev/sdc7 进行 md5sum 时只报告了错误 VERR_ACCESS_DENIED，在通过diskpartWin7 离线物理磁盘后，没有出现其他错误。
答案1
有几种情况可能发生。首先，您没有提到在对磁盘进行映像之前卸载 sdc7，因此可能是当时正在写入数据。不过，我猜情况并非如此，否则您就不会问了。我无法指责您的反应“首先，对磁盘进行映像”，这是一个相当不错的反应。不过我注意到，在您重新启动之前，内核仍然在内存中保留分区表，请检查/proc/partitions。
首先要检查的是内存错误。您的 RAM 可能有问题。您的数据无疑经过了 RAM 多次。我假设您没有 ECC 内存，这可能会发现这个问题。
硬盘也会出错。查看一些随机消费级硬盘的规格表，它们显示每 100 Tbit 出错 1 次。您至少复制了 1.2TB 数据几次（从源读取，从目标读取），因此读取量相当于 19 Tbit。出现一点错误是可以接受的。（遗憾的是，规格表上没有给出写入错误率）。
单字节损坏背后有什么原因或韵律吗？cmp -l可以告诉您变化的字节。例如，如果页面中的偏移量始终相同（您的页面大小可能是 4K），并且始终是相同的位，则几乎可以肯定地指向有缺陷的 RAM。即使它始终是相同的位或相同的偏移量，那也将是相当有说服力的（并且您是否对所有四个文件都进行了 CRC32，还是只有一个？）