Time Machine has undergone major changes over the last few years, both to make efficient backups from APFS, and to support backups stored on APFS volumes. It has been a couple of years since I last examined how Time Machine makes backups to APFS: this article steps through what happens when Ventura 13.2.1 makes an automatic hourly backup of an APFS volume to APFS backup storage, Time Machine to APFS, or TMA.
Scheduling
Automatic TMA backups aren't run at fixed times, but are scheduled and dispatched by the DAS-CTS subsystems so that backups are only made when conditions are suitable. One simple rule applied is that the first backup made after a Mac starts up is delayed for five minutes, to allow other processes such as Spotlight indexing checks to be run first. DAS-CTS is explained in fuller detail in this article, using TMA as an example.
Should regular automatic backups fail, the first task in discovering where the problem lies is to check DAS-CTS scheduling. Although normally very reliable, failure of those subsystems will prevent backups from taking place.
Setting up the backup
Once backupd has been told to make a backup, it announces
Starting automatic backup
in the log and starts checking the resources it needs to do that. First is the mount point of the backup storage, referred to as the target volume. If that's not available, then TMA will normally still make and maintain local snapshots of the volumes to be backed up. It's at this stage that the next of multiple target volumes is identified when backups are being rotated between different destinations.
In more recent versions of macOS, file write performance to the target volume is then measured by writing a single 50 MB test file, and concurrently writing 500 files of 4 KB size to the volume. These tests are also performed when backing up to network storage, when they may fail altogether, but TMA appears to proceed regardless of the results. However, those are written to the log, where they are a useful reference in the event of performance problems.
The next issue for TMA to tackle is whether the backup to be used is inherited using machine store inheritance; normally that shouldn't be needed, allowing TMA to proceed to snapshot maintenance.
Snapshots
Before making any snapshots for this backup, TMA performs housekeeping on its own previous snapshots, both on each volume being backed up, and on the target volume (backup storage). The rule it applies is inflexible: it deletes any local snapshots (on a volume being backed up) that are more than 24 hours old, unless it's the last snapshot on that volume, which it retains for this backup. Even so, TMA snapshots can become orphaned and left indefinitely, for the user to spot and delete manually. Although uncommon, this can occur when Macs are unable to make full backups because they're disconnected from their backup storage for more than 24 hours at a time.
Maintenance of snapshots on backup storage is more complicated and currently opaque.
With expired snapshots deleted, TMA then makes a fresh snapshot on every volume that it's going to back up, that's stored locally to that volume, and declared as the stable snapshot for the purpose of this backup. Because APFS can only make whole-volume snapshots, this means that if TMA is only going to back up a single folder on a volume, a snapshot is still made of the whole of that volume, which includes all the files and folders normally excluded from backups, and those excluded by the user in Time Machine's settings.
TMA then mounts the stable snapshots just made, and the last snapshots, termed reference snapshots, ready to start the backup process. These are mounted in the path /Volumes/com.apple.TimeMachine.localsnapshots/Backups.backupdb/[computer name]/[date time]/[volume name]
Determining what to back up
TMA next has the task of deciding how it's going to work out what needs to be backed up on each source volume. Choices may now include:
- collecting events using the FSEvents database stored on that volume, recording all file system events;
- full file list, used when this is the first backup made of that volume;
- a deep scan of all items modified since the last backup, when no usable FSEvents database can be found;
- calculating a snapshot delta, the differences between the stable and reference snapshots.
Snapshot deltas were first choice in the past, but TMA has returned to preferring FSEvents when possible, for second and subsequent backups of a volume.
Once its strategy has been determined, TMA uses that method to arrive at and declare what this backup will contain, and writes a detailed summary into the log. This also contains summary figures for the folders containing most of the changes to be backed up. If you're ever unsure of where much of your Mac's backups are originating, these are useful figures.
Backing up
TMA examines existing data in the backup to be 'propagated', so sparing unnecessary copying of duplicate data, and arrives at an estimate of how long copying is likely to take. While that's going on, Spotlight performs indexing. In previous versions of TMA, the log contained a clear statement of the free space remaining on the target volume (backup storage), and the decision that was sufficient to contain the backup before any copying started. That no longer appears in the log, although that check is still made.
During copying, periodic reports are made in the log providing details of progress. During long backups, these reports provide invaluable information as to what is taking the time. Once copying has completed for each volume being backed up, this is declared and summary figures given for creation of that backup. This breaks down the numbers and sizes of items added, how many were actually copied, cloned, etc.
Final checks and maintenance
Once backing up has completed, the backup and local snapshots are unmounted. The last of those local snapshots is then marked as the reference snapshot for the next backup, and TMA writes an overall result to the log. This does record free space left on backup storage, together with other useful summary figures for that backup.
Temporary space used on backup storage is then freed. This is referred to as an incomplete backup in the log, so may appear confusing. After that, TMA declares that backup as an APFS snapshot (on backup storage, not a local snapshot), and writes a summary of what it holds on backup storage, for example
59 backups: 2022-03-30-170453 to 2022-04-15-115414 (1hr,4d,1wk,14m,39yr) MΔ: 984.1 MB
giving the number of backups, their date range, intervals between them, and the average size of each over that period.
Finally, the backup is declared complete, and backupd's XPC communications cease until the next backup is started.
Variants
The TMA backup described above is typical for an hourly automatic backup dispatched by DAS-CTS. Backups run by other means, including manual backups and those scheduled as launchd tasks, differ in various respects, and those performed to network storage also differ in their details. The summary diagram below integrates each of the stages shown above.
While my free T2M2 app gives basic information to enable you to monitor and check backups, and supports a wide range of versions of macOS and HFS+ backups, you can get full details using the Time Machine log window feature in my free Mints.
