Big Sur (macOS 11) users, see the Shirt Pocket blog for instructions. The latest version of SuperDuper! Is faster, better, fully compatible with macOS Catalina (10.15) - in fact, it's compatible with macOS 10.10 and later, has Smart Wake, Smart Delete, Notification Center support, additional control capabilities, and improves many aspects of. CCC will be able to use Apple's APFS replication utility ('ASR') to copy the System volume (we field-tested that functionality for the flawed 10.15.5 update). As of the latest Big Sur release, however, Apple's APFS replication utility is not working correctly with the Signed System Volume.
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 volumes cloned by CCC (whether CCC used ASR or its own file copier). Some Big Sur cloned volumes do not appear in the Startup Disk Preference Pane, despite being perfectly bootable.
In Big Sur you can not use something like Carbon Copy Cloner to create a bootable clone?! Not with SuperDuper, at least, not in the way you can with previous versions like Mojave and Catalina, where you can direct the software to make the clone and the clone will be bootable afterwards. Related posts Helicopter Helicopter Market – COVID-19 Industry Impact Analysis, Market Trends, Market Growth, Opportunities and Forecast 2025 Samsung SDI to supply battery cells to start-up EV RivianNews Carbon Copy Cloner is popular software that allows Mac users to easily backup entire disks and partitions on macOS. While macOS Big Sur is about.
We have reported this issue to Apple (FB8889774) and we are currently awaiting a response.
Workaround: To boot from the cloned volume, restart your Mac while holding down the Option key, then select the cloned 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 cloned 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 clone just the System volume. As a result, every time an OS update is applied to the source, we would have to erase the whole destination volume (including any existing snapshots on that volume) just to update the system on the destination.
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.
We made a feature request to Apple in September 2019 (FB7328230) to allow ASR to clone just the System volume. Apple's APFS team acknowledged the request in June 2020 and clarified the requirements, and now we're waiting on the implementation.
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. If you would like to update the OS on the backup volume, you can boot your Mac from the backup and apply any updates via the Software Update preference pane in the System Preferences application. This is not something that we anticipate you would need to do frequently, nor even proactively. You could apply updates before attempting to restore from the backup, for example, if that need ever arises.
Apple Software Restore doesn't yet support the storage in Apple Silicon Macs
In the current shipping version of macOS Big Sur (11.2.3), Apple's ASR utility cannot replicate the startup disk in an M1-based Mac. Attempting to do so results in an error:
'Apple System Restore Tool': Source volume format not yet supported in this version of macOS
Apple is aware of the problem and is working towards resolving it for a future update to macOS. CCC 5.1.23+ will automatically perform Data Volume backups on M1 Macs and avoid any attempts to copy a System volume on those Macs — that's a complete backup of your data, applications, and system settings. If you would like to make your Apple Silicon Mac backup bootable, you can install Big Sur onto the CCC Data Volume backup. Please keep in mind, however, that your CCC backup does not have to be bootable for you to be able to restore data from it.
When Apple posts an update to macOS that resolves the ASR problem, we'll post an update to CCC that adds back support for copying the System volume on these Macs.
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 creates bootable backups. 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.
Big Sur Carbon Copy Cloner Software
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 on M1 Macs, leads to kernel panics
We have received several reports from M1 Mac users of kernel panics that occur while copying files to an SMB-mounted NAS volume. The kernel panic reports have confirmed that the SMB filesystem client (implemented via the smbfs.kext kernel extension) was stalled, which led to a 'watchdog' panic. These panic reports are automatically submitted to Apple, so we can presume that Apple is aware of the problem and working on a solution.
Workaround: Users have reported that using AFP rather than SMB consistently works around the panic (in cases where using AFP is an option):
- Eject the NAS volume if it's currently mounted
- Choose 'Connect to Server' from the Finder's Go menu
- Type in 'afp://{server address}' to connect to the NAS volume via AFP
- Open CCC and select the applicable backup task
- Drag the currently-mounted NAS volume (or folder or disk image on that volume) onto CCC's source or destination selector (whichever is applicable for your particular task)
UPDATE: 3/9/2021:
I remain unimpressed with the stability of Big Sur. Many users (myself included) are reporting kernel panics when waking from sleep and trouble using external displays with laptops.
In addition, the update process introduced in Big Sur was supposed to *reduce* install time, but has actually done exactly the opposite. Given the number of bugs and requisite updates being released, updates are taking upwards of 45 minutes each, longer if you don’t have a fast internet connection. Details here: https://eclecticlight.co/2021/02/28/last-week-on-my-mac-users-are-losing-out-against-big-surs-sealed-system/
Another problem with Big Sur is the cryptographically signed system volume. This was designed as a security mechanism, but in daily use it means that your Carbon Copy Cloner bootable backup must be erased each and every time the operating system is updated – a problem Apple introduced in Big Sur.
I still recommend Mojave (MacOS 10.14.x) or Catalina (MacOS 10.15.x) and am not recommending Big Sur at this time.
November 12, 2020
Apple released Big Sur – the newest operating system for the Mac today.
Carbon Copy Cloner And Big Sur
If you’re looking for the quick and dirty “should I install Big Sur?”, the answer is no, not yet.
Read on for more details and information:
Big Sur leverages the changes Apple made in Catalina, when it was released last October. Catalina was the first operating system for the Mac that only supports 64-bit application software. Older 32-bit apps do not and cannot be made to run in Catalina.
In addition, Catalina requires startup disks (including bootable backups) be formatted in the new APFS format, which Apple only supports on SSD media. This means there are ramifications for your backups (i.e. you’ll need new backup drives), if/when you update to Catalina or, as of today, Big Sur.
My observations regarding Catalina remain true – here are more details from back when Catalina was released:
I spent much of the day yesterday arguing with the Big Sur beta installer – not a good sign for stable, hassle-free software. Today’s public release (a gargantuan 12GB download) *seems* better, and Apple released a software update only hours after the initial release – not a confidence builder for well-tested code. I’ve only had a few hours to put it through the paces – so far things seem to be working and it feels snappy on my 2018 15” MacBook Pro.
There are some pretty significant cosmetic changes in Big Sur – for those who aren’t a fan of Apple changing/moving things around, this may be a release you want to wait to install, when you have time become familiar with the new bells and whistles. Here is an excellent comparison of some of the different look and feel changes from Catalina and Big Sur:
Bootable backups of Big Sur now require the system volume be cloned using a new software mechanism from Apple known as ASR. The system resides on a cryptographically sealed “Signed System Volume”. That seal can only be applied by Apple; ordinary copies of the System volume are non-bootable without Apple’s seal. To create a functional copy of the macOS 11 Big Sur System volume, Carbon Copy Cloner has to use the ASR tool to copy the system, or install macOS onto the backup. The upshot is that your backup drive will need to be erased the first time you run a clone under Big Sur and your previous backup data will be lost. If this is problematic for you, you can re-run the initial backup of your Big Sur Mac to a new external hard drive. More about Carbon Copy Cloner and ASR here:
So, my advice for now is to wait to download and install Big Sur. Give it and other third party software time to mature. And of course, I wouldn’t be me if I didn’t remind you to update your bootable clone backup immediately before downloading any software updates, especially new operating systems. And don’t run your backup again for a few days, until you’re certain everything is working as expected.