这是我第一次使用dd命令。我执行：
dd if=/dev/sdb2 of=/mnt/sdc1/Hdd1.img bs=512 conv=noerror,sync
其中 sdb 是损坏的硬盘（大小：500 GB）。我将分区 sdb2 复制到映像中。我已经做了 6(!!) 天了。 img 大小约为 640 GB 并且仍在计算中（即：尚未完成......）。 6 天后，它正在打印复制的数据详细信息（复制到哪个字节）并且没有停止。
正常吗？ img 大小怎么可能大于整个损坏的硬盘大小？预计什么时候完成？
答案1
通过一次复制 512 个字节，您将执行大量的读取和写入操作。如果你算一下，实际上大约有一万亿。您还要求同步[编辑：这不是oflag=sync所以下一个语句无效]，这意味着等待每个写入实际写入磁盘，然后才能返回。假设您的磁盘速度非常快，因此每次写入需要 2 毫秒。
500GB / 512 字节 * 2 毫秒 = 22.6 天。
哇，数万亿毫秒加起来很快，不是吗？
[编辑：虽然这确实是一个有趣的数学，但它并不准确，因为oflag=sync没有使用。延迟更有可能是由于反复读取坏扇区和相关的超时造成的。下面的 dd_rescue 方法应该会有很大帮助。使用具有较大块大小的普通 dd 可能会有所帮助，但效果不大，因为它无法调整其读取大小并且不会跳过巨大的损坏。]
如果您使用更大的块大小和/或跳过同步，它将运行得更快：
# dd if=/dev/sdb2 of=/sdb2-image.img bs=1024k
如果您担心 sdb2 映像读取时出现读取错误，请使用 dd_rescue 和 -A 选项来写出一个零块，而不是跳过该写入。当某些文件系统结构出现在与原来不同的偏移量时，完全跳过有错误的块可能会导致问题。最好有一些意想不到的零。例如：
# dd_rescue -A /dev/sdb2 /sdb2-image.img
这将开始一次读取大数据块，并且仅在开始出现错误时减少数据块。
编辑：要直接回答问题，正如 Micheal Johnson 所建议的，当使用conv=noerror,syncondd或-Aon 时dd_rescue，您的图像最终的大小将与源的大小完全相同。这是因为每次读取都会生成相同大小的写入。某些版本dd可能会在设备结束后长时间运行，因为它们会根据您的请求忽略文件结束“错误” conv=noerror。我不认为 Linux 会这样做，但如果您的图像看起来比源文件大，则需要注意这一点。
答案2
映像的大小与您从中创建映像的分区的大小相同。您没有说您的分区有多大，但如果它是硬盘驱动器总容量的一半，那么您所说的大小并不是不合理，具体取决于硬盘驱动器的大小。重要的是，您保存映像的分区的可用空间至少与您要映像的分区的大小一样多 - 如果不是，则操作将失败，并出现“设备上没有剩余空间”错误。另外，如果sdc“被破坏”，那么将图像保存到sdc1（如图像文件路径所示）可能是一个坏主意 - 也许您可以澄清“被破坏”的含义？
无论如何，史蒂夫·邦兹的回答解释了为什么花了这么长时间，但这不是你问的问题。