当磁盘上的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个扇区的偏移处。
现在我可以find哪个文件被“洗”了:
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上运行窗口。 我不知道你是否“能”启动一个活的Linux来运行该驱动程序。
如果您可以从CD或USB启动Linux,则可以使用ntfsprogs。 看着 –
ntfscluster ntfsinfo
我相信ntfscluster告诉你一个特定的集群存储什么文件。 我希望这能使你走向正确的方向。