Hailed as one of the biggest new features in APFS, there’s nothing in macOS that’s more confusing than the snapshot. Even when you understand the concept, getting your head round the arithmetic of their size usually proves too much. Let me try to explain.

Each physical store, or disk, is divided into one or more partitions, continuous storage space managed by a file system such as HFS+ or APFS. As an old file system, HFS+ uses each partition as a single volume, but APFS treats its partitions as containers for one or more of its volumes, each of which shares the space within that container. That allows APFS volumes to change size as they need to contain the files they’re storing.

Each APFS volume consists of file system metadata, where it keeps the directories and other information it uses, and all the data that makes up its contents. Within the container, there’s one set of file system metadata for each volume, and the content data is then mixed with that for all the other volumes within that container.

Making a snapshot

As the name suggests, a snapshot is a capture of one volume at an instant in time. Making that snapshot is very quick and simple: for a moment, that volume’s file system metadata is frozen and duplicated to create an identical copy, which is saved as the snapshot. On slower Macs running large APFS volumes, you can sometimes notice taking a snapshot as a momentary freeze, but because the file system metadata is small relative to the file data, on faster Macs you won’t even notice this.

The purpose of a snapshot is to enable you to return that volume to a previous state, as defined by the file system metadata in the snapshot. To make that possible, from the moment that snapshot is made, the file system manages changes to file data differently, as it has to retain all changed data, or you wouldn’t be able to roll that volume back to the state of that snapshot. After making a snapshot, when you delete a file, the file system can’t erase and reuse the storage used by that data, it has to be retained until that snapshot is deleted. And that’s what makes snapshots so complicated, both as concepts and in the arithmetic of their size.

Snapshot size

To illustrate this with a very simple example, let’s say your APFS volume has 100 GB stored on it when you make a snapshot of that volume. You then delete a file that had occupied 10 GB. Without that snapshot, your volume would then have an extra 10 GB of free space, and there would be 90 GB of files on that volume. But because of the snapshot, those 10 GB aren’t free, as without them the snapshot would be unable to return that volume to the state it was in when the snapshot was made. Only when that snapshot is deleted do those 10 GB get made free for reuse.

The same happens when files change, only here the amounts are smaller, as the file system retains changed storage blocks rather than whole files. Return to that 100 GB of data, only this time instead of deleting a large file, just 1 GB of its data is changed. The snapshot then retains the original 1 GB, leaving 101 GB of data to be kept on that volume, whose free space has only fallen by that 1 GB.

So how big is that snapshot? There are two answers, depending on whether you want to know the space taken if you were to roll back to that snapshot, in this case 100 GB, or the amount of space you would free up if the snapshot were to be deleted. That would be 10 GB in the first case (after the 10 GB file had been deleted), or 1 GB in the second (when only 1 GB had been changed since the snapshot).

There’s such a big gap between these different ways of measuring size that it should always be clear which is being given. For instance, Disk Utility will always give the size it estimates would be freed by deleting that snapshot, while the Finder can give estimates on the space taken if you rolled back to that snapshot.

Because snapshots aren’t part of the currently active file system, they can be considered as potential free space when working out the amount of space remaining in a container. This isn’t entirely consistent, though. If you’re uncertain how much space really is free, don’t use figures given by the Finder, but those in Disk Utility, where you should see truly Free Space, Purgeable Space (which may include snapshots), and their total given as Available Space.

Once a snapshot has been made, the amount of data it has to retain is only going to increase over time, as it accumulates more blocks of changed or deleted data. This is why all apps that can make snapshots, including Time Machine, are required to remove those snapshots in time. Occasionally, a Time Machine local snapshot becomes orphaned, and left beyond the 24 hours after which it’s supposed to be deleted. That snapshot can readily grow and choke that volume and its container.

Snapshot deltas, mutability and copies

macOS keeps a record of changes made to each volume in its FSEvents database, normally used by Time Machine when working out what needs to be backed up. As Time Machine also makes and keeps snapshots for the last 24 hours, it could instead (as it did back in High Sierra) compare snapshots to determine what has changed in the period between those snapshots, what’s called a snapshot delta (the Greek letter for d, standing for the difference).

One important feature of APFS snapshots is that they can’t be changed once they’ve been made. While there’s no fundamental reason that editing snapshots shouldn’t be possible, it’s certainly complex, and snapshot immutability is one of their features in APFS. This ensures that, should you want to roll back to a snapshot, or recover files from one, you should get everything you expect. Snapshots thus form a reliable record of past file system state.

You can’t ordinarily move or copy a snapshot to another volume. Although snapshots are stored in the container rather than the volume, because of their associated file data, copying a snapshot isn’t like copying a folder. As far as we know, when Time Machine backs up to an APFS volume, it effectively copies a snapshot, but does so in a complicated way, by copying all the changed data and synthesising the snapshot on the backup volume. This can become confusing, as Time Machine also makes local snapshots on each volume that it backs up. Thus, it makes two snapshots for each backup: a normal, local snapshot on the same volume, and one on the backup store, synthesised from the file system and data that it has copied during the backup.

Summary

• A snapshot consists of a copy of the file system metadata at the time the snapshot was made, blocks containing all the data on that volume that has changed since, and the unchanged data in that volume at that time.
• Changed file data in a snapshot will only be freed when that snapshot is deleted.
• Snapshots can’t be changed, although the file data for them will grow over time.
• Time Machine makes local snapshots on each volume it backs up, and creates backups on the backup storage, in the form of snapshots.