使用 GNU ddrescue 复制了故障磁盘，我遗漏了什么吗？

Question

这不会那么容易实现。

新磁盘上的逻辑扇区大小为4096，而旧磁盘使用512。分区表中的数字保持不变，但由于新扇区大 8 倍，因此克隆中的整个分区表毫无意义。

在某些情况下，可以翻译这些数字（比较我的这个答案）但这里（旧）分区从 63*512 字节的偏移量开始，不能被 4096 整除。这意味着你的文件系统现在从某个地方开始里面一个更大的扇区（虽然它应该从扇区的开头开始），所以没有分区表可以立即使其工作。

现在该怎么办？以下是一些想法。在继续操作之前，请断开旧磁盘（以防万一）。

无论分区表如何（现在无效），您仍然可以尝试挂载文件系统：

mount -o ro,offset=$((63*512)) /dev/sde /some/mountpoint

如果文件系统健康，这应该可行。对于您而言，命令可能因文件系统损坏而失败。但也许它会起作用，您将设法取出所有重要数据。

您可以将整个磁盘映射到报告扇区大小的循环设备512：

losetup -f --show /dev/sde       # 512 is the default value

这应该会打印一个类似的节点/dev/loop7。在此设备的上下文中，分区表有效。需要分区表的工具现在应该可以与设备配合使用（尽管有些工具可能需要/dev/loop7p1，才能与分区配合使用；kpartx可能会有所帮助，但请先考虑下一个想法）。

注意：你用销毁节点losetup -d /dev/loop7。

您可以将真实分区映射到循环设备：

losetup -f --show --offset $((63*512)) --sizelimit $(( (976768064+1-63)*512 )) /dev/sde

同样，这应该会打印一个类似这样的节点/dev/loop8。（可能已损坏的）文件系统从此设备的最开始处开始，因此分析文件系统的恢复工具有望在没有任何分区表的情况下找到它（或至少找到其中的文件）。

您可以将分区复制到另一个偏移量，这样分区表能需要修复。这有点棘手；所有数字都必须正确计算。如果之前的方法对您来说已经足够，那就不要费心了。

请注意，旧磁盘为 465.8 GiB，新磁盘为 2.7 TiB；因此您有足够的空间。让我们将文件系统复制到磁盘末尾。

旧分区占用了从扇区号 63 到（含）976768064 的 512 字节扇区，总共 976768002 个扇区。这意味着您至少需要 122096001 个更大的（4096 字节）扇区。

在 4096 字节扇区中，开始和结束转换为 7（部分占用）和 122096008（也部分占用）。

您的磁盘有 732558336 个扇区，您需要向后退 122096001 个扇区（如果您计划在其上使用 GPT，则需要更多）。起始扇区为 610459648 似乎没问题。它会在末尾为辅助 GPT 留出一些空间（并且它与 32 MiB 边界对齐，但这并不重要）。现在，新分区的最后一个扇区应该至少为 732555648（如果您希望扇区大小能被 8 整除，则为 732555655，这可能会让一些工具感到满意；大于足够大的分区不会影响文件系统，它知道自己的大小）。

编辑分区表，销毁旧的（无效的）条目并按计划创建一个新的条目：

第一部门 610459648
最后一个扇区 732555655
适用于 NTFS 的代码或类型

如此大的磁盘，扇区大小为 512 字节，则需要 GPT，而不是 MBR 分区表。如果扇区大小为 4096 字节，则 GPT 或 MBR 应该可以工作。

然后（之后partprobe，如果分区程序没有隐式调用它）您应该可以访问新的分区。

将数据从/dev/loop8（上面创建的）复制到新分区：

dd if=/dev/loop8 of=/dev/sdeN bs=32M
# or better use ddrescue again

在该命令复制大约 465.8 GiB 后，文件系统将在分区内正确对齐（它从开头开始，而不是从扇区的中间开始）。以前的想法有些“不靠谱”，而这个想法为您提供了一个相当标准的设置。

请注意，如果需要，您可以为恢复的数据创建另一个分区。您ddrescue最初写入的文件系统结束于扇区 122096008。新副本（如果您决定创建它）从 610459648 开始。无论如何，中间的所有内容都供您使用。

Answer 1