Time Machine to APFS: Changing disks

With the exception of internal storage, disks involved in Time Machine backups are likely to change. Some fail, others become full, or we may simply reconfigure our system. These are changes which Time Machine needs to cope with, just as other backup utilities do. In the last few days, I’ve been looking at different scenarios involving disks changing, and what happens to Time Machine backups made to APFS disks (TMA).

Changing the source

My Home folder effectively sprawls across two disks: the Data volume on my internal storage, and a folder on an external SSD. Apart from settings in Photos and a Finder alias, there’s no formal connection from the external SSD to my Home folder, but plenty of apps rely on its path. I needed to upgrade that external SSD from 1 to 2 TB, so prepared a new disk with the name External3 to replace External1. I then shut down, swapped the external disks, started up and quickly changed the volume name of External3 to External1.

My backup scripts in ChronoSync and Carbon Copy Cloner needed the volume name to be refreshed, which I quickly accomplished. Time Machine wasn’t so easily fooled, though. Its first backup was abandoned, because it had apparently added External1 to its exclusion list. The reason for that isn’t clear, but log entries reveal confusion:
19:59:13.619 Backing up to ThunderBay2 (/dev/disk7s2,6): /Volumes/ThunderBay2
19:59:13.620 Found matching machine store '/Volumes/ThunderBay2' for computer named 'Howard’s iMac Pro', no machine store inheritance needed
19:59:13.703 Backup failed (25: BACKUP_FAILED_NO_SOURCE_VOLUMES - No source volumes were found to back up.)

I then removed External1 from the exclusion list, and TMA decided that was a prompt for it to automatically perform a manual backup of External1 as if it had never seen that volume before. It therefore started a new backup set for the volume named External1, and promptly backed up nearly 700,000 files totalling 530 GB to it. It also decided to continue the previous backup set under the volume name of “External1 1”, but without adding any new data to it. This left Time Machine backups in a strange state which clearly was far from desirable.

Attempts to bring this back into line were unsuccessful. Although the Time Machine app and the Finder provided access to all backups reaching back to the first TMA backup of that volume, over half a terabyte of free space on the backup store had been wasted doing so. Furthermore, it wasn’t possible to reformat the backup store, as the volume couldn’t be unmounted by Disk Utility. Here, Disk Utility’s longstanding problems with unmounting APFS volumes, containers and disks caused repeated failures which only made the situation worse. Eventually, when the volume had been forcibly unmounted in the Finder, TMA was still unable to use it as a new backup store because the source volume still had TM snapshots, which it had made in previous double backups.

If you end up in a similar situation, simply formatting the backup store isn’t sufficient to allow TMA to create a fresh backup set and start again from scratch. You have to delete the old backup store from the volume list in the TM pane, manually delete all TM snapshots on the source volume, format the backup disk, and then try adding it as a new backup store for TMA. The current illusion created by TMA is impressive, but also creates many problems when you try changing the source disk. In practice, the only solution is to format the backup store and start completely fresh backups.

Changing the backup store

We have already debated this scenario to death. Because there’s currently no way to copy the snapshots that Time Machine relies on, except by low-level disk duplication, there’s no way to transfer existing TMA backups to a fresh disk. If you therefore back up to a single store, or use multiple rotating backups, you can’t retain their existing backups as the basis for additions.

Currently, the only practical solution here is to set aside your existing backups as an archive, and start a new backup set on the replacement backup store. This is a major disadvantage to TMA, as TM backups to HFS+ can be copied to a fresh disk, allowing you to increase the size of the store and continue to back up to the same set.

TMA needs more work

As it stands in Big Sur 11.2.3, Time Machine backing up to APFS volumes appears impressive. It overcomes the many problems which had accumulated in its Catalina version backing up to HFS+. In particular, speed, space efficiency, and improved robustness of the backup store are major improvements.

However, Time Machine is far from complete. Attention now needs to be devoted to addressing the problems identified here with changing source and destination volumes. It isn’t acceptable to have to start completely fresh backups whenever a disk needs to be changed, and Apple needs to document the processes required to inherit source and destination disks, without driving users to experiment with tmutil.

For all its ingenuity and sophisticated engineering, of the three backup utilities which I use, Time Machine is by far the most complex, and the only one which makes changes like these so difficult.