不良セクタから「破損したファイル」まで-Linux / ext3でしたか、Windows / NTFSでもできますか？

ディスクの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セクターのオフセット。

これで、どのファイルが「ホストされている」かがわかりました。

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について従うことができる同等の手順はありますか？

— ツシオドラス
ソース

参考までに、現在保留中の9というカウントは、1つだけでなく9つの不良セクターがあることを意味します。拡張セルフテストは、最初に見つかったもので停止します。バックアップから復元する前に、にゼロを書き込んで不良セクタに対処することもできますdd。これにより、ドライブは強制的に修復または再割り当てされます。

— -psusi

うん、あなたは正しい。復元後、私は別のSMARTチェックを行い、すべてが問題ないことを発見しました。したがって、ファイルの書き込みは明らかに9 + 1の不良セクタを上書きしました（およびステージング領域が代替を提供しました）。しかし、Windowsはどうですか？:-)

— ttsiodras

パーティション内のセクターオフセットの計算が間違っていると思います。セクタ番号セクタ32は、パーティションセクタ32-32 == 0でない1であるように、全てゼロベースである（CHS別名、物理的には、他）

衝撃的なことに、1年以上前の質問でこれを誰もまだ言っていません。ドライブで不良セクタを見始めたとき、ドライブの自動内部不良ブロックの再マッピングではこれ以上補償できないことを意味します。バックアップから死にかけているドライブに復元するのではなく、ドライブを交換して新しいドライブに復元する必要があります。

— voretaq7

NTFS FSがあり、そのFSでウィンドウを実行していることを知っています。ライブLinuxをそのドライバーで動作するように「起動」できたかどうかはわかりません。

LinuxをCDまたはUSBから起動できる場合は、ntfsprogsを使用できます。見る -

ntfscluster 

ntfsinfo

ntfsclusterは特定のクラスターが保存するファイルを教えてくれると思います。これがあなたを正しい方向に導くことを願っています。

— JMベッカー
ソース

このフォーラム投稿には、さまざまなファイルシステムでこれを行うユーティリティラッパーがあり、ntfsclusterも使用しています。ubuntuforums.org/showthread.php?t=1943721

— Lethargy

はい、ddrutility機能：不良セクタに関連するファイルを検索します。セクタリストのファイルも使用できます。「badblocks -nvs」+「ddrutility」を使用できます

— diyism