分区恢复后与 ext4/lvm/raid-5 相关的奇怪问题

Question

我有 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 设备时，测试磁盘的快速搜索不会找到所有分区，深度搜索会。然后我使用类似的命令为物理 /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上。

更新：不得不提的是，所有的操作都是在运行在Windows 7上的VirtualBox 4.1.16的最新ArchLinux上完成的。/dev/sda、/dev/sdb和/dev/sdc都与物理硬盘相连，通过VBoxManage internalcommands createrawvmdk. VirtualBox 在为物理 /dev/sdc7 制作 md5sums 期间只报告错误 VERR_ACCESS_DENIED，通过diskpartWin7离线物理磁盘后，没有进一步的错误。

Answer 1

有几件事可能发生。首先，您没有提到在对磁盘进行映像之前卸载 sdc7，因此可能当时正在写入数据。但我猜情况并非如此，否则你就不会问了。我不能责怪你的“首先，对磁盘进行映像”的反应，这是一个非常好的反应。尽管我注意到在重新启动之前，内核在内存中仍然有分区表，请检查/proc/partitions.

首先要检查的是内存错误。你的内存可能很差。您的数据无疑会多次通过 RAM。我假设你没有 ECC 内存，这可能会捕获这个问题。

硬盘也有错误。查看一些随机消费类硬盘的规格表，他们说每 100 Tbit 1 个。您至少复制了 1.2TB 几次（从源读取，从目标读取），所以这大约是 19 Tbit 读取。有一点点错误是可信的。（不幸的是，他们没有给出规格表上写入的错误率）。

单字节损坏背后有什么规律或原因吗？cmp -l可以告诉你变化的字节。例如，如果页面中的偏移量始终相同（页面大小可能是 4K），并且总是相同的位，则几乎可以肯定地表明 RAM 有缺陷。即使它总是相同的位或相同的偏移量，这也是相当结论性的（并且您是否对所有四个文件都有 CRC32，还是只有一个文件？）