hoakley Macs, Technology

APFS changes in Big Sur: how Time Machine backs up to APFS, and more

Despite extensive coverage of much of Big Sur and Apple Silicon, one session was missing from WWDC, that detailing changes in APFS for macOS 11. This article can’t be as authoritative, but I’ll try here to outline some of the improvements which are documented in various sources, including the latest update to the APFS reference documentation.

APFS in macOS 11 changes volume roles substantially. The System volume within a boot Volume Group is now sealed using a tree of cryptographic hashes, as I have detailed here. New roles include:

  • Update, used by macOS updates;
  • Xart, used by iOS to manage OS access to secure user data;
  • Hardware, used for firmware data;
  • Backup, used to store Time Machine backups to APFS, as explained below;
  • Enterprise, used for storage of enterprise-managed data;
  • Prelogin, which lets the system boot to the login screen ready to mount encrypted volumes.

APFS doesn’t give access to cryptographic hashes on sealed System volumes, and the process of sealing is only available to System volumes in a Volume Group. This means that, for the time being at least, sealing isn’t available to verify the integrity of files or the file system anywhere else, such as on the Data volume.

It’s not clear when Update, Hardware, Enterprise or Prelogin volumes will come into use, and some may only be available to Apple Silicon Macs, particularly as they won’t be using EFI/UEFI.

Time Machine and APFS

As 9to5Mac has already reported, Big Sur is the first version of macOS which can make Time Machine backups to APFS volumes without using a virtual HFS+ file system on a sparse bundle. However, to do so requires the destination APFS volume to be assigned the role of Backup, and allocation of storage space as a Physical Store.

Currently, when backing up to HFS+, Time Machine creates a folder within which is a replica of the file system of the volume being backed up. Files and folders which haven’t changed since the last backup are represented there by hard links: inspect the inode number of two corresponding ‘copies’ of a folder which hasn’t changed between backups, and you’ll see that they are one and the same, with identical inodes, just as regular file hard links are.

APFS doesn’t support directory hard links, so can’t use the same mechanism when storing Time Machine backups. Instead, what appears to function as a form of virtual file system is created using new features in APFS. The volume assigned the role of Backup appears to be a regular APFS volume, and is protected from normal access, even by root. File data is kept as usual in the container’s Physical Store, to which file data is copied during each backup. Apple hasn’t indicated whether this continues to be whole files, or whether only changed data are copied.

This is synthesised into what is presented by the Finder as the customary hierarchy of files and folders, just as with HFS+ backups. However, matching unchanged folders have different volume numbers, as if they were stored on separate mounted volumes. Their own inode numbers and attributes are identical, though.

Because Time Machine can only back up to HFS+ volumes (as before), or to APFS volumes with a Backup role, this means that you can’t, for example, store backups on your Data volume, or any other Data volume in a Volume Group. Current volume structure is such that APFS backup volumes are inevitably going to be external non-bootable storage, although it may be possible to divide disks into multiple containers to allow both backup and other purposes. Backup volumes are also not backward-compatible with Catalina.

Per-file encryption

Those who still recall the original aims of APFS will remember that among them was finer-grained encryption than is currently available, supporting the encryption of individual files using their own keys. Unfortunately, although this is coming at last in Big Sur, it will only be available on Apple Silicon Macs, and Apple hasn’t provided any information as to whether this will ever be available on Intel models.

To accomplish this, each file has its own metadata defining a Protection Class, which determines when a file can be opened, read or altered. This class is intended to be controlled by apps, as they already are in iOS and iPadOS, which can thus control access to those protected files. Full details are in the developer documentation.

If you come across any other significant changes in APFS in Big Sur, please let me know.