File Recovery for Mac Drives (APFS and HFS+ from a Disk Image)

About the File Recovery for Mac Drives (APFS and HFS+ from a Disk Image)

First make a disk image of the drive: one file that holds every block of it, kept on another drive with room for it (the Data Recovery Assistant shows the steps on a Mac, on Windows and on Linux). Then open the image here. The page reads the drive’s APFS container or HFS+ (Mac OS Extended) volume the way Apple documents their structures, and lists the files that were deleted, with their names, folders, sizes and dates, and how likely each one is to be whole.

APFS never changes its records in place: when a file is deleted, the parts of its file-system tree that listed it are written anew elsewhere, and the old copies stay in the drive’s unused space until new data lands there. The page searches every block of the container for them, and also reads the volume’s snapshots and older checkpoints. HFS+ keeps older copies of its catalog in its journal, which the page reads too. Then each photo, video, PDF, ZIP archive and Office file found is checked by its own content and marked Opens fully, Partly damaged or Can’t be opened; kinds of file the page cannot check, such as plain text, are marked Not checked. Nothing is uploaded: the image is read on your device, a few megabytes at a time.

Common uses

• Getting back photos, videos and documents deleted from an external drive or USB stick formatted on a Mac, also after the Trash was emptied.
• Restoring files from an APFS drive with snapshots, under their names and folders.
• Copying files off an APFS or HFS+ drive that the Mac will not mount, from its image (tick “Also list files that were not deleted”).
• Checking which deleted files are still whole before deciding what to save.

Why you need an image first

A web page cannot read a drive block by block, and no browser setting changes that: the WebUSB standard does not let a page claim USB storage devices, and the File System Access API gives pages files and folders, never raw devices. A disk image (a file with every block of the drive, deleted areas included) is what recovery needs, and imaging is also the safe way to work: the drive is read once and never written to again.

On a Mac, find the drive with diskutil list (for example disk4), unmount it with diskutil unmountDisk /dev/disk4, and copy it with sudo dd if=/dev/rdisk4 of=/Volumes/Other/drive.img bs=4m in Terminal (press Ctrl+T to see the progress), saving the image on a different drive. Disk Utility’s “Image from” saves a DMG, which the Disk Image Converter turns into a raw image.

How deleted files are found on APFS and HFS+

APFS (Apple File System Reference) keeps each volume’s files in a tree of records: an inode for each file, with its name, its folder and its size, and file extents that say which blocks hold its data. Nodes of the tree are never changed in place: a change writes a new version of a node to an unused block and releases the old one, and every node carries a checksum. Deleting a file writes new nodes without its records, so the old nodes, with the records, stay in unused space until those blocks are reused. The page reads the tree as it is now, the trees of the volume’s snapshots and older checkpoints, and, with Search every block ticked, every block of the container for old nodes whose checksum is still right, and takes the newest version of each deleted file’s records.

HFS+ (Technical Note TN1150) keeps every file’s record in its catalog, a B-tree whose records hold the name, the folder, the size and the first eight extents of the data. Deleting a file removes its record and frees its blocks in the allocation bitmap. The journal writes whole copies of the catalog nodes each change touches, in a ring that is reused from its start once full, so it often still holds a copy from before the deletion; the page reads the whole ring, also the copies already written in place, and also catalog nodes no longer in use.

On both, the blocks a deleted file used are checked against what uses them now (files that exist, the file system’s own structures, files deleted after it), and macOS’s housekeeping files (Spotlight’s index, the event log) are counted apart.

What the conditions mean

• Opens fully: the file’s own structure checks out from its first byte to its last (a JPEG to its end marker, every PNG chunk checksum, a video’s index and data, every file inside a DOCX or ZIP).
• Partly damaged: it starts correctly, but part of it is missing or was written over; or some of its blocks now belong to other files.
• Can’t be opened: its first block now belongs to another file, or no record says where its data was. Its name is still listed.
• Not checked: a kind of file whose content the page cannot check (text files, for example). The note says whether another file uses its blocks now.

Measured on test images

NIST’s CFReDS deleted-file-recovery test images include two made with macOS, each with four HFS+ volumes (journaled or not, case-sensitive or not), with NIST’s record of the files deleted from them and the sectors they used (NIST tags each 512-byte block with its file and position). On osx-01 the page found 2 of the 4 deleted files, each whole: the two on journaled volumes; NIST’s own record says the other two have nothing left that says where they were. On osx-04, 48 files with names in Devanagari, Arabic, Hebrew, Cyrillic, Korean, Japanese, Chinese and German characters were deleted, 12 per volume: the page found the 24 on the journaled volumes, each whole under its name, and none on the others.

On test volumes made on a Mac, with files written, deleted and others written after: on APFS, with the search of every block, the 5 deleted files and the deleted folder, each file whole; on HFS+ (journaled), the 5 deleted files and the folder, 3 files whole and 2 marked as written over, which they were (macOS had put a new file and its own event log on their first blocks); and in an APFS container with two volumes, each volume’s deleted files, whole, under that volume. NIST’s osx-04 image and these test volumes are part of the page’s automated tests, with their checks, together with an encrypted APFS volume, which the page names as encrypted and does not read.

Mac, macOS, FileVault and Time Machine are trademarks of Apple Inc., registered in the U.S. and other countries and regions. MySmartCoPilot is not affiliated with Apple, and Apple has not sponsored or approved this page.

Limitations

• Works on disk images only, not on drives directly (browsers do not allow it). Raw images (.img, .dd, .bin, .raw, .cdr), raw images saved in parts (.001, .002 …) and fixed-size VHD files open directly; DMG images (also those made by Disk Utility) are turned into raw images first by the Disk Image Converter, and sparse bundles with hdiutil convert on the Mac.
• APFS and HFS+ only. Memory cards and USB sticks formatted with FAT or exFAT (also on a Mac) are undeleted by SD Card & USB Drive Recovery, Windows drives by NTFS Deleted File Recovery, Linux drives by File Recovery for Linux Drives; the deep scan finds photos, videos and documents on any drive by their content.
• The internal SSD of a Mac is almost never recoverable: macOS sends TRIM to it, which erases the blocks of deleted files, and on Macs with Apple silicon or a T2 chip its volumes are encrypted with keys kept in the Mac, so an image of it does not read. External drives and USB sticks are the drives this page is for; external SSDs can be trimmed too.
• Encrypted volumes (FileVault, or a drive encrypted when it was formatted) cannot be read without their password, and this page does not decrypt them. Unlock the drive on the Mac and copy the files you can see.
• Files that macOS compressed (it does so for some of its own files and apps) are listed but cannot be saved here. Symbolic links and hard links are listed by name. A Fusion Drive’s container is spread over two drives: an image of one of them holds only part of it.
• Data that has been written over cannot be recovered by any software. On HFS+, the journal holds the records of recently deleted files only: a busy volume reuses it within minutes or days. On APFS, the old copies of the records stay only until their blocks are reused.
• The search of every block reads the whole container: on a large drive it takes about as long as copying the whole drive.
• A drive with millions of files (a Time Machine backup disk, for example) needs plenty of spare memory, because the scan keeps the volume’s current records to tell the deleted files from the others: close other tabs first, or scan on a computer with more memory.
• A web page cannot set a file’s date: files saved to a folder carry the day they were saved. The ZIP keeps the original dates, shown in this computer’s time zone.

Privacy

The image is read by your browser on your device, a few megabytes at a time, in background workers; no part of it or of the files in it is sent anywhere.