![为什么 ddrescue 不能只恢复文件系统使用的块?](https://linux22.com/image/1394097/%E4%B8%BA%E4%BB%80%E4%B9%88%20ddrescue%20%E4%B8%8D%E8%83%BD%E5%8F%AA%E6%81%A2%E5%A4%8D%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F%E4%BD%BF%E7%94%A8%E7%9A%84%E5%9D%97%EF%BC%9F.png)
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
通常用于数据已损坏且可能不一致的情况。在这种情况下尝试查找已使用的块是有风险的 - 如果空闲块列表本身已损坏(但仍然可读)怎么办?或者文件的当前版本可能不再可恢复,但文件的旧版本仍存在于空闲块中(因为文件系统没有就地覆盖)。
在这种情况下,唯一安全的选择就是抓住一切,然后再理清细节。