結論: $MFTMirr は最初の MFT レコードの複製を保持する小さなファイルで、少なくともレコード 0〜3($MFT、$MFTMirr、$LogFile、$Volume)、通常は先頭 16 レコードを含みます。NTFS は、メインの $MFT が読めない時に回復をブートストラップするために使います。メインの MFT とそのミラーの両方が読めない場合、chkdsk から 「Windows がマスター ファイル テーブルを回復できません」 が出ます。
ミラーが存在する理由
Master File Table の最初のレコードは重要です。レコード 0 は $MFT 自身を記述し、レコード 2 は $LogFile、レコード 3 は $Volume です。$MFT 先頭のバイトが損傷すると、NTFS はボリューム上の他のどのファイルも見つけられません — 通常なら復旧に使うはずのトランザクション ログさえも。
ミラーがこの循環を断ち切ります。$MFTMirr は別の物理位置にある独立したファイルで、それら先頭レコードの複製を持ちます。ドライバがボリュームをマウントするとき、まず $MFT からレコード 0 を読み、失敗したら $MFTMirr からレコード 0 にフォールバックし、複製を使って残りの場所を特定します。
配置場所
$MFTMirr は MFT のレコード 1 です。その $DATA 属性は非常駐で、伝統的に ボリュームの中央 を指すクラスタ ランを持ちます — $MFT 自身から十分離れているため、1 箇所の局所的な障害(不良クラスタ、ある領域にまたがる torn write)で両方が同時にやられることを防ぎます。
最近の NTFS は LCN clusterCount / 2 に配置します。500 GB のボリュームなら、ミラーはおよそ 250 GB の位置にあります。
ライブ システムから位置を特定できます:
fsutil file queryextents C:\$MFTMirr
内容
$MFTMirr は最初の MFT レコードのバイト単位コピーを保管します。歴史的には先頭 4 レコード(0〜3)が保証されていましたが、現行の Windows は先頭 16 — マスター ファイル テーブルのリファレンス に記述されている NTFS メタデータ セット全体 — をミラーします。
各コピーはフィックスアップ配列も含めた通常の MFT レコードです。$MFTMirr を指し示したパーサーは $MFT を走査するのとまったく同じ手順でこれを走査します。
マウント時の NTFS による使われ方
健全なマウントでは、ドライバは $MFTMirr に触れません。損傷マウントでは:
$MFTのレコード 0 を読む。- 読み取りが I/O エラーを返すかフィックスアップ検証が失敗したら、代わりに
$MFTMirrのレコード 0 を読む。 - ミラーのレコード 0 のコピーが有効なら、そのデータ ランを使ってディスク上の
$MFTを特定する。 - 通常通り続行する。
ミラーは $MFT を 置き換える 必要はありません — 本物を見つけるのに十分な情報を提供すれば足ります。ドライバがミラーのポインタから $MFT を特定したあとは、ライブ テーブルで処理を続行します。
chkdsk による使われ方
chkdsk はより積極的です。$MFT 先頭レコードの破損を検出すると、各レコードをミラーと突き合わせます。両方のコピーが有効で内容が異なる場合、chkdsk は最初の数個の重要レコードについてミラーを正本として扱います(ライブ側のレコードはより最近更新され、その過程で破損したという前提です)。
$MFT も $MFTMirr も読めない場合、chkdsk は Windows cannot recover master file table. CHKDSK aborted を報告します。その時点で復旧には、NTFS の組み込み自己修復ではなく、オフライン ツール — 典型的には生ボリュームを走査する FILE レコードのシグネチャ カービング — が必要になります。
$MFTMirr が完全なバックアップではない理由
ミラーされるのはメタデータ ファイルだけです。レコード 16 以降 — すべてのユーザー ファイルとディレクトリ — は $MFT のみに存在します。$MFT がレコード 16 を超えて損傷していると、ミラーは助けになりません。ミラーはボリュームを マウント するに足るだけで、損傷から任意のファイルを復元するには、ミラーがなくても使う同じ手法が必要です。
フォレンジックでの関心
$MFTMirr が事件で第一級のアーティファクトになることはまれですが、用途は 2 つあります。
- クロス チェック。 ミラーのレコード 0〜15 はライブと bit 単位で一致するはずです。乖離は、片方が帯域外で改ざんされた(ドライバのバグ、意図的な改ざん、部分復旧)ことを示唆します。
- 破損前スナップショット。 ライブの
$MFTレコードが変更されたがミラーがまだフラッシュされていない場合、ミラーは古い状態を保持しています。NTFS は両者を同期させ続けるためこの窓は短いですが、突然の障害事案では唯一のクリーンなコピーになることがあります。
よくある質問
$MFTMirr は MFT 全体のバックアップと同じですか?
いいえ。先頭のいくつかのレコード(システム メタデータ ファイル)のみを含みます。ユーザー ファイルはミラーされません。
$MFT と同じツールで $MFTMirr を解析できますか?
はい。構造的に同一です — 同じレコード形式、同じフィックスアップ配列、同じ属性。ブラウザ パーサー にドロップするか、MFTECmd に渡してください。
$MFTMirr を削除や移動できますか?
いいえ。$MFT と同じく、Windows 稼働中はロックされています。ミラーを完全に無効化することはサポートされておらず、chkdsk はそのボリュームを拒否するでしょう。
ディスクに $MFTMirr がない場合は?
そんなことはありません。すべての NTFS ボリュームにあり、フォーマット時に作成されます。$MFTMirr が欠落または読み取り不能なら、ボリュームは深刻に損傷しており、chkdsk は失敗します。