$MFTMirr is the smallest insurance policy in NTFS. It mirrors the first records of $MFT so that when the bytes at the start of the main table are unreadable, the filesystem driver still has a way to find every file on the volume. It is also the artifact people forget to acquire and then need three weeks later.
This is what it actually contains, where it sits on disk, when NTFS uses it, and the (limited) cases where it earns its keep in forensics.
Why a mirror exists at all
The first records of $MFT are load-bearing. Record 0 is $MFT itself, with a $DATA runlist that says where the rest of the table lives on disk. 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 from filesystem inconsistencies.
That is a circular dependency: you need $MFT to find $LogFile, but you need $LogFile to fix $MFT. The mirror breaks the cycle. $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 read fails or the fixup array does not verify, 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, and its runlist traditionally points to the middle of the volume so that a single localized failure (one bad sector, one torn write across one region) cannot take out both copies. Modern NTFS places it at LCN clusterCount / 2. On a 500 GB volume that puts the mirror around the 250 GB mark.
You can find it from a live system:
fsutil file queryextents C:\$MFTMirr
That returns the cluster runs $MFTMirr occupies, which a raw read can reassemble. KAPE's MFT target collects it alongside $MFT by default. If you are using FTK Imager, it sits next to $MFT in the root of the NTFS volume.
What it contains
Byte-for-byte copies of the first MFT records. The historical guarantee was the first four records (0 to 3, the truly essential metadata). Current Windows versions mirror the first sixteen, which is the entire NTFS metadata set described in the master file table reference.
Each copy is a normal MFT record. Same FILE signature, same header, same fixup array, same attribute stream. A parser pointed at $MFTMirr walks it exactly the way it walks $MFT. MFTECmd, mft_dump, analyzeMFT, and Sleuth Kit's fls all accept it as input.
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
$DATArunlist to locate$MFTon disk and continue.
The mirror does not have to replace $MFT. It only 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 but 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: signature carving for FILE records across the raw volume with Sleuth Kit, R-Studio, or testdisk. NTFS's built-in self-repair is exhausted.
Why $MFTMirr is not a complete backup
It only mirrors the metadata files. Records 16 and up, which is 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.
This is the misconception that costs people time in IR engagements. They reach for $MFTMirr thinking it is a full historical snapshot. It is not. For that, you want Volume Shadow Copies, each of which contains an actual point-in-time copy of the full $MFT.
Forensic interest
$MFTMirr is rarely the primary artifact in a case, but it has two real uses:
- Cross-check. Records 0 to 15 in the mirror should match the live records bit for bit. A divergence suggests one side was modified out of band: a driver bug, deliberate tampering, partial recovery after a crash, or a poorly-written wiper that scribbled on the live MFT and missed the mirror. I have seen exactly one case where the mirror caught a wiper that overwrote the first 16 records of
$MFTand did not realize a copy lived elsewhere on the volume. The reconstruction worked because the mirror was intact. - Pre-corruption snapshot. If the live
$MFTrecords have been modified but the mirror has not yet been flushed (NTFS keeps them in sync but there is a small window), the mirror holds the older state. This window is short, milliseconds in normal operation, but on a sudden-failure case it can be the only clean copy.
Beyond those cases, treat $MFTMirr as something you collect routinely (KAPE does it for you) and rarely need to look at.
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.
Further reading
- Microsoft, NTFS Reserved Files. Official catalog of the metadata files in the first 16 records.
- The linux-ntfs project's $MFTMirr notes. Practical write-up of the mirror's role from a parser implementer's perspective.
- Brian Carrier, File System Forensic Analysis. Chapter on NTFS metadata files explains the mount-time recovery path.