In previous articles in this series, I have explained how Big Sur’s Time Machine to APFS (TMA) evolved, how automatic backups are initiated, and the general principles underlying the backup. This article looks in more detail at what happens when an automatic backup is made to a local APFS volume.

The start of an automatic backup is easily recognised in the log, when the sub-system com.apple.TimeMachine announces Starting automatic backup. Immediately after that, the mountpoint of the backup volume is reported as still being valid. If that isn’t the case, then you know that TMA can’t find the APFS volume on which the backups are stored.

TMA next looks on the backup volume for the name of the current Mac, for its “machine store”, and starts checking TMA snapshots on the volume which it’s about to back up (not the volume on which backups are stored), together with any others for which TMA has been making hourly snapshots. This typically deletes at least one old snapshot, aiming when possible to keep all hourly snapshots for the last 24 hours. This process is referred to as age based thinning, and should be completed in less than a second, as snapshots are very quick to delete, although the file system takes longer to free up space resulting from snapshot removals. It’s worth noting that TMA doesn’t handle snapshots directly, which are the responsibility of the kernel with its apfs extension.

Creating the backup begins in earnest with a local snapshot, which is termed the stable snapshot. This appears to be a whole-volume snapshot, which is then mounted at a path based on /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/[machine]/[datestamp]/[volume name]. The stable snapshot made in the last backup is located and mounted as the reference snapshot, at a similar path, but with a different datestamp, of course. TMA locates the “volume store”, into which the backed up files and other items will be copied. This should be at a path like /Volumes/[backup volname]/[datestamp].previous/.

In the next stage, TMA works out what needs to be backed up. One significant piece of information which is used in this is the role of the volume being backed up: this is different for a Data volume which is part of a boot Volume Group, and a general-use volume on an external disk, which normally doesn’t have an assigned role.

TMA states the possible strategies which it could use to work out what is to be backed up, in a log entry such as
Possible strategies for "Data" (device: /dev/disk3s5 mount: '/System/Volumes/Data' fsUUID: CF3EE91B-D9F8-430C-B5B3-13886470F1FC eventDBUUID: F131C8A4-5AAB-4369-A2D6-1030D5286F0A) (<EventMarker 2021-03-03 21:14:24 +0000 7162257447525032232 F131C8A4-5AAB-4369-A2D6-1030D5286F0A 261613>): first backup, deep scan, FSEvents, snapshot diffing,

Currently, with Big Sur only backing up Data and unroled general-purpose volumes, those are the four possibilities. The full list of what’s possible in Catalina includes:

• full first backups
• deep scans
• FSEvents
• snapshot diffing
• consistency scans
• cached events.

When this is the first backup, that strategy is the default; for subsequent automatic backups, the choice is normally FSEvents, in which TMA examines that database on the volume to determine everything that has changed since the last backup. Deep scans are normally only used when FSEvents is missing or damaged, and snapshot diffing seems to have fallen out of favour after it was used in High Sierra.

TMA announces its choice of strategy, then starts going about working out exactly what is to be backed up. For FSEvents, this consists of the process of event collection, at the end of which a summary is produced of the results, e.g.
2872 Total Items Changed
222 Intermediate Directories
21 Created Clones
4 Clone Sources
1514 Modified Files
78 Created Directories
21 Renamed Files
440 Created Files
572 Modified Directories
and a summary of where the changes have occurred, e.g.
Change Overview:
Root total: 2872
81% - 2348 - private/var
70% - 2025 - private/var/db
55% - 1590 - private/var/db/uuidtext
15% - 435 - Users/hoakley/Library

The cache of events is then saved to an .eventdb file in the backup marked as .inprogress, and TMA starts sizing the backup. Those results are announced as
Changed content estimate: (bytes: 436379648 (436.4 MB), items: 3217)
Estimated 3217 files (436.4 MB) need to be backed up from 'Data'
Estimated 3217 files (436.4 MB) need to be backed up from all sources

Having worked out what needs to be backed up, and how much space it will take, TMA finally gets on with it, stating clearly its source (the stable snapshot on the volume to be backed up) and its destination (the .inprogress folder on the volume storing backups). This might read something like
Copying source: /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/[machine]/[datestamp]/Data to destination: /Volumes/[backup volname]/[datestamp].inprogress name: Data

During longer backups, TMA reports progress every few minutes, which you can check in T2M2. The final outcome is announced in a summary, such as
Finished copying from volume "Data"
3183 Total Items Added (l: 413.4 MB p: 432.7 MB)
3748 Total Items Propagated (shallow) (l: Zero KB p: Zero KB)
956829 Total Items Propagated (recursive) (l: 141.92 GB p: 124.54 GB)
960012 Total Items in Backup (l: 142.33 GB p: 124.97 GB)
1920 Files Copied (l: 106.7 MB p: 117.9 MB)
22 Files Delta Copied (l: 304.6 MB p: 312.6 MB)
15 Files Cloned (l: 2.2 MB p: 2.2 MB)
367 Symlinks Copied (l: 8 KB p: Zero KB)
1150 Directories Move Skipped (l: Zero KB p: Zero KB) | 954231 items propagated (l: 140.46 GB p: 123 GB)
859 Directories Copied (l: Zero KB p: Zero KB)
2598 Files Move Skipped (l: Zero KB p: Zero KB) | 2598 items propagated (l: 1.46 GB p: 1.54 GB)

Detailed interpretation of these figures is open to speculation. Delta copying probably refers to files where only changed blocks of data have been backed up. Move skipping probably refers to directories which haven’t changed their contents but have been moved within the file system. It is clear, though, that TMA goes out of its way to minimise the amount of data which has to be copied to create the new backup, thus being as economical as possible with its use of storage on the backup volume.

TMA then appears to perform a comparison to check the backup it has just made against the difference between the two snapshots, the reference and stable snapshots. It next unmounts those two, and marks the older of them as just another snapshot, while the newer becomes the reference snapshot for the next backup.

With the backup complete, the overall result is declared, such as
BackupStrategy = 2;
BlocksToCopy = 106538;
BytesToCopy = 436379648;
FreeBytes = 537522769920;
PaddedBytesRequired = 1253269733;
Percent = "0.2723816854080234";
TimeRemaining = 44;
"_raw_Percent" = "0.2723816854080234";
"_raw_totalBytes" = 436379648;
bytes = 118861824;
"com.apple.backupd.SnapshotTotalBytesCopied" = 118861824;
files = 3146;
totalBytes = 436379648;
totalFiles = 3217;
much of which is self-explanatory.

The final phase completes remaining housekeeping. The “incomplete” backup is deleted from the .previous folder, the backed-up files and metadata are turned into the new snapshot on the backup volume, and it summarises the state of that volume, e.g.
29 backups: 2020-12-22-192223 to 2021-01-09-182516 (1hr,5wk,13m,10yr) MΔ: 2.99 GB
It finally declares the backup completed, checks its mountpoint again, and deletes old backups on that volume. Those are normally removed on the basis of their age in age-based thinning, but could also be subject to space-based thinning if the backup volume is getting low on free space. TMA’s backup activity is then complete until it’s next initiated by the DAS-CTS dispatching system.