Most backup utilities now make snapshots of volumes they’re backing up, and Time Machine goes further by using snapshots in its backup process, and creating backups as snapshots. How then should we include snapshots in our backup plans? Could we rely on snapshots rather than conventional backups?

APFS snapshots

Each snapshot contains a complete set of the file system metadata for that volume at the time the snapshot was made, and all the extents required to reinstate that volume. Although tied to that volume, the snapshot is stored alongside the current volume metadata, in the same APFS container, in the same disk partition.

Extents list the storage blocks containing the data that composes every file that existed within that volume at the time the snapshot was made. Many of those will be the same as in the current volume, but the remainder will refer to data that has been deleted since the snapshot was made, but is being retained to enable the volume to be rolled back to its previous state. Those old extents can only be removed when that snapshot is deleted, which thus frees all those storage blocks at the same time. This is illustrated in the diagram.

This shows the same file in a snapshot and the current volume. Extents for the data of the earlier version of that file contained in the snapshot are shown at the top, and consist of blocks EA, EB, EC and ED. After that snapshot was made, the file was edited and then consists of the blocks shown at the bottom, EA, FB, FC and ED.

Thus, the extents listed for that file in the snapshot consist of two blocks, EA and ED, that are currently in use and included in its extents now, and two blocks, EB and EC, that were deleted after the snapshot was made. However, as those are referenced in the snapshot’s extents, those storage blocks are retained to enable the snapshot to restore the volume’s previous state. When that snapshot is deleted, blocks EB and EC will then be returned to the pool of free blocks for erasure and re-use.

This demonstrates how snapshots depend on their own file system metadata, and a combination of currently used storage blocks and those awaiting return for re-use.

Rolling back to a snapshot

The most popular reason for wanting to roll back to a snapshot is to recover from problems following a macOS update. As the System volume isn’t included among backup snapshots, and the process of rolling back would be so complex that it’s probably not possible, there’s no point in considering the use of snapshots for that purpose.

In other circumstances, where part or all of a user volume is to be restored from a snapshot, once that snapshot has been mounted, the procedure is the same as for restoring from a backup. What is different is that restoring a whole volume from a snapshot is a one-way trip, and there is no undo. This is because snapshots subsequent to that used to restore from will be removed, and you won’t then be able to ‘roll forward’ to a later snapshot. That contrasts with a normal backup, where items remain available from any other backup that is retained in the backup store.

Snapshot robustness

Long before the introduction of APFS, Time Machine created its own form of snapshots when a Mac was away from its normal backup store. Those enabled anyone travelling without an external drive to have limited ability to restore lost or damaged files despite their lack of conventional backups. Experience showed this to be useful in the event of human error, such as accidental deletion of files, but of limited or no use when there were file system errors.

Because snapshots share the same container as the current volume, and share many file extents with them, they are prone to common errors. In particular, common file extents make it more likely that faults occurring in extents and data storage will affect them both. This is particularly important as one of the most common file system errors that corrupts data in files occurs when extents for two separate files overlap. A snapshot is thus more vulnerable than a backup on a different disk, or even one in a different container on the same physical store.

Snapshots are whole-volume

Snapshots do have one specific advantage over backups when it comes to their coverage. As they include the whole file system metadata for the volume, no items present in that volume are excluded from its snapshots. If you want to restore an item that has been excluded from backups made of any volume, you can therefore do that from its latest snapshot, if that item was present in the volume at the time that was made.

The only disadvantage to this is that snapshots can be disproportionately large compared to volume backups. If large and ever-changing files such as Virtual Machines are excluded from backing up, but are in a volume for which snapshots are made, those snapshots may appear excessively large. The solution is to move those files to a separate volume, for which snapshots aren’t made. This behaviour can also raise privacy concerns over data that aren’t encrypted on disk, as they too will be accessible in that volume’s snapshots even when excluded from its backups.

Conclusions

• Because snapshots contain metadata and data common to the current version of a volume, and share the same container, they are prone to common errors.
• Restoring a snapshot can’t be undone, and removes later snapshots.
• Snapshots are a useful addition to conventional backups made to separate storage, but can’t replace them.
• When conventional backups aren’t available, snapshots can be invaluable.
• Snapshots can be used to restore items that were excluded from backups.
• Snapshots can’t be used to roll back from a bad macOS update.

Reference

APFS snapshots in detail

macOS Sonoma brought major internal changes to iCloud Drive, and coupled with the opacity of Time Machine, you may now be wondering whether it still backs up what you have stored in iCloud Drive, and if so, where to find those backups. This article explains how this now works, and where those backups can be found.

What does Time Machine back up?

By default, Time Machine backs up almost everything on volumes it’s set to back up. It doesn’t, of course, try to back anything up from the Signed System Volume (SSV) containing macOS itself, and there are a few folders it automatically excludes, such as the hidden folder at the root of each volume containing the versions database (as that can’t be restored in any case). But unless you add iCloud Drive to its exclusion list from your Home Library folder, Time Machine will back up all the files and folders in iCloud Drive as long as they’re stored locally at the time it makes that backup.

Dataless files

It’s that last condition that’s the most important consideration. If your Mac has Optimise Mac Storage turned off, then iCloud Drive is run as a Replicating FileProvider, where everything stored in iCloud Drive is also stored locally. In that case, all those items will be backed up by Time Machine just as they would be if kept in purely local storage.

If Optimise Mac Storage is turned on, iCloud Drive behaves as a Non-Replicating FileProvider, and some or many of the files you store in iCloud Drive may be evicted from local storage, and are then no longer available for backup. This is explained in the diagram.

Files in local storage consist of attributes, metadata (extended attributes) and data. Move them to iCloud Drive and their data is then copied up to iCloud. When a file is evicted to save local storage space, the local file’s data is removed, making that copy of the file dataless. In previous versions of macOS, that was accomplished using a special stub file, but in Sonoma it simply loses its data, and the distinctive iCloud icon is displayed next to the file in the Finder.

Dataless files can’t be backed up by Time Machine, as without their data there’s nothing to back up. If you want that file to be backed up, then it has to be downloaded or materialised by downloading its data from iCloud. Some third-party backup utilities can manage that automatically for you, but Time Machine doesn’t. If you want to ensure that a file in iCloud Drive is backed up when Optimise Mac Storage is turned on you’ll thus have to download it manually if it has been evicted to iCloud.

Restoring from backup

The simplest way to restore a file or folder in iCloud Drive from a Time Machine backup is through the Time Machine app. Before opening that app, select iCloud Drive in the sidebar of the front Finder window, then the app will take you back through its backups of iCloud Drive.

The main drawback of that is that items you restore will replace any existing items. You may also prefer to use the Finder’s or a command line interface to your backups, both of which allow you to copy restored items where you prefer. The difficulty here is that macOS deliberately hides the path to iCloud Drive: in your active Home folder, they’re located in ~/Library/iCloud Drive, but that path doesn’t work in Time Machine backups.

To access them in a backup, follow the Finder path
[backupname]/[backup].backup/Data/Users/[username]/Library/Mobile Documents/com~apple~CloudDocs/

From Terminal, you’ll have more of a struggle, but need to look for
/Volumes/.timemachine/[UUID]/[backup].backup/[backup].backup/Data/Users/[username]/Library/Mobile\ Documents/com\~apple\~CloudDocs/
where the path component [backup].backup is repeated. If you locate an item first in the Finder, you can always drag and drop that into the command line for it to automatically paste the correct path.

Summary

• Unless you manually exclude iCloud Drive from Time Machine backups, the contents of iCloud Drive will be backed up provided that items haven’t been evicted from local storage.
• If Optimise Mac Storage is turned off, the whole of iCloud Drive will be backed up by Time Machine, as eviction doesn’t occur.
• If Optimise Mac Storage is turned on, only those files and folders that are stored locally will be backed up by Time Machine. To ensure an item is backed up, manually download it before the backup is made.
• Restoring iCloud Drive items from a backup is simplest in the Time Machine app, but also available in the Finder, from a path equivalent to ~/Library/Mobile Documents/com~apple~CloudDocs/ in that backup.