Configuring Scheduled Task Runtime Conditions

This documentation is for an older version of CCC. You can find the latest version here.
Last updated on October 29, 2016

CCC 5.1.27 and CCC 6 can make bootable copies of the system on Intel and Apple Silicon Macs (11.3+) right now, and we'll continue to support that functionality as long as macOS supports it.

But as Apple's platform continues to evolve, we have to design our recovery strategies around the current hardware capabilities. A bootable external device may not be a part of that strategy. CCC can do so much more than just make copies of the system, and now is the right time to revisit your backup strategy and make it even better with some of the new features in CCC 6.

For decades, Mac users have taken for granted the Mac's "External Boot" feature. Prior to Mac OS X, people could simply drag and drop the System folder from one volume to another; presto, external boot volume. When Apple made it more complicated with Mac OS X, we pioneered the "bootable backup" solution (nearly 20 years ago!), and this has been a feature we've reliably supported on every new Mac and every new OS since then.

But Apple has never been afraid of shaking things up to blaze new trails. Big Sur and the new Apple Silicon Macs have shaken up the way Mac users will recover from hardware failure.

Big Sur's Big Change

All on its own, Big Sur introduced a significant new change to the creation of an external boot device. The operating system now resides on a cryptographically sealed "Signed System Volume" that can only be copied by an Apple-proprietary utility, "Apple Software Restore" (ASR). We were already familiar with ASR, so fairly quickly we were making bootable copies of Big Sur back in November. It hasn't been perfect though. We've performed tens of thousands of ASR clones at this point, and we've discovered that ASR is just not as robust as our own file copier. There are many scenarios where ASR simply fails with no explanation. ASR is also very one-dimensional; choosing to copy the system requires that we sacrifice other backup features, e.g. we cannot copy the system and retain versioned backups of your data, we can't evaluate what was copied, we can't exclude items from the initial backup, we can't save checksum data for later verification. So, while we're certainly able to make a bootable copy of the system with ASR, it starts to feel like using it causes us to lose sight of what's actually important to back up – your irreplaceable data.

Apple Software Restore isn't quite ready for the new Apple Silicon Mac storage

When Apple introduced Apple Silicon Macs, we discovered another snag. The "Apple Fabric" storage in these Macs offers per-file encryption keys (like the storage in iOS devices), and for months, ASR didn't work with it. Apple partially resolved that in macOS 11.3, but even now using ASR to clone the system back to the internal storage of these Macs doesn't quite work – it causes a kernel panic.

Back in December I had a conference call with Apple about the reliability and functionality of ASR on macOS and regarding Apple Silicon Macs in particular. They indicated that they were working to resolve the ASR/Apple Fabric issue, but they made it very clear that copying macOS system files was not something that would be supportable in the future. Many of us in the Mac community could see that this was the direction Apple was moving, and now we finally have confirmation. Especially since the introduction of APFS, Apple has been moving towards a lockdown of macOS system files, sacrificing some convenience for increased security.

An Apple Silicon Mac won't boot if the internal storage has failed

What did come as a surprise, however, was a very subtle logistical change noted in a Product Security document published in February regarding the new Apple Silicon Macs. A footnote at the very end of the document notes that, regardless of where the boot device is physically located, the boot process is always facilitated by a volume on the internal storage. The lightweight operating system on that volume ("iBoot") evaluates the integrity of the boot assets and authenticates the OS on that external device, then proceeds with the boot process from that external device. What does all of that mean? In theory it means that Apple Silicon Macs cannot boot at all if the internal storage fails. Lacking a Mac whose internal storage I was willing to damage to prove this, I contacted the authoritative experts within Apple in April and they unambiguously confirmed that that is the actual result – you can't boot an Apple Silicon Mac if the internal storage has died.

Apple has made clear that they will continue to support "external boot" on Apple Silicon Macs, but the reality is that it will be more limited in what it can do. If you were making your backups bootable in case of hardware failure, then that's an extra logistical chore that you can now retire from your backup strategy.

Future support for legacy bootable copies of macOS

Considering all that we know today about what the future portends, it's time to adapt our recovery plans – we should no longer rely on an external boot device for recovery from hardware failure. For our part, we've already adapted CCC 6 to this new direction. CCC will no longer present the "make it bootable" option to the user by default on Big Sur. As I alluded to back in November, I'm actually pretty stoked about this. Things are going to change, and Apple has taken away a venerable troubleshooting device, but on the whole, things are going to get simpler. For the average user, we're going to make it really easy to create feature-rich backups without all of the logistical idiosyncrasies of copying the System.

But, we're not dropping the ability to copy the System; we're going to continue to offer it with a "best effort" approach. We're going to be honest and direct about the limits of a bootable device in terms of recovering from hardware failure, but then we'll place the bootable copy solution right at the tip of your fingers.

Here's how it will look in CCC 6:

Catalina: Business as usual – when you configure a backup of your startup disk, CCC will copy the system files with our file copier, and barring any hardware compatibility issues, the backup should be bootable.

Big Sur (and beyond): CCC will create Standard Backups by default. If you want CCC to erase the destination and try to create a bootable copy of the source, simply click on the Destination selector and choose "Legacy Bootable Copy Assistant".

Click on the destination selector to access the Legacy Bootable Backup Assistant

How do I restore data from my backup if it isn't bootable? How do I get my Mac back to working condition after an OS or hardware problem has occurred?

When CCC creates a Standard Backup of your startup disk, it's backing up all of your data, all of your applications, and all of your system settings. That's everything about your Mac that is customized, and that's everything that you need to get back to productivity on either your Mac or on a replacement Mac. After you have reinstalled macOS on your Mac, or when you boot a new Mac for the first time, you can migrate data from your CCC backup via Migration Assistant. CCC Standard Backups are compatible with Migration Assistant, and we support that configuration.

We document that procedure, along with numerous other ways to restore data from a CCC backup here:

How to restore from your backup

We've got you covered

Frequent change brings challenges, but it also pushes things forward. At Bombich Software, we deal with the frustrating details so you get to enjoy the benefits of the cutting edge. There is no better demonstration of this than the brand-new, feature-packed CCC 6, along with our consistent update schedule. Time and time again we've proven that when Apple throws the next curveball, we'll knock it out of the park. There's a reason we've been here alongside you for nearly 20 years.