A basic Mac system consists of the Mac itself and external storage for its backups, and is by far the most popular configuration. For many folk backing up the whole of its Data volume is wise, but that isn’t always the most economical. If the Data volume contains large items that don’t need to be backed up as often as its working folders, that can waste space. This article shows how you can make it more efficient without additional cost or hardware.

Backups and local snapshots

Most good backup utilities including Time Machine also make local snapshots of the volumes they back up. Let’s say your Data volume contains 100 GB of files that either change little or don’t need to be backed up as frequently as the rest. One proven strategy for minimising the time and storage required for backups is to add those to the exclusion list, and back them up separately, maybe only once a week. You can do that to another volume on external storage, provided you ensure there’s sufficient space for both that and your normal automatic backups.

What that doesn’t do is keep those 100 GB out of the frequent snapshots made of the Data volume. While you can exclude files and folders from backups, snapshots always include everything in that volume, without exclusions. The only way to save the space they add to snapshot size is to move them to another volume that doesn’t get snapshots made of it. But your Mac’s standard disk layout doesn’t provide any spare volume for that.

This could apply to all sorts of relatively static data that doesn’t need Time Machine’s automatic hourly backups, including Virtual Machines and some large media libraries, although you won’t then be able to share these in iCloud Drive, which would require them to be in your Data volume.

Boot disk layout

Standard layout of the internal SSD of an Apple silicon Mac running Sequoia or earlier is shown below.

Intel Macs have the same Apple APFS container with the Boot Volume Group in it, but the other two containers are replaced by a single small EFI partition.

Adding another partition or container is possible, but not recommended as it has a fixed size, and lacks the flexibility of a volume. It also risks disturbing the three existing partitions/containers. As they’re essential for the Mac to start up successfully, you don’t want to meddle with them.

In practice, the best place to add a new volume is inside the third container, the one already holding the System and Data volumes. Add that in Disk Utility once you’ve decided the next two steps.

Limit volume size

Your new volume is going to share space in its container with all the existing volumes, including both System and Data. It’s usually wise to impose a maximum limit on the size it can grow to, to avoid compromising any of those. When you add the new volume, put a sensible limit on its Quota Size.

Encryption

Although Apple’s documentation isn’t explicit, volumes added to the boot container aren’t protected by FileVault, unlike the Data volume. If you want your extra volume to be encrypted, you’ll have to format it in APFS (Encrypted). Whether that’s accelerated by the hardware in the Secure Enclave isn’t clear, and on Apple silicon Macs it’s hard to tell the difference, as you should get similar full speed performance from your extra volume to that of the Data volume.

Setting it up

Open Disk Utility, ensure its View options are set to Show All Devices, then select the Container holding the boot volumes. Click the + tool to add the new volume.

Give the volume a name, then click on the Size Options… button.

Enter your chosen Quota Size, as the maximum you want to allow the extra volume to use on the boot SSD, and click OK.

Then select whether you want it formatted in plain APFS, or encrypted, and click the Add button.

If you’ve opted for APFS (Encrypted) you’ll then be prompted to enter the encryption password. Unlike FileVault, there’s no option for a Recovery Key, or for iCloud Recovery.

When you first unlock the extra volume, you’ll be given the option to save its password to your keychain. That confirms this isn’t being performed by FileVault, as that protects its encryption keys in the Secure Enclave.

There are a couple of quirks:

• If you try unmounting the extra volume using the Finder’s contextual menu, macOS might try to unmount all volumes on the boot disk, and warn you that it can’t. Simply cancel those warnings, and the extra volume should unmount fine. If you’re worried by this, unmount the volume in Disk Utility, which isn’t as silly.
• You can use the Finder contextual menu to encrypt or decrypt the volume if you change your mind.

Summary

• To save space in local snapshots made for backups of your Data volume, move bulky items that you back up separately to an extra volume alongside the Data volume.
• Set a Quota Size on the extra volume to limit the maximum space it can take.
• Use plain APFS or APFS (Encrypted) as the extra volume can’t be protected by FileVault.
• If you encrypt the volume, safeguard its password as there’s no recovery option if you lose it.
• The extra volume performs as well as any other volume on the internal SSD, and is far faster than using external storage.

In case you missed it, Apple has just announced that a “future version of macOS” will no longer support AFP, Apple Filing Protocol. This is included in the Enterprise release notes for macOS 15.5 Sequoia. This article looks at how that could affect those using network backups and shares, to Time Capsules, NAS and other Macs running old versions of macOS.

Network storage requires network file-sharing protocols like AFP and SMB to perform file transactions using packets transmitted over the network. AFP is one of the oldest, and originated in AppleShare back in Classic Mac OS System 6, in 1988. Version 3.0 was introduced in Mac OS X Server 10.0.3 Cheetah in 2001, and the latest is 3.4, from OS X 10.8 Mountain Lion in 2012. Because of its early popularity in Macs, it has long been available in third-party implementations including the open source Netatalk, and those have been widely included in NAS system software.

In OS X 10.9 Mavericks, Apple made SMB (Server Message Block) its primary file-sharing protocol, and AFP has been in decline ever since. When APFS was introduced in High Sierra, it wasn’t supported by AFP and has required SMB, although Time Machine backups have continued to work over AFP through their use of sparse bundles. Earlier versions of SMB haven’t worked particularly well with macOS, but in recent years SMB version 3 has improved substantially, and should be supported by all recent NAS systems.

Greatest problems come with Apple’s old Time Capsules, most of which are still used with AFP, as they can only support SMB version 1, not versions 2 or 3. If you’re still using a Time Capsule, or an old NAS that doesn’t support SMB version 3, then access to your network storage may well still be reliant on AFP.

Not yet

Apple hasn’t announced when AFP will no longer be supported, and when it does, it won’t apply retrospectively. This makes it almost certain that Macs running macOS Sequoia will be able to continue using AFP if they are currently doing so.

Given the timing of this announcement, it seems most likely that AFP will be dropped from macOS 16, to be announced early next month at WWDC and released this coming autumn/fall. If your Mac can’t or won’t be upgraded to macOS 16, then it shouldn’t lose AFP.

Time Capsules

Apple discontinued its last Time Capsule model in April 2018, just over seven years ago. If yours is still using its original hard disk, then it’s living on borrowed time, and needs replacement sooner rather than later. If you have recently installed a new hard disk inside an old Time Capsule, then this might be a good time to rehouse that disk in a more modern NAS or other enclosure if you want to continue to use it.

I’m regularly asked to suggest a suitable replacement for Time Capsules, incorporating both their Wi-Fi base station and NAS features. Although there are some products that come close, you’re better off separating those two functions, and getting a good NAS with Mac and SMB 3 support, and a separate Wi-Fi base station or router with support for the latest standards.

NAS

For other NAS, first check whether you can update its system software to a current version. If you can, that should give it a new lease of life, and full support for your Mac to run SMB 3 to it. If it’s no longer supported, then this is the best time to consider replacing it, or even moving to backing up to local storage instead.

Macs are now well-supported by most NAS manufacturers, among which my favourite is Asustor, whose products I regularly test and review. Together with other established products from Synology and QNAP, you shouldn’t go far wrong.

Summary

• A future version of macOS will no longer support AFP, but it’s not being removed from current or past versions of macOS.
• AFP could well be dropped from macOS 16 due for release later this year.
• Time Capsules only support AFP and version 1 of SMB, so need to be replaced.
• Older NAS that can’t support SMB 3 should also be replaced.

Time Machine and other backup utilities don’t back up absolutely everything. The list of folders and files that don’t get saved in your Mac’s backups is long, and hidden away out of sight. For Time Machine that used to be in /System/Library/CoreServices/backupd.bundle/Contents/Resources/StdExclusions.plist but now in .exclusions.plist at the top level of any backup. This article explains the more important in that list, and others that could trip you up. I’ll consider these according to the categories in that file.

TM Backup Exclusions

apiExclusionPaths

These are added by individual third-party apps, by setting the isExcludedFromBackupKey URLResourceKey for that file every time it’s saved. Otherwise this category might be empty.

standardExclusionPaths

This is a long list of standard paths that are set by macOS as not for backup, including:

• .DocumentRevisions-V100 – the version database on each volume, added to this list in Big Sur,
• .Spotlight-V100 – Spotlight metadata including indexes, which will be regenerated after restoring a volume,
• .Trashes – the contents of all Trash folders,
• .fseventsd – the File System Events database,
• /Library/Logs – traditional text log files, not those for the Unified log which are included in backups,
• /Users/Guest – any guest user files,
• /private/var (partial) – various transient files,

among many other ephemeral items.

Of those, only one results in any significant loss of data, the version database. Although this was dutifully copied by Time Machine into backups for several years, the current structure of that database makes it impossible to restore successfully, even when restoring a complete volume. By the middle of the Catalina cycle, it had become a frequent cause of Time Machine choking, so was added to the standardExclusionPaths for Big Sur. As far as I’m aware this was never fixed in Catalina.

stickyExclusionPaths

These are items with an extended attribute of type com.apple.metadata:com_apple_backup_excludeItem attached, including various database and related files inside Photos Libraries. In the event that a library is restored from a backup, they’re freshly regenerated from the library’s contents.

Another interesting exclusion here is the Siri Analytics database included in any sysdiagnose stored in the volume(s) being backed up, in the path
sysdiagnose[datestamp]/logs/SiriAnalytics/SiriAnalytics.db. Presumably that’s for privacy reasons.

systemFilesExcluded

This key is set to true to ensure the whole System volume is always excluded.

userExclusionPaths

These are exclusions the user has set using tmutil or in Time Machine settings, using the Options… button.

By default, volumes on external storage are automatically added to this exclusion list; if you want an external volume to be backed up by Time Machine then you’ll need to remove it from the exclusion list manually.

iCloud Drive

When backing up the current Data volume, by default all files in iCloud Drive that are downloaded to that Mac at the time the backup is made, will be included in that backup. However, any that have been evicted (their download has been removed) will not be backed up, as their data isn’t present locally on the Mac, and that file is dataless. To ensure that those are backed up, download them all prior to the backup starting, and ‘pin’ those you want to remain downloaded in future.

Local snapshots and backups

Any snapshots of a volume aren’t backed up, indeed they can’t be copied to another volume. The same applies to Time Machine backups.

Local snapshot exclusions

All items in the volume at the time a local snapshot is made are included in that snapshot. There are no exclusions from local snapshots, apart possibly from some obscure items internal to APFS.

Third-party backups

Mike Bombich gives a thorough and detailed account of what CCC doesn’t copy on this page. Other backup utilities should also provide full lists on their support site.

Replicated or ‘cloned’ volumes

These should also include the entire contents of the volume as if a snapshot.

In my introduction to the macOS document versioning system, I explained that a document could lose all its saved versions when moved to another volume. This sequel provides more detail about how you can preserve or lose those saved versions.

When you save the first version of a document, a record is created in the hidden database on the same volume as that containing that document. That record refers to the file not by its name or path, but by its inode, its unique file system number. Anything that preserves that inode number will thus tend to keep its saved versions; anything that creates a new file with its different inode number is guaranteed to lose all versions.

What’s safe

The following actions are version-safe:

• moving the file anywhere within the same volume;
• renaming the file, changing its permissions, adding extended attributes, adding a custom icon, or editing the file’s data;
• creating a Finder Alias or symbolic link to the file;
• rolling back a local snapshot, which will return the versions to the same state as at the moment that snapshot was made; volume snapshots include the whole version database, and preserve inode numbers;
• ‘cloning’ the whole volume to make an identical copy of everything in it;
• if the file is stored inside a disk image, then that disk image can be copied or moved safely, or backed up; that also applies to files stored inside Virtual Machines.

What loses versions

The following actions are destructive of versions:

• moving the file to a different volume; the original file on its original volume will retain its versions, but they won’t copy across to the new volume;
• duplicating the file; the duplicate, an APFS clone file, will have no versions at all;
• saving the file as a new file, with a Save As command;
• compressing or archiving the file; the copy in the archive won’t have any versions;
• saving the file to a file system like ExFAT or MS-DOS, which don’t support versions;
• backing the file up to another volume, as versions can’t even be backed up by Time Machine;
• moving or copying the file over a network.

If you try to save versions on a file system that doesn’t support them, you aren’t warned when saving those versions, as those appear to remain cached. Normally the first warning is given when you try to close the file.

If you want to keep versions, click on Cancel and save that file to a volume that does support versions.

The version database can only be created on a volume that has sufficient space to support it. This doesn’t normally affect working with regular APFS volumes, but can be a problem if you’re intending to store the file in a disk image or sparse bundle. You should find that a minimum size of 1 GB will support limited versions, but 500 MB is definitely too small for support, and will result in a warning when you try to close the file.

iCloud Drive

The behaviour of versions in iCloud Drive might appear confusing unless you remember the rule that they are saved for that file’s inode number. Here I’ll look at the example of a file that’s in a different folder from iCloud Drive (or Documents in iCloud) and is moved to iCloud Drive.

If that file is already in the current Data volume, that’s the same volume as local copies of what’s in iCloud Drive, so moving it to iCloud Drive keeps it within the same volume, and versions are preserved. If that file is evicted from local storage, that only removes the data for that file, and doesn’t change its inode number. When the file is downloaded again and opened, its versions are still there.

On another Mac connected to the same iCloud Drive, though, the versions are on a different volume on another Mac, so if that opens the file, there are no saved versions available. If that Mac adds its own versions to the file, they will be saved locally, and will be accessible to that Mac.

Saving versions to files already in iCloud Drive is more complex, as different versions of macOS, iOS and iPadOS have saved some into iCloud, so I will look at that in a separate article.

Preserving versions whatever

The only way that I know to preserve all the versions of any file is to save each of them individually in a folder, numbered so that the original versions can be recreated on another volume. While you can use my utility Revisionist to do that, a simpler drag-and-drop approach is provided by Versatility.

There’s no screenshot to show: all you do is drag a file with versions onto Versatility’s blue landing pad. You’ll then be prompted to name and locate the folder it creates containing the file’s versions. Once made, you can move them around like any other Mac folder, back them up, Zip the folder and send it to a colleague.

To reconstitute the original, simply drop the folder onto Versatility’s pad. You’ll then be prompted for the name and location of the file to be saved. That file will contain all the versions saved in the original, ready to use.

If you wish, you can edit the versions in the archive folder created by Versatility. When the file is reconstituted the individual versions will simply be reassembled in numerical order.

I’m also delighted to confirm that both Versatility and Revisionist are fully compatible with macOS Sequoia.

Key point

Versions are linked to the inode number of their file. Actions that preserve that on the same volume should retain those versions. Anything that creates a new inode number or uses a different volume won’t retain those versions.

APFS has two special file types designed to economise on storage space: clone and sparse files. Clone files are two or more distinct files within the same volume whose data is shared; sparse files save space by skipping empty data and only storing data containing information. This article explores how they behave in use, with particular emphasis on Time Machine backups and iCloud Drive. The latter also involves a third type of special file, dataless files.

Clone files

In contrast to hard-linked files, clone files are two or more distinct files within the same file system (volume) whose file extents are identical, so share the same data, as shown below. They’re created by variants of normal file copying, including duplicating in the Finder (and drag-copying within the same volume), and the cp -c command.

Instead of duplicating everything, only the inode and its attributes (blue and pink) are duplicated, together with their file extent information. You can verify this by inspecting the numbers of those inodes, as they’re different, and information in the attributes such as the file’s name will also be different. There’s a flag in the file’s attributes to indicate that cloning has taken place. At first, the two cloned files share the same data blocks and extended attributes, but as the two files are changed by editing, they start to drift apart and become uncloned.

Clone files are becoming more popular thanks to the Hyperspace app, which deduplicates files within the same volume by replacing copies with clones.

Because they can only exist within the same file system, clone files are fragile. Any copy or move to another file system is invariably accompanied by the copying of their full data, and their economy of storage can only remain as long as they stay within the same volume.

Backups

One notable exception to this same-volume rule is in Time Machine backups. As clone files are preserved in local snapshots, when Time Machine constructs a backup as a snapshot in the backup storage volume, shared file extents are retained, so preserving clones. This is reflected in the size of the backup snapshot, and in the report written to the log. For example, when backing up three distinct files and ten clones of one of those, that report included:
14 Total Items in Backup (l: 16 GB p: 11.02 GB)
3 Files Copied (l: 6 GB p: 1.02 GB)
1 Directories Copied (l: Zero KB p: Zero KB)
10 Files Cloned (l: 10 GB p: 10 GB)

Backups made by other utilities are unlikely to reproduce this behaviour, though, as they can’t synthesise snapshots in the way that Time Machine does. To preserve clone files in their backups, they’d have to identify clones in the source and explicitly perform cloning in their backup store. Although Carbon Copy Cloner claims that “in some cases CCC may clone a file on the destination prior to updating its contents”, it doesn’t appear to attempt to preserve clone files in the backups it makes. I’m not aware of any third-party utility that does.

Unfortunately, Time Machine appears unable to restore directly from backup snapshots in the backup store, and performs Finder copies when restoring. That saves each of those clone files as a completely separate file, without any sharing of data. As a result, the space occupied on disk for a restored volume can be substantially greater than the original or its backup. Extensive use of clone files could thus cause problems when restoring from backups.

Of course, rolling a volume back to a local snapshot, such as one made during Time Machine backups, preserves all clone files within that volume.

iCloud Drive

Clone files created within the same volume as local iCloud Drive storage on the Data volume, or cloned when within a folder in iCloud Drive, remain within the same file system and clones are therefore preserved, and when the file is moved to other folders in the same volume.

However, clone files are treated as simple copies as far as iCloud Drive’s remote storage is concerned. While a pair of cloned 5 GB files only use a total of 5 GB local storage, they require a full 10 GB of your iCloud allocation, indicating that their cloud storage is separate and not common to both. Although the effects of eviction (removing local data) and materialisation (restoring local data from cloud storage) are difficult to observe directly, they appear to lose the benefits of cloning.

When the local copy of a file also stored remotely in the cloud is evicted, its data is removed from local storage, rendering it dataless, as shown below.

When that file is to be used locally again, its data has to be downloaded from the cloud service, and the local dataless file is materialised by adding its data back. As far as I can tell, that doesn’t result in the reconstruction of the shared file extents, so changes cloned files into normal copies with different file extents. You would then need to use Hyperspace to restore them as clone files. Other Macs sharing the same iCloud Drive also see them as full copies rather than clones.

These behaviours could also catch the user by surprise.

Sparse files

Unlike clone files, the structure of sparse files in APFS is conventional, as shown below.

They achieve their economy in storage by only including file extents containing non-null data, and thus aren’t dependent on remaining within the same file system (volume), making them more robust. Their primary requirement is that they’re created and maintained using specific file system operations, and are only copied or moved to other APFS file systems.

Backups

When backed up by Time Machine to another APFS volume, sparse files are preserved reliably, and are also restored as sparse files. That isn’t likely to hold, though, if the file is transferred using a network file system such as SMB, as all network transfers currently appear to explode sparse files to full size prior to transfer. Because of the way in which they have to be created, only the app maintaining that file could restore its sparse format. In the case of disk images, this should normally occur the next time they’re mounted in the Finder and Trimmed by APFS.

iCloud Drive

Assessing what happens with sparse files in iCloud Drive is considerably simpler than with clone files. As long as they remain downloaded to local storage, they are preserved, and can be moved in and out of iCloud Drive storage without exploding in size. However, they too are stored in full when in iCloud storage, requiring their full size in your iCloud allocation, and the eviction-materialisation cycle explodes them to full size, and their sparse file flag is removed.

The only way to return a former sparse file to its original economical format is then to open and save it using the app that creates and maintains it. In the case of disk images, this should occur when they’re next mounted and Trimmed.

Conclusions

Clone files:

• are only preserved when moved within the same file system (volume);
• are preserved and restored from local snapshots;
• are preserved in Time Machine backups, but aren’t restored from them;
• aren’t preserved in other backups;
• could result in a restored volume being substantially larger than its original;
• occupy their full space in your iCloud allocation;
• are only preserved in iCloud Drive when they aren’t evicted from local storage;
• can be regenerated using Hyperspace.

Sparse files:

• are only preserved when copied or moved directly between APFS volumes;
• aren’t preserved when copied or moved over network connections, or using SMB;
• aren’t preserved when copied or moved to different file systems, including HFS+;
• are preserved in and restored from local Time Machine backups;
• should be preserved in and restored from other local backups;
• occupy their full space in your iCloud allocation;
• are only preserved in iCloud Drive when they aren’t evicted from local storage;
• can only be regenerated by the app that creates and maintains them.

Both clone and sparse files can result in substantial savings in storage space. However, because that’s fragile, their greatest value is in minimising erase-write cycles in SSDs, hence slowing their ageing.

References

Apple’s APFS Reference (PDF), last revised 22 June 2020.
Dataless files are explained here.
How sparse files work
Files and clones
Special file types, including dataless files