Short answer: $MFTMirr is a small file containing a duplicate of the first MFT records — at minimum records 0–3 ($MFT, $MFTMirr, $LogFile, $Volume), typically the first 16. NTFS uses it to bootstrap recovery when the main $MFT cannot be read. If both the main MFT and its mirror are unreadable, you see "Windows cannot recover master file table" from chkdsk.
Why a mirror exists
The first records of the Master File Table are critical: record 0 describes $MFT itself, record 2 is $LogFile, record 3 is $Volume. If the bytes at the start of $MFT are damaged, NTFS cannot find any of the other files on the volume — including the transaction log it would normally use to recover.
The mirror solves this circularity. $MFTMirr is a separate file at a different physical location, holding a duplicate of those first records. When the driver mounts a volume, it reads record 0 from $MFT; if that fails, it falls back to record 0 from $MFTMirr and uses the duplicate to relocate the rest.
Where it lives
$MFTMirr is MFT record 1. Its $DATA attribute is non-resident, with cluster runs that traditionally point to the middle of the volume — far enough from $MFT itself that a single localized failure (a bad cluster cluster, a torn write across one region) cannot take out both.
Modern NTFS versions place it at LCN clusterCount / 2. On a 500 GB volume that puts the mirror around the 250 GB mark.
You can locate it from a live system:
fsutil file queryextents C:\$MFTMirr
What it contains
$MFTMirr stores byte-for-byte copies of the first MFT records. The historical guarantee was the first four records (0–3); current Windows versions mirror the first sixteen — the entire NTFS metadata set described in the master file table reference.
Each copy is a normal MFT record, fixup array and all. A parser pointed at $MFTMirr walks it exactly the same way it walks $MFT.
How NTFS uses it on mount
On a healthy mount, the driver does not touch $MFTMirr. On a damaged mount:
- Read
$MFTrecord 0. - If the read returns an I/O error or the fixup verification fails, read
$MFTMirrrecord 0 instead. - If the mirror's copy of record 0 is valid, use its data runs to locate
$MFTon disk. - Continue normally.
The mirror does not have to replace $MFT — it just has to provide enough information to find the real one. After the driver has located $MFT from the mirror's pointer, it proceeds with the live table.
How chkdsk uses it
chkdsk is more aggressive. When it detects corruption in the first records of $MFT, it cross-references each record against the mirror. If both copies are valid and differ, chkdsk treats the mirror as authoritative for the first few critical records (the assumption being that the live records were updated more recently and corrupted in the process).
If $MFT is unreadable and the mirror is unreadable, chkdsk reports Windows cannot recover master file table. CHKDSK aborted. At that point recovery requires offline tools — typically signature carving for FILE records across the raw volume — rather than NTFS's built-in self-repair.
Why $MFTMirr is not a complete backup
It only mirrors the metadata files. Records 16 and up — every user file and directory — exist only in $MFT. If $MFT is damaged past record 16, the mirror cannot help you. The mirror is enough to mount the volume; recovering arbitrary files from damage requires the same techniques you would use without it.
Forensic interest
$MFTMirr is rarely the primary artifact in a case, but it has two uses:
- Cross-check. Records 0–15 in the mirror should match the live records bit-for-bit. A divergence suggests one side was modified out-of-band (driver bug, deliberate tampering, partial recovery).
- Pre-corruption snapshot. If the live
$MFTrecords have been modified but the mirror has not yet been flushed, the mirror holds the older state. This window is short — NTFS keeps them in sync — but on a sudden-failure case it can be the only clean copy left.
Frequently asked questions
Is $MFTMirr the same as a backup of the whole MFT?
No. It contains only the first few records (the system metadata files). User files are not mirrored.
Can I parse $MFTMirr with the same tools as $MFT?
Yes. It is structurally identical — same record format, same fixup array, same attributes. Drop it onto the browser parser or feed it to MFTECmd.
Can I delete or move $MFTMirr?
No. Like $MFT, it is locked while Windows is running. Disabling the mirror entirely is not a supported operation; chkdsk would refuse the volume.
What happens if my disk has no $MFTMirr?
It does. Every NTFS volume has one, created at format time. If $MFTMirr is missing or unreadable, the volume is severely damaged and chkdsk will fail.