Watch your background: automatic Time Machine backups

Automatic Time Machine backups are the classic example of background scheduling and dispatch by Duet Activity Scheduler and Centralised Task Scheduling, the DAS-CTS system, and the stimulus for my personal interest, when they went awry in macOS Sierra. Before looking at how these are handled, I’ll start by showing how DAS sets up its budgets and its lists of scheduled activities. Following that I’ll describe how scheduling and dispatching automatic Time Machine backups have changed in macOS Sequoia.

Preparations

Shortly after user login, DAS starts gathering its budgets enabling it to score activities. These include thermal policies, shared memory and energy, for example
Allocating 188 budget on start for com.apple.dasd.systemEnergy
Each is given in notional units that can’t be correlated with anything external to DAS.

Following those, DAS loads saved activities by group. It’s not clear where those are stored, though, and presumably they were in the lists of activities for that user when they last logged out. A background system task helper is created, with a scheduler, listener and publisher, before DAS solicits activities for resubmission. Among the first of those is an activity run as root to clean up software update logs:
DAS Submitted: 0:com.apple.softwareupdated.logs-cleanup:27B9B4 at priority 5 with interval 604800 (Wed Feb 12 20:28:32 2025 – Thu Feb 13 20:28:32 2025)
DAS <private>: Optimal Score 0.5687 at <private> (Valid Until: <private>)

There are also some backup activities, including that to initiate automatic backups:
DAS Submitted: 0:com.apple.backupd-auto:9015F3 at priority 30 with interval 1800 (Wed Feb 12 08:05:28 2025 – Wed Feb 12 08:25:28 2025)
DAS <private>: Optimal Score 0.8535 at <private> (Valid Until: <private>)
DAS 0:com.apple.backupd-auto:9015F3:[
{name: Boot Time Policy, policyWeight: 0.010, response: {33, 0.00, [{[Minimum seconds after boot]: Required:300.00, Observed:22.19},]}}
], Decision: MNP}
As with many other activities, that can’t be considered for running until at least 5 minutes after boot.

Dispatch

Eventually, DAS decides to run backupd-auto to initiate the automatic backup:
DAS Rescoring all 535 activities [<private>]
DAS 0:com.apple.backupd-auto:3F876A:[ ], Decision: CP Score: 0.994671}
DAS ‘0:com.apple.backupd-auto:3F876A’ CurrentScore: 0.994671, ThresholdScore: 0.095313 DecisionToRun:1
DAS REQUESTING START: 0:com.apple.backupd-auto:3F876A

That’s the cue for CTS to initiate the activity and run it. DAS then records
DAS STARTING <_DASActivity: “0:com.apple.backupd-auto:3F876A”, Utility, 60s, [27/01/2025, 11:08:52 – 27/01/2025, 11:28:52], Started at 27/01/2025, 11:28:30, Group: com.apple.dasd.default, PID: 568>!
DAS 0:com.apple.backupd-auto:3F876A:[ ], Decision: CP Score: 0.994671}

backupd-auto only runs for a fraction of a second before it completes, and its next run is rescheduled in 30 minutes, not an hour:
CTS Completed: com.apple.backupd-auto (0x61e077ac0)
CTS Rescheduling: com.apple.backupd-auto (0x61e077ac0)
DAS SUBMITTING: 0:com.apple.backupd-auto:59E600
CTS _xpc_activity_set_state_from_cts: com.apple.backupd-auto (0x7ae068320), set activity state to 1
CTS _xpc_activity_end_running: com.apple.backupd-auto (0x7ae068320) seqno: 0.
DAS COMPLETED <_DASActivity: “0:com.apple.backupd-auto:3F876A”, Utility, 60s, [27/01/2025, 11:08:52 – 27/01/2025, 11:28:52], Started at 27/01/2025, 11:28:30, Group: com.apple.dasd.default, PID: 568>
DAS NO LONGER RUNNING 0:com.apple.backupd-auto:3F876A …Tasks running in group [com.apple.dasd.default] are 2!
DAS Submitted: 0:com.apple.backupd-auto:59E600 at priority 30 with interval 1800 (Mon Jan 27 11:43:29 2025 – Mon Jan 27 11:58:53 2025)

The two activities are distinguished by their appended hex IDs: the original and now-completed backupd-auto was 3F876A, and the new one is 59E600. This ensures that the next backup will be run in about 30 minutes, without losing the time taken to perform the backup. Instead, the backup is performed by the backupd process run by backupd-auto.

While Time Machine is estimating the time required to perform the backup, DAS dispatches an analytics activity, and another named com.apple.backupd-auto.dryspell.

Re-scheduling

Once the backup has been completed, Time Machine will normally re-schedule the next backup for an hour later. When it does, it announces in the log
Re-scheduled next backup in 60 minutes (plus or minus 30 minutes)
before submitting another activity with a new ID for backupd-auto. Immediately after that, it cancels the previously scheduled backupd-auto activity for 59E600, so the interval to the next automatic backup is about an hour following completion of the previous one.

New in Sequoia is this twice re-scheduling of the next automatic backup, first for 30 minutes later, then for the full hour. Previously, the first re-scheduling was for 60 minutes and there was no change made when the backup had completed. Presumably this is considered to be more reliable than in Sonoma and earlier.

Summary

This is summarised in the following chart.

Previous articles

Background activities with DAS-CTS
Scheduling XProtect Remediator scans
In-app background tasks