Reading view

There are new articles available, click to refresh the page.

Save space on the internal SSD by adding another volume

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.

BootDiskStructureMSeq

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.

Check your network backups and shares, as AFP is being removed

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.

What isn’t backed up?

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.

xclusions1

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.

Versions in motion: how to preserve document versions

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.

❌