DDrescue并行操作

我正在使用ddrescue从Seagate Barracuda 3TB驱动器恢复数据。驱动器出现故障，但到目前为止，我尝试读取的每个扇区最终都返回正确的数据，但可能需要进行一些探测（这意味着ddrescue必须在最后一个阶段进行多次传递，其中读取坏扇区）。

但是，正常操作非常慢。我在磁盘上有一些全速读取（60MB / s）的延伸，但在成功获得~2.5TB的数据后，剩余的500GB分布在整个磁盘上并以~2KB / s的极快速度读取，估计需要几千天才能完成。

但是，我可以在同一个驱动器上同时运行多个ddrescue实例，这会增加吞吐量，但我不确定如何将数据最终合并到一个图像中，特别是通过跟踪地图文件。我假设多个进程意味着多个映射文件。

另外，有人知道驱动器为什么这么慢？我的意思是，2KB / s（或更少，如果出现错误）非常慢，会带回C64的回忆。我花了3个小时才得到30MB的数据。我会有一个相同的Barracuda 3TB驱动器可以作为一个器官捐赠者，如果偶然改变控制器可以缓解问题（但从阅读这个，这是否有效是值得怀疑的）。

hard-drive partition-recovery ddrescue

— Ro-ee
source

运行多个实例是否会增加吞吐量？或者它看起来更快，因为慢读取被更快的读取变得模糊了？我很难想象在一个旋转磁盘上有多个读卡器实际上会导致更高的读取速度的情况？看起来你实际上是通过添加更多的头部搜索来放慢速度？

— ernie

我将不得不对此进行测试，但是当我只读取2KB / s的内容时，我不确定磁盘是否有很多磁头移动。当然，如果那是因为它必须经常在内部重新阅读这个部门，那可能就是这种情况，寻找不同的地方会使速度变得更糟......

— Ro-ee

是的，我的观点是即使是一个完美运行的磁盘，我也不知道两个同步读取如何比单个读取器更快。

— ernie

IF（这是一个很大的问题）慢读取速度不是由读取本身引起的，而是驱动器中的其他东西（记住，驱动器即将发生故障，智能数据正在给我发送蠕变），然后同时读取可能是更快，因为物理读取/本身/将在相同的时间内完成，但剩余的数据处理将花费其余的时间。这是我能想出来的唯一原因，但测试必须证明这一点。我知道当我用ddrescue将尺寸限制为30MB拉伸时，大约需要3个小时。所以我可以并行执行此操作，需要3到6个小时才能完成。

— Ro-ee

同时读取总是引入头部搜索，减慢速度。看起来你正在想象一个场景，瓶颈是它从盘子里读出的东西，然后是一些处理或者某种非常慢的东西，这是瓶颈？这看起来真的非常不可能。在驱动器出现故障的情况下，我真的不愿意做并行读取器，因为你会在驱动器上引入额外的磨损并增加磁头。我可能只是尝试直接复制我绝对需要的文件，而不是使用dd或类似的。

— ernie

您可以告诉GNU ddrescue跳过缓慢的部分，然后再回到它们，而不是让两个图像复杂化。

允许你这样做的标志是 --min-read-bytes=。

来自 GNU ddrescue手册：

--min-read-rate=bytes

良好的未尝试区域的最小读取速率，以每秒字节数为单位。如果读取率低于此值，则ddrescue 将根据速率和错误跳过可变数量历史。跳过的块在额外的传递中尝试（之前微调）。如果字节为0（自动），重新计算最小读取速率每秒（average_rate / 10）。

如果您坚持制作多个图像，手册中还有一个如何组合它们的示例：

示例4：合并3个相同DVD的部分恢复的图像使用他们的mapfiles作为域mapfiles。

 ddrescue -m mapfile1 dvdimage1 dvdimage mapfile
 ddrescue -m mapfile2 dvdimage2 dvdimage mapfile
 ddrescue -m mapfile3 dvdimage3 dvdimage mapfile
   (if bad-sector size is zero, dvdimage now contains a complete image
    of the DVD and you can write it to a blank DVD)

— Deltik
source

我已经在使用-a（= --min-read-bytes），它以20000字节/秒的速度熄灭。我在第1遍运行多次（我在地图文件中重置了'当前'指针，因为我发现跳过了更大的延伸，这远远帮助我在最后获得了~10GB的额外数据但是最终，大面积的区域都将被处理掉，我留下了30MB的未经尝试的区域，在它们的50k以上。感谢合并提示。

— Ro-ee