Why you shouldn’t try cloning your Apple silicon Mac’s startup disk

When upgrading from an Intel Mac running older macOS to a new Apple silicon Mac, you’ll notice a great many changes. Although it won’t be immediately apparent, one of the most limiting might appear to be that you can’t ‘clone’ your startup disk on an M-series Mac. This article explains why cloning is no longer recommended, and what you should do instead.

The traditional boot disk

From the first release of Mac OS X 10.0 Cheetah 23 years ago until macOS Catalina 18 years later, the main structure of the boot disk remained largely unaltered, although hidden Preboot, Recovery and VM volumes were added over the years. Even with the introduction of APFS in High Sierra, the main Macintosh HD volume contained a combination of system and user files, making it convenient to copy in a ‘clone’. The only complications arose with ensuring the boot volume’s UUID remained unique, and negotiating System Integrity Protection (SIP, introduced in 2015) for most of its system files.

It was common practice to clone the bootable volume, sometimes repeatedly, a trick often used to defragment free space within the volume, for instance. If you wanted a copy of macOS to undertake tests with, or for research, then cloning a known good copy of macOS was a popular solution.

Secure boot and Apple silicon Macs

Early in the design process for Apple silicon Macs, Apple decided that their boot security should be improved from what had worked satisfactorily back in 2000 to a more resilient scheme suitable for 2020 and well beyond. This was implemented progressively from Catalina to Monterey, and in Apple silicon Macs always starts the boot process from the internal SSD. This provides a verified chain of trust extending through each step in the process from the Boot ROM through to the bootable system, with its kernel and system files stored in a read-only snapshot and verified using cryptographic hashes.

To implement this, the internal SSD of an Apple silicon Mac is divided into three APFS containers, and that for the system separates immutable system files into a System volume snapshot with its hash tree, with writeable files in a Data volume. Those two volumes are joined using multiple firmlinks into what is effectively a single coherent directory tree rooted in the System snapshot.

Creating this boot volume group is complex, and broadly consists of:

create the two volumes within the Apple_APFS container, with their directories and firmlinks;
copy system contents to the System volume;
make the snapshot of the System volume;
build the tree of cryptographic hashes to verify the entire contents of the System snapshot;
seal the hash tree and hash the seal to create its signature;
verify the signature against that prescribed by Apple;
copy mutable system files and user files to the Data volume.

Another of Apple’s objectives was to support Secure Boot when starting up from an external disk, in contrast to T2 Macs which can only boot from external disks if that is explicitly enabled in Recovery mode. To accomplish that, the normal Secure Boot process is run from the internal SSD first, and relies on saved LocalPolicy to determine whether that can transfer to a bootable system with its own kernel stored in a similar boot volume group on external storage. Thus, external boot disks for Apple silicon Macs have just the single Apple_APFS container, complete with its paired Recovery volume.

Could macOS clone a boot volume group?

Although no longer encouraged, it has proved possible to create a complete copy of the Apple_APFS container using asr, the command tool intended for this purpose.

asr is complex, and at times has suffered bugs that have prevented it from working correctly. It appears to have been the solution used by products such as Carbon Copy Cloner, which have worked in the past. Given the complexity of the boot volume group, it’s perhaps surprising that it has been able to create clones successfully. If you want to know how to do that, this account is well worth reading before you make any decision.

Why might you clone a boot volume group?

Some of the original reasons for cloning boot disks as a maintenance procedure have now vanished; there’s no need to defragment free space, nor to ‘refresh’ a file system, for instance, when using APFS on an SSD.

As a means of making a quick copy of a known good bootable system, for example before undertaking research or tests that might render a system unbootable, it’s no longer suitable because of its complexity and fragility. The last thing you’d want to do is to put the boot volume group on your Mac’s internal SSD at risk by trying to clone to it from external storage, and attempting that in Recovery mode would be a long and daunting task.

Cloning from one bootable external SSD to another has been performed successfully, but again is less reliable than simply installing macOS and then populating the data volume from another data volume or backup.

Alternatives

In most cases, rather than trying to clone an existing boot volume group, it’s simpler and more reliable to run the macOS Installer to create a fresh system, then populate its Data volume as desired.

Unless there are compelling reasons to boot an Apple silicon Mac from an external disk, it’s faster and more reliable to boot from its internal SSD.

In the more distant past, it was common for backups to include a bootable system, making the backup bootable. These were superseded with the introduction of the Recovery volume, which provides a set of tools for checking and repairing the file system, installing macOS, and migrating user files to the Data volume. Apple silicon Macs have two separate Recovery systems, one paired with each boot volume group, the other in the Apple_APFS_Recovery container on the internal SSD.

If research or testing carries any significant risk of damage to the boot volume group, then it’s usually preferable to create a lightweight Virtual Machine and use that instead of a boot volume group on the host. VMs run at close to native speed, and can be cloned instantly. Using a suitable virtualiser, the VM can be run in a sandbox and completely isolated from host resources including its file system. Once the VM has served its purpose, it can then be trashed.

When substantial damage has occurred to the contents of the internal SSD, the best way to return it to normal is to boot it in DFU mode connected to a second Mac, and perform a full restore. That returns the Mac to as-new condition with a fresh set of pre-boot ‘firmware’ and full macOS, ready to migrate into from a backup. That isn’t possible using cloning.

Summary

Apple silicon Macs must start their Secure Boot process from internal ROM and pre-boot phases that are only installed on their internal SSD.
Structure and installation of a modern boot volume group is much more complicated than the single-volume layout of the past, and doesn’t clone reliably.
Cloning a boot volume group using asr is more complex and less reliable than installing macOS.
Never try cloning to the internal SSD. It’s not worth the risk.
In the event of substantial damage to the contents of the internal SSD, perform a restore to it in DFU mode.
High-risk testing and research is best performed in a virtual machine, if necessary run in a sandbox and isolated from the host.