Mac boot disks have changed beyond all recognition over the last few years. Although Intel Macs still have a degree of flexibility, Apple Silicon Macs adopt a model in which, come what may, they have to start the boot process from their internal SSD. The system itself has gone from an integral and largely mutable part of the boot disk to a sealed snapshot. While we could freely clone our boot disks to and fro, even using that as a method of defragmentation, cloning the system is now frowned upon and fraught with problems. This article looks at the way ahead with your Mac’s recovery system, and how useful re-installing macOS is as a generic solution to problems.

macOS may be Unix-like in many respects, but its system is now very different from what you’d expect to see elsewhere. From Big Sur, and almost certainly in Monterey, nearly all of what we refer to as ‘the system’ is not only a separate volume, but locked and sealed away in a snapshot which is mounted and used to boot from. So long as the seal remains intact on that snapshot, nothing can change it, not even the system itself. That seal is a guarantee that every last bit in the system is exactly as it was when it was installed, and matches perfectly with Apple’s original seal too.

Re-installing macOS as a panacea

The traditional reasoning behind re-installing macOS is that something may have become corrupted within the system, so re-installing it could fix that, and restore normal function. For the great bulk of macOS, that no longer applies, but there are still significant parts of what we include in macOS which aren’t sealed on the System volume. Most significantly, these include:

• Much of Safari and its support files. These are unfortunately divided between the System and Data volumes, apparently in a bid to make it easier to update without a full system installer.
• The MRT app, which is updated separately. In October 2020, Apple pushed version 1.68, which had a bug in Sierra and El Capitan.
• XProtect’s data (Yara and other) files, which are usually updated every couple of weeks.
• Three Apple kernel extensions.
• Rosetta 2 (M1 Macs only), which isn’t installed by default and can be updated outside system updates.
• All mutable system configuration and settings files, which of course have to be writable.

Oddly, Apple’s Platform Security Guide states: “the user’s data volume is never mounted during a software update, to help prevent anything being read from or written to that volume during updates.” It’s hard to see how the components listed above, particularly Safari, can be updated without mounting the Data volume, though.

Perhaps the most frequent cause for wanting to re-install parts of the system which remain unsealed is therefore a problem with Safari which can’t be resolved by another means. As Apple no longer supplies separate Safari updates for the current release of macOS, this remains of potential value.

Other reasons for re-installing macOS are more dubious. Kernel extensions, with the three exceptions noted above, are either Apple’s and inseparable from the sealed system, or third-party and installed on the Data volume. If the problem is in a system kernel extension, you might have to try installing an earlier version of macOS, but re-installing the current release is a waste of time. If it’s a third-party kernel extension at fault, that needs to be removed from the Data disk, not the System. If the problem lies with configuration or settings, then only a clean install – after erasing both System and Data volumes – stands a chance of success, and even then migrating from a recent backup may just bring the problem back.

Big Sur’s sealed system volume should have made re-installing macOS much less frequent, and rarely worth trying as a solution now.

Recovery disks

Creating an external bootable disk, with or without backups on it, is more complex, because of the differences between types of Mac.

For Intel Macs without a T2 chip, the arguments for and against are relatively unchanged, except that you shouldn’t rely on being able to clone the system any more, and cloning from an external disk to the internal one may prove increasingly unreliable. But there’s no functional difference between bootable internal and external disks: both can have full-featured recovery systems, although you’ll still want to run Diagnostics from the internal disk.

Add a T2 chip and there’s one major problem: in order to be able to boot from an external disk, you have to change that Mac’s startup security settings to explicitly allow that. If you haven’t enabled booting from an external disk, then before you could use any external recovery disk, you’d have to boot into recoveryOS on its internal storage and use Startup Security Utility to change that. As recoveryOS is stored within a volume within the startup container, thus shares disk space with the System and Data volumes, any more serious problem could force you to boot that Mac in Internet Recovery, making an external recovery disk of limited value. Unless you’re happy to reduce the security on all your Macs with T2 chips, an external recovery disk is unlikely to be worth the effort.

For an M1 Mac, the situation is different again. Although you can boot those Macs from external disks without reducing their security settings beforehand, an M1 Mac can have only one full-featured recovery system, and that’s kept in a separate container on the internal SSD, and can’t be copied or moved. The only way of accessing all the tools provided in recoveryOS is therefore to boot it in Recovery mode (1 True Recovery) from its internal SSD.

Unlike Intel Macs, recoveryOS on an M1 Mac isn’t stored in the same container as the System and Data volumes, but in a completely separate container, which doesn’t share disk space with macOS volumes. This makes M1 Recovery far more robust, and the least unlikely event which might prevent you from accessing Recovery is functional failure of the internal SSD. If that’s a soft failure, the only solution then is to restore that Mac in DFU mode – which is an exceptionally rare requirement.

Given that an external disk attached to an M1 Mac can’t provide Recovery, and lacks key tools such as Startup Security Utility, which can only be run from the primary copy of recoveryOS on the internal SSD, it’s hard to see any value in making an external backup bootable, or in trying to create an external recovery disk. One common reason in the past for preferring a custom recovery disk was to include file system repair tools, such as Disk Warrior and Drive Genius. Currently, no third-party disk utilities can work independently on APFS disks, and those which do so at present only use the same tools available to the user in Recovery mode.

Best practice for an M1 Mac is to ensure that it’s fully backed up, Data and external volumes only, to separable external storage. Should a problem arise which require Recovery, then it should be started up in primary Recovery mode. If necessary, it can then have its macOS container erased, a fresh copy installed, and migration performed from the backup. Cloning to or installing macOS on a backup disk serves no useful purpose, and just wastes 15 GB of space.

Summary

Re-installing the system in Big Sur should only rarely be of any value when trying to fix problems. The most likely situation in which this could help is when Safari has serious problems which can’t be fixed by any other means.

Intel Macs without a T2 chip can still have external/removable recovery disks which should function as before, although cloning the system is likely to become increasingly difficult.

Intel Macs with a T2 chip can only use external recovery disks if their security protection is downgraded at all times to allow them to boot from external disks.

M1 Macs don’t benefit from external recovery disks. Use their primary recoveryOS on their internal SSD instead. Neither does making their backup disks bootable serve any useful purpose.