$MFTMirr は NTFS の中で最小の保険です。$MFT の最初のレコードをミラーリングしているため、メインテーブルの先頭のバイトが読み取れなくなっても、ファイルシステムドライバはボリューム上のあらゆるファイルを見つける手段を持っています。同時に、人が取得するのを忘れて、3 週間後に必要になるアーティファクトでもあります。
これが実際に含むもの、ディスク上のどこに位置するか、NTFS がそれをいつ使うか、そしてフォレンジックで真価を発揮する（限定的な）ケースです。
なぜミラーが存在するのか
$MFT の最初のレコードは骨組みです。レコード 0 は $MFT 自身で、テーブルの残りがディスク上のどこに存在するかを示す $DATA ランリストを持ちます。レコード 2 は $LogFile。レコード 3 は $Volume。$MFT の先頭のバイトが損傷していると、NTFS はボリューム上のほかのファイルを見つけることができず、ファイルシステムの不整合から回復するために通常使用するトランザクションログにもたどり着けません。
これは循環依存です。$LogFile を見つけるために $MFT が必要ですが、$MFT を修正するために $LogFile が必要です。ミラーがこのサイクルを断ち切ります。$MFTMirr は、最初のレコードの複製を保持する、物理的に別の場所にある独立したファイルです。ドライバがボリュームをマウントするとき、$MFT のレコード 0 を読み取ります。それが失敗するか fixup 配列が検証できない場合、$MFTMirr のレコード 0 にフォールバックし、その複製を使って残りを位置付けます。
ディスク上の場所
$MFTMirr は MFT レコード 1 です。その $DATA 属性は非レジデントで、ランリストは伝統的に ボリュームの中央 を指します。これにより、単一の局所的な故障（1 つの不良セクタ、1 つの領域にまたがる torn write）が両方のコピーを同時に潰さないようになっています。最新の NTFS は LCN clusterCount / 2 に配置します。500 GB のボリュームでは、ミラーは 250 GB あたりに位置します。
ライブシステムから見つけることができます。
fsutil file queryextents C:\$MFTMirr
$MFTMirr が占めるクラスタランが返され、生の読み取りで組み立て直せます。KAPE の MFT ターゲットはデフォルトで $MFT と並んでこれを収集します。FTK Imager を使う場合は、NTFS ボリュームのルートで $MFT の隣に座っています。
内容
最初の MFT レコードのバイト単位のコピーです。歴史的な保証は最初の 4 レコード（0 から 3、真に必須のメタデータ）でした。現在の Windows バージョンは最初の 16 レコードをミラーリングし、これは マスターファイルテーブルリファレンス で説明されている NTFS メタデータセット全体です。
各コピーは通常の MFT レコードです。同じ FILE シグネチャ、同じヘッダ、同じ fixup 配列、同じ属性ストリーム。$MFTMirr に向けたパーサは $MFT を走査するのとまったく同じ方法で走査します。MFTECmd、mft_dump、analyzeMFT、Sleuth Kit の fls はすべてこれを入力として受け入れます。
マウント時に NTFS がそれをどう使うか
健全なマウントでは、ドライバは $MFTMirr に触れません。損傷したマウントでは次のようになります。
$MFTのレコード 0 を読み取ります。- 読み取りが I/O エラーを返した場合、または fixup 検証が失敗した場合、代わりに
$MFTMirrのレコード 0 を読み取ります。 - ミラーのレコード 0 のコピーが有効であれば、その
$DATAランリストを使って$MFTをディスク上で位置付け続行します。
ミラーは $MFT を 置き換える 必要はありません。本物を見つけるのに十分な情報を提供するだけで足ります。ドライバがミラーのポインタから $MFT を位置付けた後は、ライブテーブルに進みます。
chkdsk がそれをどう使うか
chkdsk はもっと積極的です。$MFT の最初のレコードに破損を検出すると、各レコードをミラーと相互参照します。両方のコピーが有効だが異なる場合、chkdsk は最初の数個の重要なレコードについてミラーを権威として扱います（仮定は、ライブレコードがより最近に更新され、その過程で破損したというもの）。
$MFT が読み取り不能で かつ ミラーも読み取り不能の場合、chkdsk は Windows cannot recover master file table. CHKDSK aborted を報告します。その時点で、回復にはオフラインツールが必要です。Sleuth Kit、R-Studio、testdisk を使って生のボリュームから FILE レコードのシグネチャカービングを行います。NTFS の組み込み自己修復は尽きています。
$MFTMirr が完全なバックアップではない理由
メタデータファイルのみをミラーリングします。レコード 16 以降は、ユーザーファイルやディレクトリすべてですが、これらは $MFT 内にのみ存在します。$MFT がレコード 16 を超えて損傷している場合、ミラーは助けになりません。ミラーはボリュームを マウント するのに十分です。損傷から任意のファイルを回復するには、ミラーなしで使うのと同じテクニックが必要です。
これが IR 業務で時間を奪う誤解です。$MFTMirr を完全な履歴スナップショットと勘違いして手を伸ばす人がいます。そうではありません。それには Volume Shadow Copy が欲しいところで、それぞれが完全な $MFT の特定時点のコピーを実際に含みます。
フォレンジックでの関心
$MFTMirr がケースで主要なアーティファクトであることは稀ですが、2 つの実際の用途があります。
- クロスチェック。 ミラーのレコード 0 から 15 は、ライブレコードとビット単位で一致するはずです。乖離があれば、どちらかの側が帯域外で修正されたことを示唆します。ドライバのバグ、意図的な改ざん、クラッシュ後の部分的な回復、または
$MFTの最初の 16 レコードに落書きしてミラーがボリュームの別の場所にあることに気付かなかった出来の悪いワイパーです。私はミラーが、$MFTの最初の 16 レコードを上書きしてミラーがボリュームの別の場所にあることに気付かなかったワイパーを捕まえたケースを 1 件だけ見ました。ミラーが無傷だったため再構築は成功しました。 - 破損前スナップショット。 ライブの
$MFTレコードが変更されたがミラーがまだフラッシュされていない場合（NTFS は同期を保ちますが小さなウィンドウがあります）、ミラーはより古い状態を保持します。このウィンドウは短く、通常運用ではミリ秒ですが、突然の障害ケースでは唯一のクリーンなコピーになり得ます。
それらのケース以外では、$MFTMirr は習慣的に収集するもの（KAPE が代わりに行います）であり、見る必要があるのは稀だと思ってください。
よくある質問
$MFTMirr は MFT 全体のバックアップと同じですか？
いいえ。最初の数レコード（システムメタデータファイル）のみを含みます。ユーザーファイルはミラーリングされません。
$MFT と同じツールで $MFTMirr を解析できますか？
はい。構造的に同一です。同じレコードフォーマット、同じ fixup 配列、同じ属性。ブラウザパーサ にドロップするか、MFTECmd に渡してください。
$MFTMirr を削除または移動できますか？
いいえ。$MFT と同様、Windows の実行中はロックされています。ミラーを完全に無効化することはサポートされていません。chkdsk はそのボリュームを拒否します。
私のディスクに $MFTMirr がないとどうなりますか？
存在します。すべての NTFS ボリュームには 1 つあり、フォーマット時に作成されます。$MFTMirr が欠落しているか読み取り不能であれば、ボリュームは深刻に損傷しており、chkdsk は失敗します。
参考資料
- Microsoft, NTFS Reserved Files。最初の 16 レコードのメタデータファイルの公式カタログです。
- linux-ntfs プロジェクトの $MFTMirr ノート。パーサ実装者の視点からのミラーの役割の実用的な解説です。
- Brian Carrier, File System Forensic Analysis。NTFS メタデータファイルの章は、マウント時の回復経路を説明しています。