Apple published macOS Big Sur in November 2020. CCC 5.1.22 (and all versions of CCC 6), published in October 2020, is fully compatible with macOS Big Sur. We cite known problems that Apple introduced in the new OS below.
Some Big Sur startup volumes don't appear in the Startup Disk Preference Pane
In the past, the Startup Disk Preference Pane would list all available startup volumes, including CCC backup volumes. When Apple's APFS replication utility is used to copy a Big Sur System volume (something that is now required on macOS Big Sur), however, the cloned volume will not appear in the Startup Disk Preference Pane, despite being perfectly bootable.
We reported this issue to Apple in Nov 2020 (FB8889774). Apple resolved the issue in macOS Monterey.
Workaround: To boot from the backup volume, restart your Mac while holding down the Option key, then select the backup volume in the Startup Manager. When your Mac has completed booting, you can optionally choose to set the startup disk to the current startup volume (i.e. if you want the Mac to always boot from the backup volume).
CCC will not update the System volume on a Big Sur bootable backup
Starting in macOS Big Sur, the system now resides on a cryptographically sealed "Signed System Volume". That volume can only be copied using Apple's proprietary APFS replication utility ("ASR"). Right now, ASR will only copy whole volume groups (System and Data); we can't choose to copy just the System volume. As a result, every time an OS update is applied to the source, you would have to erase the whole destination volume (including any existing snapshots on that volume) just to update the system on the destination. We made a feature request to Apple in September 2019 (FB7328230) to allow ASR to clone just the System volume. We do not anticipate that Apple will implement our requested functionality.
To avoid deleting your snapshots and the rest of your backup, CCC will not update the System volume on the destination when System updates are applied to the source.
Our recommendation: We recommend erasing the destination only for the purpose of establishing the initial bootable backup. CCC can then use its own file copier to maintain the backup of your user data, applications, and system settings.
Workaround: Any time you want to make the OS on the destination identical to the source, simply click on the Destination selector and choose Legacy Bootable Backup Assistant... to configure CCC to re-erase and reclone the entire volume.
Apple Software Restore causes a kernel panic when cloning to the storage in Apple Silicon Macs
In the current shipping version of macOS Big Sur (11.3), Apple's ASR utility can copy from the Apple Fabric storage in an Apple Silicon Mac, but it causes a kernel panic when cloning to Apple Fabric storage.
We reported this issue to Apple in March 2021 (FB9055615). Apple resolved the issue in macOS Monterey.
Workaround: If you need to recover your Apple Silicon Mac from a backup, we recommend that you reinstall macOS and then migrate data from your CCC backup using Migration Assistant.
Finder will not show, nor allow you to set custom icons on other Catalina and Big Sur startup disks
Finder will show and allow you to customize the volume icon for your current startup disk, but not for other Catalina- or Big Sur-bearing startup disks that your Mac is not currently booted from. This problem is not specific to CCC backups, but we see this frequently because CCC can create copies of macOS System volumes. This problem is the result of a design flaw in the implementation of custom icons in an APFS volume group. Up to macOS Catalina, the custom volume icon is stored in a file at the root of the startup disk named ".VolumeIcon.icns". To keep the System volume read-only, yet allow the apparent modification of this icon file, Apple chose to create a symbolic link at the root of the startup disk that points to System/Volumes/Data/.VolumeIcon.icns. For the current startup disk, this path resolves correctly because the Data member of the volume group is mounted at /System/Volumes/Data. That's not the case for external volumes, those Data volumes are mounted at /Volumes/CCC Backup - Data (for example). As a result, the symbolic link to .VolumeIcon.icns is unresolvable for any volume that is not the current startup disk.
We have reported this issue to Apple (FB7697349) and we are currently awaiting a response.
Other Catalina and Big Sur startup disks can't be renamed in the Finder
Finder will let you rename the current startup disk, but you won't be able to rename any other startup disks that have an installation of Catalina or Big Sur because the System volume is mounted read-only.
Solution: Unmount and remount the volume in Disk Utility, then right-click on the volume in Disk Utility's sidebar and choose the option to rename the volume.
We have reported this issue to Apple (FB8912480) and we are currently awaiting a response.
The System volume is not encrypted when FileVault is enabled on a Big Sur startup disk
This is not a bug, this appears to be a deliberate change on macOS Big Sur. When you enable FileVault on a Big Sur startup disk, the System volume member of the APFS volume group is not encrypted. Considering that this volume is identical on all Macs, encrypting its contents is not going to prevent someone from knowing what's on it, so the encryption does appear to be unnecessary. There is one undesirable effect of this change, however, regarding an encrypted, bootable backup disk. When you attach the device to your Mac, the System volume is mounted automatically, regardless of whether you unlock the associated Data volume. If you specifically choose to not unlock the Data volume, there are three results that range from confusing to annoying to alarming:
- The volume appears to be mounted in the Finder, despite not wanting to mount it
- None of the data on the volume is accessible because the Data volume isn't mounted, so you might be led to believe that your data has been lost
- There is no apparent way in the Finder to get the Data volume unlocked and mounted
You can unlock and mount the Data volume in Disk Utility to access the data. If you provided the volume's password to CCC, then you can simply run your CCC backup task and CCC will automatically unlock and mount the Data volume.
We have reported this issue to Apple (FB8918177) and we are currently awaiting a response.
Apple's SMB filesystem client causes system stalls, random application crashes, and may lead to kernel panics
We have received several reports from Apple Silicon Mac users of unruly macOS behavior that occurs while copying files to an SMB-mounted NAS volume. The behavior includes the following:
- Random application crashes
- Prompts to grant various macOS system services access to the login keychain (i.e. because the service that retains the unlocked keychain reference crashed, thus locking the keychain)
- Laggy mouse behavior
- System stalls that eventually end with a reboot and kernel panic report
We were able to reproduce this behavior using a simple shell script that creates files and folders on SMB-mounted NAS volumes (and also with Finder copies). The underlying problem appears to be a memory leak in the macOS kernel or one of the kernel extensions. Specifically, the "kext.kalloc.32768" memory zone is expanded until it can no longer be expanded ("zone_map_exhaustion" occurs), at which point the memoryd system process starts to terminate idle processes. This problem is limited to Apple Silicon Macs and SMB volumes.
We reported this issue to Apple (FB9857268) and we are still awaiting a response.
Workaround: We have confirmed that using AFP rather than SMB consistently avoids these behaviors (in cases where using AFP is an option):
- Eject the NAS volume if it's currently mounted
- Open CCC and select the applicable backup task
- Click on the Source or Destination selector (whichever is applicable for your particular task)
- Hold down the Option key and choose "Switch to AFP" (provide the credentials for the NAS volume again if prompted)
- Save and run the task
While we recommend using AFP whenever it is an available option, it's important to note that AFP is a deprecated protocol and that some NAS vendors have started to drop support for it (e.g. Western Digital MyCloud). If you are not happy with the performance and reliability of Apple's SMB filesystem client on the latest version of maCOS, please share that feedback with Apple, and please feel free to include our FB9857268 bug report number in that feedback.