当磁盘上的SMART检查报告坏扇区时,能够识别具有坏扇区的文件并从备份中恢复它是很重要的.下面,我将展示如何为我的
Linux / ext3 VMWARE服务器执行此操作 – 但有人知道是否可以为Windows / NTFS执行此操作吗？
这是我为Linux / ext3做的：我首先要求驱动器进行硬件表面扫描(低于操作系统级别,驱动器上的SMART电路)：
vserver:~# smartctl -t long /dev/sdc
我查看了结果：
vserver:~# smartctl -a /dev/sdc ... 196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 1 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 9 ... Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed: read failure 90% 27679 591363172
因此,一个部门已经被标记为坏,9个被标记为从“升级”部门空间取代.更重要的是,第一个不可读的逻辑块地址(LBA)是591363172.
我找到了这个数字“翻译”到的分区(以及它内部的偏移量)：
vserver:~# fdisk -lu /dev/sdc Device Boot Start End Blocks Id System /dev/sdc1 32 976773119 488386544 83 Linux
分区从32区开始.所以,坏区是……
vserver:~# bc -l 591363172-32+1 591363141
…从分区开始的591363141个扇区的偏移量.
现在我可以找到哪个文件被“软管”：
vserver:~# tune2fs -l /dev/sdc1 | grep Block\ size Block size: 4096
这个EXT3文件系统的块大小是4096字节,所以坏扇区在文件系统中破坏了这个块：
vserver:~# bc -l 591363141*512/4096 73920392.62500000000000000000
并且块号(73920392)对应于此文件：
vserver:~# debugfs debugfs 1.41.3 (12-Oct-2008) debugfs: open /dev/sdc1 testb 73920392 debugfs: testb 73920392 Block 73920392 marked in use debugfs: icheck 73920392 Block Inode number 73920392 18472967 debugfs: ncheck 18472967 Inode Pathname 18472967 /path/to/filewithbadsector
我从备份中恢复了该文件.
我可以遵循Windows / NTFS的等效程序吗？
解决方法
我知道你有一个NTFS FS,并在该FS上运行Windows.
我不知道你是否“可以”启动一个实时Linux来处理该驱动程序.
我不知道你是否“可以”启动一个实时Linux来处理该驱动程序.
如果您可以从CD或USB启动Linux,
你可以使用ntfsprogs.看着 –
ntfscluster ntfsinfo
我相信ntfscluster会告诉你特定集群存储的文件.我希望这会让你朝着正确的方向前进.
