SMARTディスクのチェックで不良セクターが報告された場合、不良セクターのあるファイルを特定し、それをバックアップから復元できるようにすることが重要です。以下に、その方法を示します。これは私のLinux/ext3 VMWAREサーバー用ですが、これがWindows/NTFSで実行できるかどうかは誰にも分かりますか?
Linux/ext3でこれを実行した方法は次のとおりです。最初にハードウェアサーフェススキャンを実行するようにドライブに要求しました(OSレベルの下、オンドライブ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
そのため、1つのセクターは既に不良としてマークされ、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セクターのオフセット。
これで、「hosed」されたファイルを見つけることができました。
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を起動して、そのドライバーで動作するかどうかはわかりません。
LinuxをCDまたはUSBから起動できる場合は、ntfsprogsを使用できます。見る -
ntfscluster
ntfsinfo
Ntfsclusterは、特定のクラスターが格納するファイルを教えてくれると思います。これであなたが正しい方向に進むことを願っています。