Several of you have asked me why a user can’t make a snapshot of their current System volume in Big Sur, immediately prior to updating it, and use that snapshot to roll back to, if the update goes wrong. This article tries to explain why that’s not as easy or simple as it sounds.

What’s a snapshot?

Snapshots are common features in modern file systems, and are one of the core advantages of APFS. The purpose of a snapshot is to record the state of the file system of an APFS volume at a moment in time. To create one, all APFS has to do is make an exact replica of that volume’s file system. That’s then stored in the same container as the volume, and any time you want, you can revert the volume’s file system to the way it was when the snapshot was made.

The hidden cost is that, if you’re going to be able to revert to a saved snapshot, all the file data to support that volume information has to be preserved, otherwise many of the files that get changed after making the snapshot would be lost. To take an extreme case, let’s assume that the user deleted every folder and file on the volume. To be able to restore that snapshot, none of the deleted file data can be removed. Although the basic size of a snapshot is very small, its preserved data can amount to the size of all the data that was present when the snapshot was made. And until that snapshot is deleted, both the snapshot and the data for all the files inside it must be retained.

How is a Big Sur System made?

The major change in disk structure brought in Catalina was the division of the boot volume into two, kept in a Volume Group: the protected System volume, and the Data volume.

Big Sur takes this one step further: instead of booting from a read-only System volume, the Mac doesn’t boot from that volume as such, but mounts a snapshot of it. In security terms this is a great advantage, as nothing can tamper with a snapshot; it’s made even more secure by a scheme which seals the contents using cryptographic hashes. The simple way to understand how that works is to consider how this snapshot is made during installation.

Once the System volume has been installed, a hierarchy of SHA-256 hashes is made to cover every file on that volume individually, and its file system metadata, in a hierarchical structure culminating in a single top-level hash known as the Seal. That is then verified against a value which is signed by Apple, providing a chain of trust for everything in that System volume. When that has been completed correctly, a snapshot is made of this System volume, which is specially designated as a System snapshot and blessed.

Rolling back with snapshots

If you as a user make a snapshot of the System volume, you’ll get an unsealed replica of the System volume that can’t be used to replace the new sealed snapshot, and hasn’t even been blessed to make it bootable. Trying to roll back to that would only end in failure.

What has been tried earlier in Big Sur is preserving the previous bootable sealed snapshot rather than deleting it once a macOS update has been completed. This isn’t a cheap option, though: it would probably require up to 15 GB of free space on the System volume. Because of that, macOS would need to remove it automatically after a period of a week perhaps, which sets a time limit on its use for a rollback.

It’s unclear why Apple doesn’t provide an option in its updaters to automatically preserve the old snapshot for a maximum of one week, to support rollback over that time. Unfortunately, it’s not something the user can achieve any other way.