The process used by Time Machine to make automatic backups to local APFS storage is broadly similar to that introduced in Big Sur, although some details have changed, and its log entries are now very different from earlier versions of macOS backing up to HFS+. Unfortunately, that means The Time Machine Mechanic, my utility T2M2, is of limited value in assessing these more recent versions of Time Machine.

In Sonoma, Time Machine settings give you the choice of making manual or automatic backups, the latter now repeated every hour, day or week. Those are set in the Options… button, together with any items you wish to be excluded from backups. To keep this explanation simple, I’ll consider only automatic backups being made every hour, Time Machine’s original and most common setting.

Scheduling and dispatch

Automatic backups are scheduled and dispatched by the DAS-CTS system, responsible for managing those for all background processes in macOS. Duet Activity Scheduler (DAS) maintains a list of several hundred background tasks, one of which is backupd-auto, the initial trigger for automatic Time Machine backups. Periodically, DAS evaluates items in that list, and when it assesses that backupd-auto has passed its threshold, DAS calls for Centralized Task Scheduling (CTS) to run that process.

backupd-auto in turn kicks off backupd-helper to start the backup. This is so that backupd-auto completes its task quickly and can be rescheduled to run another backup in an hour, even though the backup itself may take many minutes or longer. DAS-CTS is explained in fuller detail in this article.

Checks and admin

Before the backup can proceed, several checks have to be made to ensure that it will work correctly. As Time Machine supports making backups to multiple backup stores in rotation, the first of these determines whether this should rotate the backup store. The backup is then declared to have started, giving its mode explicitly as “automatic backup”.

The backup store is then checked, to see if it’s at its expected mountpoint or is missing, and the machine store on the backup is located and checked to ensure that no migration is required. By far the most interesting of these checks, though, is measurement of transfer performance to the backup store. Two tests are run:

• copying one 50 MB file, which on a decent NVMe SSD should proceed at around 200 MB/s. This is far lower than normal copying performance because Time Machine’s copying is performed with I/O throttled at background level, a system-wide policy applied by macOS.
• concurrent copying of 500 files of 4 KB, which should achieve around 15 MB/s on a fast SSD. Backing up folders and bundles of many small files remains one of Time Machine’s weaknesses, as anyone who has backed up Xcode knows only too well.

Although those results are recorded in the log, I haven’t seen Time Machine raise any objection to poor performance. In one case, where the small file test resulted in an error, it was ignored and the backup proceeded.

A new entry in the log for Sonoma is mention that inline Spotlight indexing isn’t enabled, suggesting that could be available in the future.

Snapshots and housekeeping

Local snapshots, those made on each volume to be backed up, go through age-based thinning, which has APFS delete any that are more than 24 hours old. Time Machine then makes a fresh local snapshot of each volume to be backed up, and declares that to be the stable snapshot. That is mounted, as is the most recent local snapshot made prior to this backup, designated the reference snapshot. The final step in housekeeping is to ready the volume store to receive the backup that’s about to be made.

Determining the backup

With all the components ready to make the backup, Time Machine then has to work out what needs to be copied to the backup store. The method used depends on whether this is an initial full backup, and whether the volume’s file system events (FSEvents) database is available.

First full backups should copy everything apart from items excluded by Time Machine, and those set by the user to be excluded. Subsequent backups should normally build Time Machine’s EventDatabase using the data in FSEvents. If those aren’t available, or can’t be relied upon, then a deep traversal scan can be used to build the EventDatabase from datestamps in the file system, or a snapshot delta can be calculated using the stable and reference snapshots (a method originally the default in High Sierra).

The projected statistics for the backup are declared, including estimates of the total number and size of files to be included in the backup, and the expected total time copying will take. Those are recorded in the log.

Backing up

In most cases, this is the longest phase of the backup, during which all the files and data are copied from their source volumes into the volume store on the backup store. Time Machine therefore writes periodic summaries of progress made during this phase, where it records the rate of copying of items and their transfer rate. During large backups, you’ll see those figures vary widely, from relatively rapid data transfer for large files, to interminably slow when copying large numbers of small files.

Finalisation

Once all copying has been completed, Time Machine records a final summary, and finalises the completed backup in the backup store.

Snapshots and housekeeping

With the backup complete, there’s a second phase of snapshot and related maintenance. First, the latest snapshot, which had been declared as the stable snapshot for this backup, is marked as the reference snapshot for the next backup. Those, and the backup snapshot on the backup store, are then unmounted.

The working folder on the backup store used to construct the previous backup is then deleted, as it’s declared somewhat confusingly as being ‘incomplete’. Finally, there’s a period spent performing age-based thinning of old backups on the backup store. It’s here that Time Machine records the total number of backups in the store.

Final tidying up

Its tasks complete, Time Machine announces in the log that the backup succeeded, then backupd-helper is released. That and the main backupd process itself are left running in the background, ready to be woken up for the next backup in less than an hour.

Snapshot and backup retention

Local snapshots, made to each volume being backed up, are retained for 24 hours, then automatically deleted during the first snapshot thinning phase of the next backup. There appears to be no way to retain them any longer than that, although this does work differently when backups can’t be made (usually because the backup store isn’t connected) and there are longer periods for which only local snapshots can be made.

Backups, in the form of synthetic snapshots on the backup store, are deleted according to two different policies, by age or by space. Age-based thinning applies as long as there remains sufficient free space in the backup store. The policy is to keep hourly backups for the previous 24 hours, then daily backups over the last month, and weekly back to the start of that backup series. Space-based thinning should only occur when free space is getting low, and will delete other backups in an effort to ensure that new backups can still be stored.

The main events that occur during a normal automatic Time Machine backup to APFS in macOS Sonoma 14.0 and 14.1 are summarised in the following diagram.

A tear-out PDF version is available here: tmbackup14b