为什么 ddrescue 无法实时压缩图像？

Question

我正在尝试使用 GNU 的ddrescue来恢复一个垂死的硬盘驱动器上的文件。驱动器相当大（1TB），我所需要存储的图像是另一个 1TB 驱动器。

ddrescue 接近尾声时失败，并显示有关磁盘空间的错误，即使使用 -S 选项也是如此。

为什么不能在创建图像时对其进行压缩？dd和dd_rescue是可能的。

另外，man ddrescue说 -S 选项不适用于所有系统，但我怎么知道它是否适用于我的系统？

Answer 1

gddrescue 不会按顺序对文件进行映像 - 它会返回并重试并填充空白，我怀疑这就是您无法有效地将其导入其他内容的原因。手册页详细介绍了这一点

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

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

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

它的设计使然，不幸的是，解决方案是获得更大的驱动器。为了使 -S 参数起作用，我相信源驱动器上的已用空间必须小于目标驱动器。

Answer 2

它是可以与创建压缩的图像ddrescue上的动态。事情是，ddrescue需要一个可搜索的目的地，因为它会经过多次传递（因此必须能够向后跳以填补早期的空白，正如@JourneymanGeek 在他的回答中所解释的那样）。这意味着您不能使用管道作为输出，因为管道是不可查找的。因此，您不能通过管道传输到压缩程序。

解决此问题的一种方法是使用透明压缩。一些文件系统（特别是 Btrfs 等）提供了这种内置功能。或者，您可以使用文件系统驱动程序来提供透明、可查找的压缩存储，例如fusecompress。