如何使用当前状态估算完成GNU ddrescue（1.18.1）的循环/时间？

背景/背景：

我目前正在运行GNU ddrescue 1.18.1，以便从将虚拟磁盘映像写入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 -r -3 / 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日志文件

即使这个问题是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个小时。就是说，在十多个小时内，它实际上并没有从驱动器中得到任何东西。这表明您的驱动器可能已拍摄了345GB（或部分）的数据。这对您来说是个坏消息。

相比之下，第二个500GB驱动器刚开始出现“ SMART”错误，将其复制到磁盘（另一个驱动器上有日志文件），整个操作大约花费了8-9个小时。它的最后一部分放慢了速度。但这仍然可以忍受。如上所述，虽然非常糟糕的驱动器在使用500GB内存的情况下已经过去了2个星期，但仍有大约4-5％的空间需要恢复。

HTH和YMMV