APFS Deleted File Recovery: Checkpoints, OMAP History, and Extents

APFS deleted file recovery is not only a raw byte search. A higher-confidence recovery workflow starts with APFS metadata: the current file tree, older checkpoints, snapshots, object map history, and the file extents that point to data blocks.

This article explains the recovery model used by Ed Recovery for regular, unencrypted APFS volumes. It is written as a practical engineering overview, with simple diagrams and source links for readers who want to go deeper.

Related language version: 中文：APFS 删除文件还原.

Short Answer

When an APFS file is deleted, the current directory view no longer lists it. However, older APFS metadata may still describe the file. If that metadata still contains the file record and the old data blocks have not been overwritten, the file can often be exported by reading its extents.

Why APFS Has Recoverable History

APFS is a copy-on-write filesystem. Instead of modifying every structure in place, APFS records newer filesystem states through transaction-based metadata. Older metadata can remain on disk until the space is reused.

Apple's archived Apple File System Guide describes APFS features such as snapshots, clones, space sharing, and copy-on-write behavior. Apple's Foundation documentation also gives a high-level overview in About Apple File System.

For recovery, the important idea is:

• The current APFS tree shows what exists now.
• Historical APFS metadata may show what existed earlier.
• A deleted candidate is a historical file that no longer matches the current tree.

What the Scanner Looks For

A useful APFS deleted-file candidate needs more than a filename. The scanner tries to recover both identity metadata and data-location metadata.

Identity metadata includes:

• File name.
• Parent directory.
• Logical file size.
• File mode and type.
• Inode and directory-record evidence.

Data-location metadata includes:

• File extent list.
• Logical offset for each extent.
• Physical block address.
• Extent length.

Scan Stage

1. Identify the APFS Container and Volume

The recovery tool opens the source device or image read-only. It then identifies the APFS container and the volumes inside it. The user selects the volume to scan.

2. Build the Current Baseline

The current file tree is parsed first. This produces a baseline of files that still exist. The baseline helps avoid reporting normal current files as deleted files.

3. Revisit Historical Metadata

After the baseline is built, the scanner walks older metadata sources:

• APFS checkpoint descriptor history.
• APFS snapshots.
• OMAP root history.
• Recent OMAP transaction history.
• Optional orphan metadata scanning when normal metadata is incomplete.

4. Compare Old Records with the Current Baseline

A historical file record becomes a deleted candidate only when it passes practical filters:

• It has at least one readable extent.
• It satisfies the minimum size filter.
• It is not filtered as system-path noise.
• It does not match the current baseline.
• It is not a duplicate of a previously emitted candidate.

Recovery Stage

Recovery uses the candidate's historical transaction id and object id to reopen the matching historical view. It then finds the file record again and exports file data by walking the extent list.

How Extents Rebuild a File

An extent maps a part of the file's logical byte range to physical APFS blocks. A small file may have one extent. A large or fragmented file may have many.

If APFS marks a file range as sparse, the exporter writes zero bytes for that range so the recovered file keeps the correct logical layout.

Why APFS Recovery Can Fail

APFS recovery depends on two things surviving deletion:

• Historical metadata.
• The physical data blocks referenced by that metadata.

If the old metadata is gone, the scanner may not know the filename, path, or extent layout. If the data blocks have been overwritten, the file content cannot be reconstructed from APFS metadata alone.

Practical Recommendations

1. Stop writing to the source disk as soon as possible.
2. Prefer scanning a disk image instead of a live disk.
3. Recover to a different physical disk.
4. Start with historical metadata scanning.
5. Use deeper metadata or signature scans only when the first scan does not find the target.
6. Preview important media before bulk recovery.

Sources and Further Reading

• Apple: Apple File System Guide.
• Apple Developer Documentation: About Apple File System.

FAQ

Can APFS always recover deleted files?

No. Recovery depends on whether old metadata and old data blocks still exist.

Is APFS recovery the same as raw file carving?

No. Metadata-based APFS recovery tries to use historical file records and extents. Raw carving searches for file signatures and may lose filenames or fragmented layout.

Why should recovered files be written to another disk?

Writing to the source disk may overwrite the very blocks needed for recovery.