Last Week on My Mac: Why has Apple put snapshots in a straitjacket?

Last week has been a fascinating journey into one of the crown jewels of APFS: snapshots. Soon after I had set off and was discovering how powerful they are, I was angry with Apple for locking them away in relative obscurity, and infuriated at how difficult it is to make a snapshot of an arbitrary volume. My epiphany came a day or two later, when it dawned on me how easily Apple could have let snapshots destroy the reputation of its new file system.

An APFS snapshot is a near-instantaneous copy of the file system metadata of a given volume, together with all the data referenced by it, which enables you to restore the file system to that state. Because no data is actually copied at the time, a snapshot takes but a moment to make. As the volume changes subsequently, the snapshot retains its original data and metadata, rather than returning them for re-use as free space.

Currently in macOS Mojave, there’s no utility or command which will just make a snapshot on any APFS volume. You can only make them as part of a controlled backup system such as Time Machine, Carbon Copy Cloner, or SuperDuper!, and when you do so, your snapshots are rigorously controlled within that system and automatically deleted over time.

Even if you’re a developer and prepared to write your own code, making a snapshot is impossible without Apple’s explicit approval: the function call fs_snapshot_create() not only requires superuser privileges, but for it to work, your app has to have a special entitlement granted by Apple. Apple apparently only approves applications for use in carefully-managed backup environments.

At first sight, this appears absurd: build a powerful new feature into macOS, then make it almost impossible to use.

A couple of days ago, following my epiphany, I explained why this is necessary. Yes, snapshots are very powerful and have many uses, but they also have a fatal flaw. Without strict controls over their number and age, you can easily fill your storage with old snapshots. Because they’re essentially transparent to the user, it’s all too easy to forget that they’re there. Running a fairly unexceptional setup, with Time Machine making hourly backups, snapshots currently occupy around 10% of the space used on my two main working volumes. On my 1 TB internal SSD, that’s 55 GB for just the last 24 hours.

Imagine what might happen if a user were able to click on a button and make an uncontrolled snapshot, perhaps just before they installed a software update, to let them roll back quickly in case anything went wrong. At the time, the snapshot would take no additional space, and after the installation it might occupy less than a gigabyte.

Then they forget about that snapshot, and carry on using their Mac for a few days. By this time, many more files have changed on that volume, and that snapshot is preventing those changed blocks from being reused. Its effective size could now be 25% or more of space used, and threatening to take over their storage. Yet they can’t see the problem, other than the fact that their free space is falling steadily towards zero.

Features, no matter how powerful or useful, which bring many Macs to their knees like this aren’t going to enhance the reputation of APFS or macOS, but cause alarm among many users.

The problem for Apple is almost unique: wrapping a file system feature in a user-protective interface. For the moment, its solution is good, but if users are going to get the most out of snapshots, it’s not only too restrictive, but also being applied at the wrong level for the longer term. Time Machine has proved itself an excellent all-round backup product which has saved many users’ skins, but as it stands it’s only a small part of what macOS could be doing with snapshots.

Users have learned to live with dangerous abilities such as deleting files and folders, thanks to the protection built into the Finder’s Trash interface. Of course we still all make mistakes, so we’ve got additional features such as versions and backups, and with their aid it’s actually hard to obliterate a file unintentionally.

I think the best answer is not going to come from stringent limitations on how apps manage snapshots, but in building in system features which do so. For instance, each snapshot when made could be assigned a lifetime, on the expiry of which it would be removed by macOS. When snapshots start taking excessive amounts of storage, macOS could also involve the user in tackling the problem before it grows to the point where it affects them. Then developers will be able to start realising the power of snapshots at last, perhaps making an automatic snapshot at the start of each installation, with a lifetime of but a few hours, safe in the knowledge that macOS will remove it automatically.

Cast your mind back just a few years, and there was a time when the user had to manage memory, allocating fixed limits to each app. Since then we’ve been able to hand over such tasks to macOS, which does a far better and more dynamic job. Maybe we need a similar approach for storage.

In the long term, the best way to harness power is with design, not restriction.