Bootable macOS backups do not matter anymore

Creating bootable backups has been a longstanding practice in the Mac community.

What was once necessary now appears superfluous.

The macOS boot process evolution

Summary of the recent changes made in the macOS boot process:

• High Sierra: APFS replaces HFS+
• Mojave: macOS boots from a single volume (as it has always done)
  • many folders in this single volume are protected by SIP
  • however:
    • there's no integrity check
    • there's little to prevent system files from becoming corrupted
    • there's no way of knowing whether they have been corrupted
• Catalina: macOS splits the single volume into two (via a new APFS feature)
  1. the System volume:
     • is mounted in read-only mode
     • only changes during macOS updates/installs
  2. the Data volume:
     • contains all writeable files that can change between macOS updates
       • e.g., Home folders
• Big Sur: macOS enters the Apple Silicon era and introduces the Sealed System Volume (SSV)
  • the System volume becomes a sealed snapshot with immutable files
    • except during macOS updates/installs
  • macOS boots from this sealed snapshot (via a new APFS feature)

Here are the highlights of a modern macOS update:

1. the Data volume is unmounted to protect its content from a failure
2. the System volume is mounted for writing
3. SIP is disabled
4. the contents of the update are written to the System volume
5. SHA-256 hashes are calculated and stored
   • for every file in the system, a SHA-256 hash is calculated and stored in the main file-system metadata tree
   • the file-system metadata tree itself is hashed
   • each node in the tree recursively verifies the integrity of its children's hashes
   • so the root node's hash value, known as the Seal, encompasses every byte of data
     • if a single bit in any of those system files changes, it changes the Seal
     • when that happens:
       • the Seal is broken
       • the Mac can no longer boot from that copy of macOS
       • the Mac enters Recovery mode for the user to re-install macOS
6. the installer makes a snapshot of the System volume with all the hashes and the Seal
   • this snapshot is known as the Sealed System Volume
7. SIP is re-enabled
8. the System volume is unmounted
9. macOS boots from that snapshot

The system volume is now:

• separated
• immutable
• validated using cryptography

From Apple's perspective, this prevents attackers to modify system components.

From some tools' perspective (like SuperDuper or Carbon Copy Cloner), this makes creating a bootable startup drive clone more complicated.

The Apple software restore a.k.a. the replicator

It's still possible to create bootable macOS backups:

• via the asr (Apple Software Restore) CLI utility
• which is an Apple-proprietary procedure

The replicator puts third party developers at the mercy of Apple's tool to provide bootable backups.

Update 30/03/2025: SuperDuper 3.10 Beta Works Around asr Bug

Migration assistant is enough

To mitigate the difficulty in creating bootable backups, Apple has made it trivial to:

• boot into macOS Recovery (long-press the power button)
• install/reinstall macOS (this will create a new, secured, immutable volume)
• restore user files to the Data volume using Migration Assistant

In this scenario, a Data volume backup is all you need.

Until you're customizing your own kernel and have changed the security policy, I can't think of any good reason to still create bootable backups.

It's also worth noting that a bootable macOS backup on a hard drive, rather than an SSD, will be useless:

[…] the last time I needed a bootable backup […] it was unusable. The core problem was that it lived on a hard drive rather than an SSD, and hard drives don't provide sufficient performance for booting macOS. If you're going to make a bootable backup, make sure it's on a fast SSD.