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

Question

背景/背景：

我目前正在运行 GNU ddrescue 1.18.1 以从 USB 恢复数据，该 USB 在我将虚拟磁盘映像写入 disk2s1 分区时遇到电缆断开连接。最初我正在恢复我的第二个分区 (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 之外，我还使用技术来提高所有坏扇区的机会。爱荷华州

通过对“循环”的估计，如果您的意思是重试次数，那么这取决于您使用的参数。如果您的意思是“总通过次数”，则可以通过阅读此处的算法轻松确定。 >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