妻子的 USB HDD 出了点小问题,文件夹无法打开(NTFS 文件系统)。我可以使用 Linux 对该驱动器进行映像处理,但只对一个扇区进行映像处理(扇区为 4096 字节)。读取该扇区失败:
sudo dd if=/dev/sdb of=block skip=21647245 bs=4096 count=1 dd:读取‘/dev/sdb’时出错:输入/输出错误 0+0 条记录 0+0 条记录 已复制 0 字节(0 B),22.9317 秒,0.0 kB/s
用空字节替换该扇区会导致与 Windows 中相同的症状,因此该扇区似乎与有问题的目录有关。
访问所述扇区时,dmesg 输出内容为:
[20381.842495] sd 7:0:0:0: [sdb] 未处理的感知代码 [20381.842506] sd 7:0:0:0:[sdb] [20381.842510] 结果:hostbyte=DID_ERROR driverbyte=DRIVER_SENSE [20381.842514]sd 7:0:0:0:[sdb] [20381.842517] 感知键:硬件错误 [当前] [20381.842531]sd 7:0:0:0:[sdb] [20381.842535] 附加感知:无附加感知信息 [20381.842539]sd 7:0:0:0:[sdb] CDB: [20381.842542] 读取(10):28 00 01 4a 4f 8d 00 00 01 00 [20381.842557] end_request:I/O 错误,dev sdb,扇区 173177960 [20381.842572] 设备 sdb 上的缓冲区 I/O 错误,逻辑块 21647245
有没有办法可以读取该扇区(原始数据),无需 CRC 校验或其他任何操作来实际尝试恢复一些损坏的数据?
我打开了外壳:HDD 是原生 USB,无需 USB 到 SATA 转换。
编辑: 尝试了 ddrescue,但还是无法恢复坏扇区。读取坏扇区周围的 2Gigs,让磁头在寻道后稳定下来:
sudo ddrescue -s 2Gi -o 0 -i 87593373696 /dev/sdb blkk GNU ddrescue 1.19 按 Ctrl-C 中断 已拯救:2147 MB,错误大小:4096 B,当前速率:0 B/s ipos:88667 MB,错误:1,平均速率:8488 kB/s opos:1073 MB,运行时间:4.21 分钟,成功读取时间:1.06 分钟前 完成的
向后读取(-R 标志)也失败了。
编辑2:我计划的第二步是使用取证技术来尝试获取丢失的文件。我首先开始手动查看 MFT,但这很快就变得非常非常乏味。所以我的列表中列出了以下工具:
- 侦探工具
- ntfs-3g
- 解剖刀
- scrounge-ntfs
Sleuthkit 并未做任何有用的事情,很早就退出了,并抱怨元数据结构有错误。
使用 Ntfs-3g (现在是 Tuxera) 可以挂载带有调试输出的图像:
sudo mount -o loop,ro,offset = 258048,debug image2 ./mnt -t ntfs-3g
尝试进入错误的目录将会触发错误:
目录 inode 101874 的索引缓冲区 (VCN 0x0) 的大小 (24) 与目录指定的大小 (4096) 不同。
在 DuckduckGo 中寻找这个错误让我找到了以下帖子: http://www.tuxera.com/forum/viewtopic.php?f=3&t=27054 事实证明,Tuxera / ntfs-3g 的人们实际上鼓励使用 Microsoft 的 CHKDSK 来恢复 NTFS 错误
在磁盘上运行 chkdsk 是我计划的第三步也是最后一步,但是应该尽早尝试,因为它可以在磁盘映像上运行例如使用 OSFMount (http://www.osforensics.com/tools/mount-disk-images.html)。
大多数丢失的文件和目录(如果不是全部)已通过 chkdsk /f 在已安装的磁盘映像上恢复。已修复了一百多个错误(其中大多数是孤立文件)。
编辑3:我接受 psusi 的回答。虽然没有证明这是不可能的,但尝试读取坏扇区无疑是从轻微损坏的硬盘中恢复数据最不确定和最困难的途径。
答案1
不,这是不可能的。有一个 SCSI 命令可以执行此操作,但您仍然只会得到垃圾,并且它在消费级驱动器上不受支持,尤其是 USB。该扇区中的所有内容都消失了。