如何使用当前状态估计完成 GNU ddrescue (1.18.1) 的循环/时间？

Question

背景/背景：

我当前正在运行 GNU ddrescue 1.18.1，以从 USB 恢复数据，当我将虚拟磁盘映像写入到 disk2s1 分区时，该 USB 电缆发生了断开。最初，我正在恢复第二个分区（disk2s2），并注意到我已经到达第三阶段（分割）。我正在将图像放置到网络存储上。

问题：

我注意到这个阶段是循环的。考虑到我当前的状态信息（我只显示两个错误），有没有办法计算我可能经历的循环数量？

地位：

更新/编辑：

因此，我仍然对如何使用 ddrescue 工具估计完成的循环/时间非常感兴趣。根据评论，我正在添加对当前正在运行的 disk2s1 分区的日志文件的评估（disk2s2 在 14.5 小时后完成，其中一个用户中断了大约 6 小时）。

完成的分区日志

对于刚刚完成的分区，这是日志检查的结果。

参考（ddrescue算法笔记）：

4 算法

---

GNU ddrescue 不是 dd 的衍生版本，也与 dd 没有任何关系，只是两者都可以用于将数据从一个设备复制到另一个设备。主要区别在于 ddrescue 使用复杂的算法从故障驱动器复制数据，从而尽可能减少额外损坏。

Ddrescue 有效地管理正在进行的救援状态，并尝试首先救援好的部分，安排稍后在坏（或慢）区域内进行读取。这最大限度地提高了最终可以从故障驱动器中恢复的数据量。

标准 dd 实用程序可用于保存发生故障的驱动器中的数据，但它会按顺序读取数据，如果错误位于驱动器的开头，则可能会磨损驱动器而无法挽救任何内容。

其他程序按顺序读取数据，但在发现错误时切换到小尺寸读取。这是一个坏主意，因为这意味着在错误区域花费更多时间，损坏表面、磁头和驱动机构，而不是尽快摆脱它们。此行为降低了挽救剩余良好数据的机会。

ddrescue 的算法如下（用户可以在任何时候中断该进程，但要注意坏驱动器可能会长时间阻塞 ddrescue 直到内核放弃）：

1) （可选）读取描述多部分或先前中断的救援状态的日志文件。如果未指定日志文件、为空或不存在，则将所有救援域标记为未尝试。

2）（第一阶段；复制）读取输入文件中未尝试的部分，将失败的块标记为未修剪并跳过它们。也跳过慢速区域。稍后在另外两次通过中尝试跳过的区域（在修剪之前），在每次通过后反转方向，直到尝试了所有救援域。第三遍是扫遍，禁用跳跃。 （目的是快速界定大错误，保持日志文件较小，并为修剪提供良好的起点）。仅以大块读取未尝试过的区域。修剪、分割和重试是逐个扇区完成的。每个扇区最多尝试两次；此步骤中的第一个（通常作为大块读取的一部分，但有时作为单个扇区读取），以下步骤中的第二个作为单个扇区读取。

3)（第二阶段；修整）从最小的未修整块的前沿开始一次向前读一个扇区，直到发现坏扇区。然后从同一块的后沿开始向后读取一个扇区，直到发现坏扇区。对于每个未修剪的块，将发现的坏扇区标记为坏扇区，并将该块的其余部分标记为未分割，而不尝试读取它。重复此操作，直到不再有未修剪的块。 （大的未修剪块是由较小的块串联而成的，因此其边缘的好数据比例较小）。

4）（第三阶段；分割）从最大的非分割块的中心开始一次向前读取一个扇区，直到发现坏扇区。然后，如果发现的坏扇区不是第一个尝试的，则从同一块的中心开始向后读取一个扇区，直到发现坏扇区。如果日志文件大于“--logfile-size”，则按顺序读取最大的非分割块，直到日志文件中的条目数降至“--logfile-size”以下。重复此操作，直到所有剩余的未分割块的扇区数少于 7 个。然后依次读取剩余的未分割块。

5)（第四阶段；重试）可选择尝试再次读取坏扇区，直到达到指定的重试次数。每个坏扇区在每次传递中仅尝试一次。 Ddrescue 无法知道坏扇区是否不可恢复，或者在重试后是否最终会被读取。

6) 可选择写入日志文件以供以后使用。

总错误大小（'errsize'）是所有未修剪、未分割和坏扇区块的大小之和。它在复制阶段增加，在修剪、分割和重试期间可能减少。请注意，当 ddrescue 分割失败的块并使其变小时，总错误大小可能会减少，而错误数量会增加。

日志文件会定期保存到光盘，以及在 ddrescue 完成或中断时保存。因此，一旦发生崩溃，您只需很少的重新复制即可恢复救援。保存之间的间隔从 30 秒到 5 分钟不等，具体取决于日志文件大小（较大的日志文件以较长的间隔保存）。

此外，同一日志文件可用于复制输入文件不同区域的多个命令，以及对不同子集的多次恢复尝试。看这个例子：

首先拯救光盘最重要的部分。 ddrescue -i0 -s50MiB /dev/hdc hdimage 日志文件 ddrescue -i0 -s1MiB -d -r3 /dev/hdc hdimage 日志文件

然后拯救一些关键的光盘区域。 ddrescue -i30GiB -s10GiB /dev/hdc hdimage 日志文件 ddrescue -i230GiB -s5GiB /dev/hdc hdimage 日志文件

现在拯救其余的（不重新复制已经完成的内容）。 ddrescue /dev/hdc hdimage 日志文件 ddrescue -d -r3 /dev/hdc hdimage 日志文件

Answer 1

尽管这个问题是 10 个月前提出的，但答案可能是相关的，因为恢复周期可能仍在运行，具体取决于几个因素！没有双关语的意思。

原因是，时间估计几乎是不可能的，但有时您可以得到如下的粗略想法。最明显的原因之一是您无法预测驱动器读取坏扇区需要多长时间，并且如果您希望 ddrescue 读取并重试每个扇区，那么可能需要很长时间。例如，我目前正在一个 500GB 的小型驱动器上运行恢复，该恢复已经持续了 2 周多，而且我可能还剩几天时间。但我的情况更复杂，因为驱动器是加密的，为了成功读取任何内容，我必须确保获取具有分区表、引导扇区和磁盘其他重要部分的所有扇区。除了 ddrescue 之外，我还使用其他技术来提高出现所有坏扇区的机会。 IOW，您的独特情况对于确定完成时间很重要。

通过估计“循环”，如果您指的是重试次数，那么这是您使用的参数决定的。如果您的意思是“通过总数”，可以通过阅读此处的算法轻松确定。 >man ddrescue</ 算法：ddrescue 如何恢复数据

我将具体讨论您提供的屏幕截图中的数字。其他情况可能有其他适用因素，因此请将此信息作为一般指南。

在您提供的示例中，查看 ddrescue 的运行状态屏幕。我们通过“errsize”获得问题（救援域）的总“估计”。这是“尚未读取”的数据量。示例中为 345GB。右下一行是“平均利率”。示例中为 583kb/s

如果“平均利率”保持接近稳定，这意味着您还有 7 天的时间。 345 GB / (583 kb * 60*60*24) = 7.18 但问题是你不能依赖 583kb/s。事实上，随着恢复的深入，驱动器会变得更慢，因为它正在读取越来越多的困难区域并进行更多的重试。因此完成时间呈指数增长。所有这些都取决于驱动器损坏的严重程度。

您提供的示例显示“成功读取”是在 10 多个小时前。也就是说，在 10 多个小时内，它并没有真正从驱动器中获取任何信息。这表明您的驱动器可能有 345GB 的数据（或一部分）。这对你来说是个非常坏的消息。

相比之下，我的第二个 500GB 驱动器刚刚开始出现“SMART”错误，被复制到磁盘（日志文件位于另一个驱动器上），整个操作大约需要 8-9 小时。最后一部分放慢了速度。但这仍然可以忍受。如上所述，非常糟糕的驱动器在 500GB 上运行已经过去 2 周了，但仍有大约 4-5% 的空间需要恢复。

HTH 和 YMMV