Afaik there's quite a bit of a problem when cloning Big Sur. It is a known issue that you cannot properly get a complete backup of Big Sur using the traditional cloning method because Apple had changed the way the data is saved since Sierra ie. containers.
The CCC complete clone via the APFS replicator option (CCC calls it something like Legacy Bootable Backup Assistant) works fine at least up through macOS 11.5.2 and prolly for 11.6, though I personally haven't tested 11.6
Using APFS replicator requires erasing the target drive, so a full backup is required.
CCC makes it easy to run the APFS replicator, but CCC makes a point to note that it's an Apple built-in with no promise by Apple to keep it working. (But Apple promises nothing anyway.)
There is a very grave concern that if there are any read errors on the source, APFS replicator fails with no explanation and the clone is useless. — This is just a fact of life using the replicator.
Unlike using the Apple APFS replicator option, CCC's built-copier is resilient to errors, keeps running, and notes affected files in the task log. But it can't handle the signed system volume (SSV) due to the crypto that ensures it isn't tampered with.
So yes, you can get a complete system clone using CCC, assuming the source drive is healthy.
The problems with CCC backups based on SSV pertain to making incremental clones: due to the crypto, only the Data volume can be incrementally copied.
This restriction is ok as long as the SSV isn't updated.
The problem attends when Apple code in the Data volume, including apps such as Safari, and support libraries of any kind which depend on a certain rev of the system volume, get updated but the system volume does not, or vice-versa.
There's no simple way to handle this that fits well with the overall Apple update capability and CCC's idea of tasks.
The workaround is to completely disable automatic updates, then arrange updates to include a subsequent full APFS replicator backup. As this will erase the target, the user should have two backup drives and alternate between them to avoid a gap in backup coverage, especially because the time you're most likely to encounter source drive errors is precisely during the APFS replication, which leaves arbitrarily incomplete and essentially unusable backup data upon failure.
Bombich recommends just making Data volume backups and doing Apple SW restore plus Migration Assistant to recover, but this also doesn't quite address any mismatch between the OS rev of the backup and the restore either. Consider how iOS requires a equal-to or newer install to restore from a iTunes backup, which leads to problem of you can't recover using an older device which doesn't support newer iOS.
The combinatorials get especially on macOS because of 3rd party App dependencies.
Due to the inability of CCC to keep incrementals tracking the OS for easy recovery, the primary selling point of CCC bit the dust with the SSV. No doubt this has been incredibly aggravating for Bombich+Users.
However, the old approach can still work with appropriate care, and a clever user can fudge a complete recovery out of mismatched SSV and data. The trick is there are pitfalls that may test the resolve of even the experienced mac admin.
The way to make sense of it is as follows:
• Get OS + Apps to desired rev
• Completely disable auto SW updates of OS and Apps
• Make a full clone with APFS replicator
• Run incrementals as you like with the proviso of no-Apple-SW-updates allowed and limited 3rd-party App updates allowed between incrementals (know your apps!)
• Schedule the job of any Apple update to include an immediate subsequent system full clone and verify you can start from new backup
• Use two backup drives and alternate between them for the full clones
And don't forget to watch our for any of the myriad other ways that backups can go wrong!
HTH, I am using this method and I have recovered from a couple of NVMe drive failures by booting via OC to backups made as described above on both NVMe and SATA drives.
This said, and to repeat: There are still ways for things to go wrong.
