When Time Machine backs up to HFS+ (TMH), it both uses the features of that file system to its advantage with directory hard links, and suffers from its limitations. The latter include lack of support for sparse files, and limiting copying to whole files rather than changed storage blocks. The result is that APFS sparse files have to be expanded to their full size, and APFS clones have to be expanded into whole files too, making HFS+ inefficient as a file system for hosting backups of APFS volumes. This article explores whether Time Machine backing up to APFS (TMA) is more efficient, as most of us suspect.

To test this, I created three files on an APFS volume being backed up to an APFS volume, under macOS 11.2.3. Two were sparse files, whose expanded size was 5 GB each, and the third was a duplicate of one of those. According to the Finder, each of those three files was 5 GB in size, but each actually occupied just a few KB on disk. Test files were created using Sparsity, and their status checked using Precize.

Following the next Time Machine backup to an APFS volume, the three test files were located in Time Machine and restored from there. Both the backups and the restored files appeared identical, with the same sparse file and shared data flags as the original files. I then examined log extracts for the Time Machine backup which made backup copies of the three test files.

Of the strategies available, Time Machine chose FSEvents to determine what needed to be backed up, as it normally does for Data volumes. Using that, TMA decided that 607 items totalling 110.1 MB had changed, not 10 or 15 GB. That process took approximately 0.8 seconds, and occurred before any comparison had been made between reference and stable snapshots, although both were mounted at the time.

Copying the files to the backup took just over 0.8 seconds, at the end of which Time Machine gave the following information about that backup:
48.480 Finished copying from volume "Data"
563 Total Items Added (l: 15.09 GB p: 98.7 MB)
2810 Total Items Propagated (shallow) (l: Zero KB p: Zero KB)
1020960 Total Items Propagated (recursive) (l: 150.27 GB p: 132.98 GB)
1021523 Total Items in Backup (l: 165.36 GB p: 133.08 GB)
156 Files Copied (l: 10.04 GB p: 48.2 MB)
6 Files Delta Copied (l: 47.9 MB p: 49.2 MB)
16 Files Cloned (l: 5 GB p: 1.4 MB)
162 Symlinks Copied (l: 4 KB p: Zero KB)
1194 Directories Move Skipped (l: Zero KB p: Zero KB) | 1019344 items propagated (l: 135.45 GB p: 118.11 GB)
1616 Files Move Skipped (l: Zero KB p: Zero KB) | 1616 items propagated (l: 14.81 GB p: 14.87 GB)
223 Directories Copied (l: Zero KB p: Zero KB)
48.480 Reference Snapshot comparisons: Mtch:2922
48.480 Baseline comparisons: Mtch:2922,MdDte:158

Of particular interest here are two lines. The total sizes given for Files Copied gives both the total expanded sizes of the two ‘original’ sparse files (l: 10.04 GB), and a much smaller size as p: 48.2 MB. The total sizes given for Files Cloned gives the expanded size of the clone-copy (l: 5 GB) and a much smaller size of p: 1.4 MB. The previous backup, which didn’t contain the test files, had l and p values for those two items near-equal.

It’s therefore likely that the Files Copied item includes all files which are copied to the backup, excluding clones, with its l value reflecting the total expanded size, and the p value the size actually copied and space taken on the backup volume. Similarly for the Files Cloned item, for APFS clone files.

The overall result of that backup was given as:
49.969 TimeMach Backup result: {
BackupStrategy = 2;
BlocksToCopy = 26889;
BytesToCopy = 110137344;
FreeBytes = 509477478400;
PaddedBytesRequired = 1160020196;
Percent = "0.5661050987392614";
TimeRemaining = 7;
"_raw_Percent" = "0.5661050987392614";
"_raw_totalBytes" = 110137344;
bytes = 62349312;
"com.apple.backupd.SnapshotTotalBytesCopied" = 62349312;
files = 541;
totalBytes = 110137344;
totalFiles = 607;
}

Figures in that set of results refer to the actual sizes copied, with sparse files in sparse format, and clones only requiring the space of changed storage blocks.

This confirms that TMA is as efficient as possible in both the copying and storage of APFS sparse files and clones. This is far superior to TMH, which would of course have had to copy across almost 15 GB extra data, and required a total of 15 GB space in the backups for these three files. With sparse files and clones being relatively common in APFS volumes, the efficiency of TMA can make a big difference to the time taken to make backups, and use of storage space on the backup volume.

If you’re using Time Machine in Big Sur and are still backing up to HFS+, you might wish to reconsider that decision.