Snapshots are one of the huge advances in APFS, but like other features, they can cause more problems than they’re worth. This article explains how they can go wrong, and what you can do to manage them so they don’t swallow all the free space on your storage.

Why snapshots grow large

At its heart, a snapshot is itself very small: it’s simply a saved copy of the file system of the APFS volume at the instant the snapshot was made, a few MB, not GB. However, to be of any use, snapshots also need data. Without that, you couldn’t revert the volume to its previous state, or restore a file which has since been deleted.

What happens from the instant that snapshot is made is that all file data which would otherwise be deleted, either because the file itself is deleted or because it has changed when editing that file, is retained instead of being returned for re-use. For example, let’s say that after you’ve made a snapshot of a volume, you delete one 1 GB file, and change another 2 GB of data in other documents. At the end of that, the snapshot’s effective size is the original MB used for the file system itself, plus 3 GB, which can’t be deleted until that snapshot itself is deleted.

This gets more complicated when you make the next snapshot. After that, all changes are required by two snapshots, the original and the new one. Let’s say you now delete another 1 GB file and change 3 GB of data in other documents. The effective size of the data for first snapshot alone remains 3 GB, and that for the second snapshot is 4 GB. But deleting either or both snapshots won’t necessarily free what you might expect because some of the retained data will be common to both, and some will only be referenced by one of them. In Disk Utility, those sizes are shown as Private Size, which is the size of that snapshot alone, and Size, which is the cumulative size including all previous snapshots.

Snapshots have some important and relevant properties:

• In APFS, snapshots can only be made of complete volumes. If Time Machine backs up a single item on a volume, its snapshots will be for the whole of that volume, not just what’s backed up. This is a useful feature, as it allows you to access what are in effect full backups for a short period, while keeping formal backups far smaller.
• Best practice is to delete older snapshots first. Deleting intermediate snapshots will free less space than you might expect, because data still has to be retained for older snapshots.
• Snapshot sizes are approximate, in the sense that you won’t know how much free space you’ll actually recover until you delete them.
• You can’t undelete snapshots. Never.
• Snapshots are read only. Once created, you can’t modify them in any way, only delete them. And you can’t delete just part of a snapshot.

Apps that make snapshots must maintain them

Apple doesn’t let any old third-party app create snapshots, but vets them strictly and imposes requirements before it will grant its approval and the special entitlement enabling an app to make its own snapshots. Although I’ve been critical of this policy, it guarantees some degree of safety to the user.

Time Machine has a policy whereby it makes hourly snapshots of all volumes which it backs up, but deletes those snapshots automatically after 24 hours. This should ensure that the total space used by its snapshots remains relatively small, but if each snapshot requires 25 GB of data, disk space used by them will still mount up. There are additional levels of safety too: if free disk space falls too low, Time Machine should reduce the number of snapshots it retains, and if the worst comes to the worst, APFS should always ensure that there’s sufficient free space, if necessary by deleting older snapshots.

Third-party backup products which incorporate snapshot features, like Carbon Copy Cloner (CCC), are more flexible and you can set custom snapshot retention policies for individual volumes. These operate independently, so CCC can’t change Time Machine’s policy, neither can Time Machine delete CCC’s snapshots automatically.

Managing snapshots

Like anything else on your Mac, snapshots need a bit of supervision. As they’re capable of eating up huge amounts of free disk space, hundreds of GB at times, you need to keep an eye on them. If free disk space starts to fall on a volume on which snapshots are made, check whether that’s because of those snapshots. Disk Utility and third-party apps like CCC now give useful information about the number and size of snapshots on each volume, and provide tools for their management, most importantly their deletion.

If you find snapshots becoming very large, then you need to establish the cause. Deleting some of the older snapshots on that volume will free up disk space quickly and buy you time, but you don’t want to have to keep doing that in order to maintain sufficient free space. Besides, what’s the point of continuing to make snapshots if you’re going to have to delete them almost immediately?

Although Disk Utility and CCC tell you which app made each snapshot, and allow you to delete them, they can’t tell you why any given snapshot appears so large. To do that, you’ll need to keep a watchful eye on the apps you use. Anything that creates many large temporary files should be a suspect: while they can easily be excluded from backups, remember that a snapshot is of a whole volume, and includes all the files in temporary folders, the macOS versioning system on that volume, and the Trash, most of which are automatically excluded from Time Machine backups.

This is one of many reasons why macOS stores its virtual memory files on a separate volume named VM. They used to be kept on the boot volume, but if that were done now, every snapshot would contain large overhead from swap files. Apps which operate their own forms of virtual memory, perhaps caching large data files, or versions of very large documents in the macOS versioning system, could pose similar problems. In most cases, apps should provide settings in their Preferences which let you store their temporary files on a volume which isn’t backed up, so avoiding them swelling the size of hourly snapshots.

For the great majority of users, snapshots are a valuable enhancement and cause no problems. But for a few, if they’re not carefully managed, they can eat so much free space that it affects their work. Instead of just deleting them, you need to discover the cause and address that. In a very few cases, it could mean that using snapshots as part of your backup strategy isn’t a good idea, in which case Time Machine isn’t a good choice. Thankfully, such cases should be rare.