这个问题解决了第一遍ddrescue要救援的设备上的。
我不得不拯救一个1.5TB的硬盘。
我使用的命令是：
# ddrescue /dev/sdc1 my-part-img my-part-map
当在磁盘的良好区域上启动救援（没有可选参数）时，读取速率 (" current rate") 保持在 18 MB/s 左右。
它偶尔会减慢一点，但随后会恢复到这个速度。
但是，当遇到磁盘坏区时，速度可能会显着减慢，然后再也不会回到 18 MB/s，而是保持在 3 MB/s 左右，即使在读取 50 GB 的好磁盘后也没有问题。
奇怪的是，当它当前以 3 MB/s 的速度扫描良好的磁盘区域时，如果我停止ddrescue并重新启动它，它会以 18 MB/s 的较高读取速率重新启动。实际上，当速度达到 3 MB/s 时，我通过停止并重新启动节省了大约 2 天的时间ddrescue
，我必须执行 8 次才能完成第一遍。
我的问题是：为什么它ddrescue不会尝试自行回到最高速度。鉴于文档中明确规定的政策，即首先完成并快速完成简单的区域，这就是应该做的事情，而我观察到的行为在我看来似乎是一个错误。
我一直想知道是否可以通过该选项来处理这个问题，
-a或者--min-read-rate=… 但是手册太简洁了，我不确定。此外，我不明白应该根据什么基础来选择此选项的读取速率。应该是上面的18MB/s吧？
尽管如此，即使有一个选项来指定它，我还是很惊讶这不是默认情况下完成的。
元注释
两名用户投票结束该问题，因为该问题主要基于意见。
我很想知道它是什么意思？
我以一定的数值精度描述了一个重要软件在实际示例中的行为，清楚地表明它不符合其文档中规定的主要设计目标（尽快完成简单的部分），并且推理非常简单可以改善这一点。
该软件是众所周知的，来自非常值得信赖的来源，具有精确的算法，我希望大多数缺陷很久以前就被淘汰了。因此，我向专家询问这种意外行为的可能已知原因，但我自己并不是这个问题的专家。
另外，我问是否应该使用软件的某个选项来解决问题，这更是一个非常精确的问题。我要求提供详细的方面（如何选择此选项的参数），因为我没有找到这方面的文档。
我要求的是工作所需的事实，而不是意见。我用实验事实而不是观点来激发它。
答案1
我一直想知道是否可以使用选项 -a 或 --min-read-rate= 来处理这个问题......但手册是如此简洁，我不确定。此外，我不明白应该根据什么基础来选择此选项的读取速率。应该是上面的18MB/s吧？
该--min-read-rate=选项应该有帮助。现代驱动器往往会花费大量时间进行内部错误检查，因此虽然速度大大减慢，但这不会被报告为错误情况。
即使读取 50 GB 的好磁盘也没有问题。
这也意味着：你甚至不知道是否存在问题。驱动器可能有问题，并决定不报告该问题。
现在，ddrescue支持使用动态--min-read-rate=值，来自info ddrescue：
If BYTES is 0 (auto), the minimum read rate is recalculated every
second as (average_rate / 10).
但根据我的经验，自动设置似乎没有多大帮助。一旦驱动器卡住，特别是如果这种情况发生在开始时，我想average_rate永远不会保持足够高的水平以使其有效。
因此，在第一遍中，当您想要获取尽可能多的数据时，首先是快速区域，我只是将其设置为average_rate / 10手动，average_rate 是驱动器完好无损时的平均速率。
例如，您可以选择10M此处（对于应该以约 100M/s 的速度运行的驱动器），然后您可以随时返回并在稍后的慢速区域试试运气。
我观察到的行为在我看来是一个错误。
如果你有一个错误那么你必须调试它。如果没有相同类型的驱动器故障，则很难重现。它也可能是驱动器本身陷入某种恢复模式。
在处理有缺陷的驱动器时，您还必须检查dmesg是否发生任何奇怪的事情，例如总线重置等。一些控制器在处理故障驱动器方面也比其他控制器更糟糕。
有时手动干预是无法避免的。
即便如此，我还是很惊讶这不是默认情况下完成的。
大多数程序都没有合理的默认设置。dd默认情况下仍然使用 512 字节块大小，这在大多数情况下是“错误”的选择...被认为合理的内容也可能随着时间的推移而改变。
我要求的是工作所需的事实，而不是意见。
拥有良好的备份比依赖要好ddrescue。从故障驱动器中获取数据首先需要运气。数据恢复涉及很多个人经验和意见。
我们拥有的大多数恢复工具也很愚蠢。该工具没有向中央服务器报告的人工智能，并且类似于“哦，我以前在这个特定的驱动器模型上看到过这种故障模式，所以让我们改变我们的策略......”。所以这部分工作必须由人类来完成。
答案2
这是一个有点死灵的帖子，但对于任何可能遇到这种情况的人来说：
我已经能够重现 OP 的行为，并让 ddrescue 通过使用其-O标志恢复其最大读取速度，该标志在每次错误后重新打开输入文件。
不幸的是，我没有机会深入研究为什么它在遇到错误后似乎以 ~3 MiB/s 的速度恢复，但我想我应该分享我的经验。