When you’re trying to sort out a problem, the Unified Log can be a real pain, with its endless chatter and repeated entries. But for exploration it can be a fascinating mine of tantalising glimpses into what your Mac is up to. When looking through Time Machine backup entries this week, I stumbled across what appeared at first to be a linked sub-system, SecureBackupDaemon (SBD). In fact, it’s something quite unassociated with Time Machine, and it was just by chance that on this occasion it ran at the start of an automatic backup, and its log entries were picked up by Mints.

SBD is quite reclusive too: you’ll find its LaunchAgent in /System/Library/LaunchAgents/com.apple.SecureBackupDaemon.plist, which in turn refers to the Universal Mach-O binary at /System/Library/PrivateFrameworks/CloudServices.framework/Helpers/com.apple.sbd. That isn’t an ‘.sbd’ file, but the binary containing the sbd daemon.

For once, Apple documents Secure Backup in its Platform Security Guide. It covers the databases containing personal information which are kept in and synced using iCloud: Contacts, Calendars, Photos, Messages, and most importantly the Keychain. A fuller listing comes from the log, where it includes:

• AccessoryPairing
• AppleTV
• BackupBag
• ContinuityUnlock
• CreditCards
• HomeKit
• NanoRegistry
• OtherSyncable
• PCS-Backup
• PCS-CloudKit
• PCS-Escrow
• PCS-FDE
• PCS-Feldspar (Find My, perhaps?)
• PCS-Maildrop
• PCS-MasterKey
• Notes
• Photos
• Sharing
• iCloudDrive
• iMessage (Messages)
• Passwords
• WatchMigration
• WiFi
• iCloudIdentity

Apple states that Secure Backup is run once daily, which could be shortly after you start your Mac up, as was the case when I happened to catch it at work. In that case, it’s one of the iCloud sync tasks responsible for the slowly-filling progress circle displayed next to your iCloud Drive in the sidebar of Finder windows. Unlike Time Machine backups, which can’t be started until five minutes after starting your Mac up, Secure Backup can start earlier, and doesn’t appear to be scheduled or dispatched by the DAS and CTS-XPC system. Macs which are left running overnight should then perform at least one Secure Backup each day.

For iOS and iPadOS devices, Secure Backup is only performed when a device is locked, connected to a power source, and has a Wi-Fi connection to the Internet. The macOS version of Secure Backup also seems to have a preference for Wi-Fi connections, although I expect that it’s also perfectly happy to work over ethernet instead. Neither do Macs need to be ‘locked’ or even idle.

As the name implies, Secure Backup transfers and stores your data securely: data to be backed up is encrypted, and transferred and stored in iCloud in that encrypted form. The keys used for encryption are stored in a special iCloud Backup ‘keybag’, which is itself encrypted and stored with the encrypted data in your iCloud storage. Your keychain, at least in iOS, is specially protected using what Apple terms a “UID-tangled key”, which allows restoration only to the same device from which it came, and prevents any third-party (including Apple) from reading its contents.

What’s strangest about this in macOS is that there appears to be no user interface to Secure Backup: in iOS, this is controlled in the Settings app, but I have so far been unsuccessful in finding any control, or a means to restore from a Secure Backup, in Big Sur. Perhaps this is a feature earmarked for future extension.

Log entries made during a Secure Backup contain many Apple internal names which can make them opaque. There’s considerable involvement with Octagon and OctagonTrust, for example, which refers to a Private Framework of that name. I also noticed an error report in the sbd code which reads “unable to fetch certificate (lakitu error)”, referring to creatures in Super Mario Bros. My favourite error message, though, is “iCloud gave us junk for metadata”, which I hope proves rare.

For iOS devices, Secure Backup is an important feature for many users. While it already appears to function in Big Sur, its role is unclear at present. Hopefully this will become more clear in the near future.