我正在使用 ddrescue 复制故障/即将报废的硬盘，经过近 15 天，过程完成了约 84%，预计将在接下来的 4 到 5 天内完成第 1 阶段。
历史（参考另一个问题我之前发布过）：源驱动器是 2TB Seagate Baracuda 驱动器，用作 Windows 10 计算机中的第二个驱动器，有四个分区，前三个分区每个 500GB，最后一个分区大约 400GB（留下的不是正好 500GB 来制作第 4 个分区）。
使用 Ubuntu Linux 插入硬盘。驱动器和分区出现在 ubuntu 中，但实际上没有分区可访问，导致系统响应非常非常慢。我在尝试安装 ubuntu 时错误地使用 ext4 格式化了驱动器。安装已完成，但系统从未从此磁盘启动。
然后我们尝试使用 TestDisk 进行恢复，但 10 天后，我们停止了。（深度扫描后，测试磁盘识别出第一个 500 GB NTFS 分区）
最后，尝试使用 ddrescue 将磁盘复制到新硬盘。
计划是从这个中间副本制作另一个副本。中间驱动器是 WD 4TB 驱动器。
对于第二份副本，我购买了另一块 Seagate 4TB 硬盘。计划稍后尝试使用 Testdisk 恢复 NTFS 分区。感兴趣的文件可能位于第二个或第三个 500GB 分区中。
对于第一次复制，我使用了以下命令：
ddrescue -d -f -r3 /dev/sdb /dev/sdc sdc.log
根据 SMARTTools 显示，原始故障驱动器的容量为 2,000,398,934,016 字节 [2.00 TB]。
我理解添加-s参数并使目标大小略高于原始大小。所以我认为在原始大小（以字节为单位）上添加大约 10 mb 就足够了，对吗？10 mb = 10,000,000 字节。我应该再增加一点，比如说 100 mb 吗？
其次，我认为我们也不需要使用 -r3 参数。因此，命令应该是这样的：
ddrescue -d -f -s 2000408934016 /dev/sdb /dev/sdc sdc.log
我还应该在命令中添加什么（或删除）来启动 ddrescue 进行第二次复制？
答案1
首先您应该复制
sdc（而不是sdb）到sdd或其他内容；并且您不应该sdc.log再次使用旧的映射文件作为映射文件。即使您要重新连接驱动器，它们的名称也会发生变化，在这个答案中我将严格使用：
sdb仅适用于原始驱动器，sdc仅适用于中间驱动器（第一个副本），sdx仅适用于新驱动器（第二份副本），sdc.log仅适用于旧的地图文件。
-
我理解添加
-s参数并使目标尺寸略大于原始尺寸。[…]我应该再增加一点吗[…]？没有必要。在我对你的第一个问题的回答我写道“如果有任何疑问，请使用更大的数字”。如果您知道确切的大小
sdb（而且您似乎知道），那么您可以使用确切的数字。 -
我认为我们也不需要使用该
-r3参数。我同意。前提是
sdc健康，并且每个扇区都可以在第一次尝试中读取。以防万一，您可以添加-r3；如果sdc健康，那么该选项根本不重要。但即使您不添加该选项并且sdc结果有些错误，也可以重复该命令-r…并ddrescue尝试再次读取坏扇区。（您可以随意重复一次又一次）。 -d（直接访问）也是不需要的。从健康磁盘读取时，您可以使用操作系统提供的任何增强功能，这种方法只会让事情变得更好。
该命令如下：
ddrescue -f -s 2000398934016 /dev/sdc /dev/sdx sdx.log
坦率地说，您甚至不需要ddrescue使用专门设计来处理读取错误的先进引擎。如果 sdc是健康的，那么下面的操作也应该有效：
head -c 2000398934016 /dev/sdc >/dev/sdx
（请注意，你需要一个提升权限的 shell 才能使重定向工作，sudo head …这是不够的；sudo head … | sudo tee /dev/sdx >/dev/null应该可以工作，请参阅这个答案）。
head不会创建sdx.log，但如果sdc是健康的，那么你无论如何都不需要这个文件（你应该将其视为sdc.log与两个副本相关的文件）。另一方面，即使你sdc现在认为是健康的，你也永远无法真正确定它能否停留在操作过程中保持健康，因此使用ddrescue是一个好主意。ddrescue如果出现读取错误，这将是一个优势sdc。我们希望不会，可能不会。
有一种方法你应该考虑。我没有把它包括在已经链接答案，现在是时候向您介绍它了。您可以将其用作sdc.log域映射文件。从GNU手册ddrescue：
-m file
--domain-mapfile=file
将救援范围限制在映射文件中标记为完成的块内file。[…]
该命令如下：
ddrescue -f -m sdc.log /dev/sdc /dev/sdx sdx.log
优点：
您不需要知道原始驱动器的大小；没有必要
-s。关键是标记为已完成的块sdc.log显然不能超出的大小sdb。由于只读取第一个
ddrescue（从sdb到sdc）成功复制的内容，因此您不会无谓地复制无关数据。如果 中指示的未完成（实际上为错误）片段sdc.log很大，这将提高性能；我们的ddrescue -m …将直接跳过它们。如果存在读取错误（即
sdc不太健康），sdx.log将反映这些错误。最终，它还将反映未完成的片段（如所示）sdc.log。无论如何，sdx.log将描述实际的上的副本状态sdx。（旁注：预期读取错误，您可以-r…在第一次尝试时添加；或稍后添加，因为关于（此答案上方）的注释-r也适用于此处）。如果发生读取错误
sdcsdx.log，描述副本实际状态的事实sdx将允许您（尝试）重新读取缺失的部分sdb。只需在命令中替换sdc为（保留和，随意添加）。sdb-m …sdx.log-r…
坏处：
- 如果 中指示的未完成（实际上为错误）片段
sdc.log很小但数量很多，则在读取时跳过它们实际上可能会降低性能。最有可能是健康的，从指示的sdc开始到结束-s 2000398934016连续读取可能是一个更好的主意。
如果不查看完整的sdc.log，很难猜测哪种变体（-m或-s）对您来说性能更好。在某些情况下，仅知道映射文件并不足以确定，无论如何都会有一些猜测（希望是有根据的猜测）。
如果我是你，并且我合理地信任sdc，我可能会继续使用-s并连续读取sdc。假设此方法无错误地运行，最终我应该认为sdc.log和 都相关。