Scheduling and dispatch of backups and other background activities

Time Machine backups are but one of hundreds of activities that run in the background on our Macs. When they’re automatic, those backups don’t occur at precisely regular intervals, because macOS dispatches them using a scheme that takes factors such as load from other activities into account. Most, perhaps all, other backups are run by the clock: set a Carbon Copy Cloner backup to occur at 0415, and that’s the time it will run its backup. That’s fine when you know that your Mac will be free to devote a few minutes to copying files, but when backups could occur while you’re trying to get on with your work, it’s hardly convenient. This article explains how TM’s backups are scheduled and dispatched to be run in the background, when they’re least likely to disrupt, using the DAS-CTS system that’s used for all background activities in macOS.

DAS-CTS

Initially, macOS used the popular Unix cron service to run scheduled activities, but in Mac OS X 10.4 Tiger (2005) this was replaced by launchd. In conjunction with launchctl, that’s still responsible for running most third-party background activities, including backups. When TM was released in Mac OS X 10.5, it was launchd that ran its backups, every hour on the dot. Apple didn’t introduce Duet Activity Scheduler (DAS) and Centralized Task Scheduling (CTS) until OS X 10.10 Yosemite, since when TM’s automatic backups have relied on DAS-CTS.

This doesn’t apply to manual backups made using TM’s Back Up Now command, nor to third-party utilities that control the frequency of TM backups, only to TM’s own automated backups.

DAS-CTS is at heart relatively straightforward: DAS maintains a list of all background activities in macOS that it has to schedule. Every few seconds, it checks through that list and calculates a score for those that are due to be run soon. That score takes into account factors such as other activities, internal temperature, and the priority assigned to each activity. When an activity’s score exceeds a threshold, DAS runs the activity by calling on CTS to start it using lightweight inter-process communication, XPC. You can trace that in log entries using MintsDAS Scheduling button set to a minute or so before the last TM backup started, and for a period of a couple of minutes.

Log entries

You’ll first see DAS (DuetAS) rescoring its activities:
41.461 DuetAS Rescoring all 400 activities [<private>]

For each activity due according to the clock, there’ll be an entry like
41.462 DuetAS 501:com.apple.mediaanalysisd.photos.ocr:F5BE15:[
{name: Device Activity Policy, policyWeight: 20.000, response: {Decision: Must Not Proceed, Score: 0.00, Rationale: [{deviceActivity == 1}]}}
], FinalDecision: Must Not Proceed}

In that case, the score is far below the threshold, and DAS decides not to dispatch it.

tmdascts1

For a TM backup, you should instead see entries like
41.469 DuetAS 0:com.apple.backupd-auto:A5EFFA:[
{name: Device Activity Policy, policyWeight: 2.000, response: {Decision: Can Proceed, Score: 0.69}}
] sumScores:31.909324, denominator:32.530000, FinalDecision: Can Proceed FinalScore: 0.980920}
41.469 DuetAS '0:com.apple.backupd-auto:A5EFFA' CurrentScore: 0.980920, ThresholdScore: 0.092809 DecisionToRun:1

where the threshold is reached, and DAS dispatches that activity with a log entry like
41.471 DuetAS REQUESTING START: 0:com.apple.backupd-auto:A5EFFA

That’s followed by an entry from CTS reporting that the TM XPC activity is being started
41.564 CTS-XPC Initiating XPC Activity: com.apple.backupd-auto (0x7f94d9b1b0e0)
which is echoed by DAS
41.565 DuetAS STARTING activity 0:com.apple.backupd-auto:A5EFFA <private>!

tmdascts2

What happens next may appear surprising: just a millisecond later, DAS reports that backupd-auto has completed, and is no longer running
41.566 DuetAS COMPLETED 0:com.apple.backupd-auto:A5EFFA at priority 30 <private>!
41.566 DuetAS NO LONGER RUNNING 0:com.apple.backupd-auto:A5EFFA ...Tasks running in group [com.apple.dasd.default] are 3!

Then, before the backup itself has even got under way, CTS asks DAS to schedule its next backup, by adding it to its list
41.568 CTS-XPC Rescheduling XPC Activity: com.apple.backupd-auto (0x7f94d9b1b0e0)
41.568 DuetAS SUBMITTING: 0:com.apple.backupd-auto:AE409F

Note how the next run of backupd-auto is given a new label of AE409F, instead of the previous A5EFFA.

To understand what’s going on here you need to look at TM’s log entries, where you’ll see that backupd-auto does no more than kickstart TM to make the backup, and that the heavy lifting is then performed by other processes including backupd-helper and backupd itself.

E cores and throttled I/O

There are two further consequences of TM being run in the background. DAS takes into account the Quality of Service (QoS) set for TM, which marks it as a background process. When macOS comes to allocate its threads to the CPU cores in an Apple silicon Mac, that ensures that they are designated to be run on the efficiency (E) cores there, although some threads may be run on any available P cores if their QoS merits that. Effects on Intel Macs aren’t so apparent, though.

Background processes also have their rates of transfer to storage limited, to ensure other processes can be given priority. This is set in the IOPOL_THROTTLE policy, and can have significant effect on backup speed. For example, TM’s copying phase might achieve 332 MB/s to local storage with the policy disabled, but when IOPOL_THROTTLE is applied, that’s likely to fall to less than 200 MB/s. In the past, that hasn’t been applied when backing up to network storage, but it’s unclear whether that still holds good.

Although DAS-CTS was notoriously unreliable in macOS Sierra, since High Sierra it seems to have been thoroughly reliable. Warning signs are log messages referring to DAS evaluating activities based on triggers, rather than its normal scoring system. backupd-auto may completely vanish from DAS listings, and backups are dispatched and started irregularly and infrequently. When that happens, the best solution is to restart the Mac, forcing DAS to rebuild its list of activities and start from scratch.

Summary

  • When backing up automatically, Time Machine backups are scheduled and dispatched by DAS-CTS.
  • Check this using the DAS Scheduling log extract in Mints.
  • On Apple silicon Macs, automatic TM backups are run on the E cores.
  • TM backups also have throttled transfers to storage.
  • If DAS-CTS stops scheduling TM backups properly, restart the Mac.