Recovering deleted files from NTFS using the MFT

Recovering deleted files on NTFS comes down to two clocks and one short rule. The clocks: how long until the MFT record slot is reused, and how long until the data clusters are overwritten. The rule: do not write to the volume while either clock is still useful to you.

This is the recovery workflow I actually run when someone hands me an NTFS volume and says "they deleted X, can we get it back". It pulls from the same toolbox no matter whether X is a single file, a directory tree, or the contents of an SDelete-touched directory.

Why deletion does not erase

When Windows deletes a file from an NTFS volume:

The IN_USE flag (bit 0 in the record header flags at offset 0x16) is cleared.
The clusters that held the data are marked free in $Bitmap.
The parent directory's $INDEX_ROOT entry is removed.

What does not happen: nothing overwrites the record or the clusters. They are flagged available for the next allocation. Until something else claims them, the file is recoverable. See what survives a delete for the field-by-field detail.

The MFT slot recovery clock and the data cluster recovery clock are independent. You can have a record that has been reused (the slot is now a different file) but whose data clusters still hold the old bytes. You can have an intact deleted record whose clusters have been allocated to a new file. The two situations require different recovery strategies.

Step 1: stop writing to the volume

Every write you make on the volume risks reusing a deleted record's slot or its data clusters. If the file matters:

Stop the application that touched it. If it was a database, stop the engine. If it was a document, close the editor.
If the file lived on the system drive and the system is still running, the OS itself is constantly writing (paging, prefetch, registry, event logs). Power down or boot from external media. A live system is leaking recoverable space by the second.
For an external drive, unmount immediately. On Windows, eject; on Linux, umount.

This is the step people skip when they think recovery is going to be "easy". Half of the failed-recovery cases I have seen failed at this step.

Step 2: image the disk

Work on a copy, never the original. The standard options:

FTK Imager: free, GUI, produces .dd or .E01 images. Hashes the source during read.
dd on Linux: dd if=/dev/sdX of=disk.img bs=4M conv=noerror,sync status=progress. Fast on healthy drives.
ddrescue: slower, but tolerates read errors on failing drives. The right choice when the drive is the problem (clicking, slow reads, SMART warnings).

Hash the image (SHA-256) immediately after acquisition. Every later step works against the image, never the original.

Step 3: pick the right recovery approach

The approach depends on what is still intact.

MFT replay when the deleted file's record is still in the table. Parse $MFT with a tool that lists deleted records. The file's name, timestamps, parent directory, and (for small files) data are recoverable from the record. For non-resident files, the runlist still points at the original clusters; if those clusters were not yet overwritten, icat or equivalent extracts the data.

MFTECmd lists deleted records and tags resident data.
The browser parser filters to deleted entries with one click and shows resident data inline.
Sleuth Kit's fls -d -m lists deleted entries; icat -r recovers their data when possible.

File-system-aware recovery tools when you want a GUI-driven selective restore from a volume or image:

R-Studio: commercial, the analyst's pick for NTFS. Handles complex damage, recovers from formatted volumes, understands EFS and BitLocker (with key).
TestDisk + PhotoRec: free, mature, good for partition damage. PhotoRec is signature carving rather than filesystem-aware, so it loses filenames.
Recuva: consumer grade. Fine for single-file single-drive recoveries on uncomplicated volumes. Not what I would use for an investigation.

Signature carving when the MFT is gone or the record has been reused. scalpel, foremost, and PhotoRec scan the raw image for known file signatures (JPEG FF D8 FF, PNG 89 50 4E 47, ZIP 50 4B 03 04, PDF 25 50 44 46) and reassemble what they find. Carved files lose their filenames and timestamps; those lived in the MFT. The bytes themselves come back, modulo fragmentation.

For fragmented files, signature carving struggles. The carvers concatenate consecutive clusters that look right, but if the file was scattered across the disk they cannot reassemble it. NTFS-aware MFT replay handles fragmentation correctly because the runlist explicitly describes every fragment.

Step 4: when MFT recovery is the only path

Small files (under ~700 bytes of $DATA) live entirely inside the MFT record. Even if $Bitmap has been overwritten dozens of times, the resident bytes still sit in the record until the slot is reused. See resident data.

For a small text file, a small JSON config, a PowerShell script, a registry export, a small certificate, or a .lnk file, the browser parser is often the fastest path: drop the extracted $MFT, filter to deleted entries, look for records with resident $DATA, and copy the bytes back out. This works when nothing else does because the data never left the MFT in the first place.

What is genuinely unrecoverable

Overwritten clusters. Modern HDDs and SSDs offer no realistic path to recover data that has been written over once. The fanciful "remnant magnetization" recovery from older forensics literature does not apply to drives manufactured this decade. Density is too high, head positioning is too precise.

SSD blocks reclaimed by TRIM. Once the SSD controller has TRIM'd a block, the underlying flash is zeroed during garbage collection. The data is gone, fast. The window between deletion and TRIM completion on modern Windows is seconds at most.

Encrypted volumes without the key. BitLocker, VeraCrypt, or LUKS-encrypted NTFS volumes are unrecoverable without the key. The cleartext never touched the disk in the first place.

Files wiped by a competent wiper. sdelete -p 3 -z -s -q C:\target\* overwrites the file's clusters three times, zeroes free space, and recurses. Recovery is impossible for data clusters; the MFT record may still hold metadata and resident data, but the substantive file contents are gone.

Resident data: the case where physics is on your side

The resident-data case keeps surprising junior analysts. Files under the threshold sit inline in the MFT record. The record persists until the slot is reused. The data area is irrelevant; if $Bitmap has been overwritten a thousand times, the resident bytes are still there.

I once recovered a 400-byte .config file from a hard drive that had been used for two more weeks after the deletion and had been mostly overwritten. The MFT slot above record 230,000 had not been reused. The full file was sitting there, resident, in the record. Five minutes of work.

This is why I always try MFT-first recovery for small files before touching the data area.

Frequently asked questions

How long do deleted files stay recoverable on NTFS?

Until the MFT slot is reused and the data clusters are overwritten. On a busy system this is hours. On an idle system it can be months. There is no fixed timer; it is driven by the volume's allocation pressure.

Does emptying the Recycle Bin make recovery harder?

No. The recycle bin is a hidden directory ($Recycle.Bin) on each volume. Emptying it deletes the files in the normal NTFS sense; the same recovery techniques apply. Before emptying, the file is still a normal NTFS file under \$Recycle.Bin\<SID>\ with an $R<ID> name; the $I<ID> sibling records the original path.

Can I recover files deleted with `del /F` or `Shift+Delete`?

Yes. These skip the recycle bin but delete the same way (IN_USE cleared, clusters freed). The MFT record is still there until reused.

Can I recover files from a formatted NTFS drive?

Quick format only rewrites the boot sector and a fresh $MFT. Most of the old data clusters are intact and many of the previous MFT records (NTFS reuses the same starting offset) are recoverable via signature carving for FILE headers across the raw volume. Full format zeroes the volume; that data is gone.

What about a file that was renamed before deletion?

The MFT record after deletion shows the final name (the post-rename one). The USN journal preserves the RENAME_OLD_NAME / RENAME_NEW_NAME pair, so you can recover the original name from there.