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