ddrescue 似乎试图恢复磁盘或分区上的所有块，甚至不包含文件的块。它是否可以通过查看文件系统（例如 NTFS 上的主文件表）来找出哪些块实际包含文件？
编辑：看来它可能与 partclone 结合使用：
http://partclone.org/features/
对于救援情况，Partclone 的救援模式将尝试跳过坏块并备份分区的所有好块。ddrescue 程序是另一种更好的解决方案，可以挽救坏磁盘，而借助 partclone 的帮助，通过将所有使用的块列为域文件，它可以使 ddrescue 在转储分区时更智能、更快速。
也可以看看： http://sourceforge.net/p/partclone/mailman/partclone-user/thread/[电子邮件保护]/
答案1
简短回答：因为这不是它的用途。Ddrescue 只做一件事（1：1 复制故障硬盘），而且做得很好。
答案2
我认为这是不可能的，因为 ddrescue 和 dd 本身一样，旨在对任何块设备进行操作，即使是没有文件系统或文件系统已损坏的设备。查看文件系统（如果存在）只会让事情变得复杂。
答案3
旧线程但可能对其他人有帮助...
如果输入的是 NTFS 格式的卷，您可以使用 ddrutility 中的 ddru_ntfsbitmap，通过使用 $Bitmap 系统文件为 ddrescue 生成一个映射文件，该文件正是 NTFS 分区上已使用/未使用簇的映射。当然，它要求 $Bitmap 文件完整无缺，位于完全可读的区域，才能正常工作（通常它位于分区的开头）。如果是这种情况，它会很快进行（在我的第一次也是迄今为止唯一的体验中，从 1TB 分区生成映射文件大约需要 2 分钟）。然后，您可以使用以下基本命令运行 ddrescue：
ddrescue [options] [input path] [output path] [logfile] -m [mapfile]
在 ddrescue 的最新版本中，术语“logfile”（即在恢复期间保存输入卷的已挽救/未尝试/坏区的文件）已被“mapfile”取代，这让人非常困惑。因此，例如，如果您想要使用由 ddru_ntfsbitmap 生成的名为 Recovery_bitmap.log 的 mapfile 将名为 /dev/sdc 的 HDD 恢复到名为 Recovery 的 /media/sdd1 上的映像，则命令应为：
ddrescue [options] /dev/sdc /dev/sdd1/Recovery /dev/sdd1/Recovery.log -m /dev/sdd1/Recovery_bitmap.log
答案4
主要原因可能是它会使ddrescue代码变得更加复杂，因为它需要合并有关各种文件系统的信息并解析其内部结构。
但是，即使忽略额外的开发工作，尝试找出哪些块包含数据通常也很困难。ddrescue通常用于数据已损坏且可能不一致的情况。在这种情况下尝试查找已使用的块是有风险的 - 如果空闲块列表本身已损坏（但仍然可读）怎么办？或者文件的当前版本可能不再可恢复，但文件的旧版本仍存在于空闲块中（因为文件系统没有就地覆盖）。
在这种情况下，唯一安全的选择就是抓住一切，然后再理清细节。