NTFSパーティションにアクセスできなくなり、3つのMFTレコードが破損しました。修正方法は？

Question

NTFSパーティションが1つある2TBSeagate ST2000DM001HDDがあります。何ヶ月も使用していませんでした。もう一度接続すると、このパーティションに不可解にアクセスできなくなりました。ボリュームの文字がWindowsエクスプローラーに表示されますが、パーティションのサイズが認識されなくなります。開こうとするとエラーが発生します。ストレージマネージャに「RAW」と表示されます。 CHKDSKは、ボリュームのバージョンと状態を判別できないというエラーメッセージを表示して、すぐに分析をあきらめます。

それでも、R-Studioでそのドライブを開くと、パーティションは正しいサイズですぐに表示され（スキャンも必要ありません）、それを開いて、最後に通常使用したときにそこにあったすべてのファイルにアクセスできます。ディレクトリツリー全体、およびファイルの内容は、私が見る限り100％正しいように見えます。同様に、WinHexでドライブ全体を開くと、パーティションが正しく認識され、ファイルとフォルダーが正しい内容で表示されます。また、2つのデフラグソフトウェアをテストしました（分析モードのみ）：MyDefragはパーティションの内容を一覧表示し、マウスポインターでカーソルを合わせた各ブロックの有効な情報（ファイル名、サイズ、LBA ...）を提供します。しかし、Defragglerはできません。また、DMDEで開きました。R-Studioのように、パーティションの内容を即座に認識できます。また、MFTレコード1、2、3に関する赤い警告も表示されます。これらは通常、$ MFTMirr、$ LogFileおよび$ Volume、3つの重要なシステムファイル。これらは実際には「$ MetaData」ディレクトリにありません。 R-Studioに戻ると、これらのファイルも「メタファイル」ディレクトリにないことがわかります。 WinHexでMFTの始まりを調べると、MFTレコード0は問題ない（MFT自体を指している）ことがわかりますが、MFTレコード1、2、および3が破損しています、「FF」（16進数）/「ÿ」（ASCII）で埋められます。そして奇妙なことに、MFTミラー（問題が発生する前に作成された古いボリュームスナップショットを使用してWinHexで見つけることができます。また、その場所はR-Studioによってパーティションプロパティパネルに示されます。明らかにMFTとMFTMirrのLBAはブートセクターで記述されています）は、まったく同じ破損パターンを持っています。最初のレコードは問題なく、次の3つは「FF」で埋められます。

さて、私の推測では、これらの3つのMFTレコードが欠落しているため、パーティションにアクセスできず、対応するファイルが見つかりません。また、CHKDSKが正しく動作するには、少なくともこれらのファイルが必要です。どうしてそれが起こるのでしょうか？ MFTとそのミラー（実際には最初の4つのレコードのコピーのみですが、この特定のケースでは、3つの破損したレコードが4つに含まれているため、問題を修正するのに十分なはずです）の両方がで破損する可能性があります。同時？
そしてすべてを抽出するのではなく、パーティションを「インプレース」で修正するために、欠落しているMFTレコードを修正/再作成するにはどうすればよいですか？ファイル（安全対策としてすでに実行しました）、パーティションを再フォーマットして、それらを転送し直しますか？テンプレートを知っていれば、別のパーティションから有効なレコードをコピーして変数値を変更できましたが、これまでのところ、タイムスタンプしか識別できませんでした（同じパーティション上の他のシステムファイルからコピーできるのは、すべてで作成されているためです）。まったく同じ時間）、クラスターの場所のサイズを示すフィールドをまだ見つけることができません。また、常駐ファイル（完全にMFTにある）である$ Volumeには、パーティションの一意の識別子が含まれていることもわかりました。これは、ここで最も問題となるハードルである可能性があります。パーティションが適切に機能するためには、必ず以前と同じである必要があります。認識され、その場合、システムのどこかに保存されますか、それともランダムに選択できますか？その場合、準拠する必要のある特定のパターンがありますか？ MFTレコードの基本構造に関する情報は、このような場合には役に立たないほど広い範囲の曲がりくねったフォーラムスレッドや記事の数千ページの中から、不足しているか、見つけるのが非常に難しいようです。

HDDGuruの詳細で問題を説明しましたが、「どうすれば修正できますか？」という質問に対する適切な回答がありませんでした。（ハードウェア/ファームウェアの障害に関しては、定期的な寄稿者は非常に知識が豊富ですが、そのような論理的な障害については、かなり早く諦めているようです）。
http://forum.hddguru.com/viewtopic.php?f=1&t=36969

GabrielB · Answer

それで、私は自分で問題を修正することができました。いくつかの有効なパーティションでそれらを調べながら、一般的なMFTレコードの構造、および再作成する必要のある3つの破損したレコードの特定の構造（詳細についてはリンクされたHDDGuruスレッドを参照）について調査しました。次に、基本的に、それらを有効なパーティションからWinHexの一時ファイルにコピーし、パーティションごとに異なるいくつかのキー値を変更してから、3072バイトのファイルをパーティションに直接コピーし、CHKDSKを実行しました。これにより、続行できます。いくつかの試行とエラー）は、ボリュームにエラーがないことを報告し、パーティションは通常、再びアクセス可能になりました。それがどのように起こったのかはまだわかりませんが、修正されました！

私が変更しなければならなかった値は次のとおりです。
–タイムスタンプ：すべてのシステムファイルのタイムスタンプが同じであるため、破損したパーティションの最初のMFTレコード（MFT自体を指す）からタイムスタンプフィールドをコピーしました。
– DMDEの「fixup」と呼ばれる各レコードに1バイトのフィールドがあり、それぞれの3つの異なる場所に存在します。これは、HDDGuruスレッドで誰かが私に説明したように、「レコードを確認するためのチェック」です。有効で破損していない」であり、そのフィールドの3つのインスタンスすべてで同じである限り、任意の値に設定できます。
– $ LogFileレコードの最初のクラスターLBA（古いWinHexボリュームスナップショットのおかげでファイルがどこにあるかがわかりました。そうでない場合は、ヘッダーに基づいてファイルを検索してその値を取得する必要がありました。デフォルトサイズは正確に64MB、つまり67108864バイトで、調べたすべてのパーティションで同じです）;
– $ Volumeレコード（実際の$ Volumeファイルも含まれています。そのファイルは「常駐」であるため、つまり完全にMFTレコードに含まれているため）の場合、元の16バイトID（または「最もトリッキーな部分であるボリュームのオブジェクト識別子」）：試行に失敗した後、「システムボリューム情報」ディレクトリの「tracking.log」ファイル内にその値が見つかりました（最初に有効なパーティションを確認しました）、値は$ Volumeに表示された値と一致したため、破損したパーティションの「tracking.log」から対応するフィールドをコピーし、$ VolumeのボリュームIDフィールドに貼り付けました）;
– $ Volumeでも、ボリュームの名前を以前と同じ名前に変更しましたが、それは必須ではありませんでした。他のパーティションから名前を取得して、後でボリュームのプロパティで変更することもできました。再びアクセスできるようになったら（実際、ここでちょっとしたトリックを使用しました。「TEMP」というパーティションから$ Volumeレコードの末尾をコピーし、パーティションが以前に呼び出されたときにその名前を「Stockage」に変更する代わりに、予期しないオフセットを回避し、「使用済みサイズ」の値が一致することを確認するために、「Stoc」を同じ文字数になるように配置します。これは、の構造をまだ完全には理解していないためです。レコード）;
–ボリュームの名前を変更したため、実際に使用されるファイルレコードの長さが異なるため、これを反映して一貫性を保つために、「使用サイズ」に対応するフィールドを変更する必要がありました（同じ「「TEMP」と呼ばれるパーティションからのものとして「使用されたサイズ」）;
– DMDEの「LSNlo」と呼ばれる$ Volumeレコードの先頭に、異なる別の値がありました。私の調査によると、「LSN」は「$ LogFileSequenceNumber」の略です。これは参照です。 $ MFT内の特定のファイルレコードに関して$ LogFileに記録された最後の変更まで、一貫性にとって重要ではありません。とにかく、$ LogFileのサイズが制限されているため、古いレコードが定期的に「パージ」されることがわかりました。そのドライブを数か月使用していなかったため、ワイプされる前に存在していた値に対応するレコードが削除されたため、そのフィールドにゼロを入力しました。

@DrMoishe Pippik：安全対策として、このインプレース修正を試みる前に、R-Studioを使用してコンテンツ全体を別のドライブに抽出しました。また、最初の5GBの部分バックアップを作成しました（これは、関連するすべてのファイルシステム構造を含むのに十分です。ただし、MFT全体を取得するのに必ずしも十分ではないことを強調しておく必要があります難しい方法で学びました =！）。別のコンピューターでドライブにアクセスしようとしたことはありませんが、ドライブがどのように異なっていたかはわかりません（とにかく、Windowsシステムでは-おそらくLinuxシステムでは認識されてアクセス可能でした）。 MFTレコードはWinHexで効果的に消去されたように見え、再起動後も問題は解決しませんでした。

@cybernard：TestDiskを試しました。これは、S.M.A.R.T.ステータス（これは問題ありませんでした）を確認した後の最初のアイデアの1つです）：パーティションを検出し、ファイルを一覧表示できました（私が言及した他のソフトウェアのように）、しかし、MFT破損の場合にできることは、最初の4つのレコードを$ MFTMirrからコピーして修復することだけなので、問題を修正できませんでしたが、ここでは、これら3つの破損したレコードも破損しています$ MFTMirrで、まったく同じ方法で。

@Andrea Lazzarotto：私の観察によれば、$ MFTMirrは常にセクター16にあります。したがって、ボリュームの最初の部分で、実際の$ MFTのずっと前にあります。これは、デフォルトで3GBのマーク付近です。 CHKDSKは、$ MFTMirrも破損しているため、おそらく機能しませんでした。そのため、MFTレコードの一部であるためにワイプされた明らかに重要な$ Volumeファイルにアクセスできませんでした。