In the previous article in this series, I looked at the problems which can arise in Time Machine (TM) backups, and how you can try to diagnose and address them. Although I promised to turn to network backups next, this article considers a topic of more general importance: what happens when your backups change in Catalina, using the specific example of migrating them to a new Mac.

As I described in the first article in this series, TM has become considerably more complex in Catalina, and now uses different strategies for determining what it should back up. It also has to cope with migrating its backups from previous versions of macOS and from other machines, and has complex behaviours to address those. Many users have reported that migration doesn’t work right, or results in strange backups. The example I use here gives insight into what might be going on, thus diagnosis and fixing of migration problems more generally.

When you have existing TM backups and replace your Mac, you have three choices as to how to proceed:

• put your old backups into archive, and start fresh backups on different storage,
• leave your old backups as they are, and start a new backup series in the same backup folder,
• inherit your old backups so that your new backups continue from where they left off.

If you choose the first in Catalina, your new backups will start with a full first backup of each volume. The second will also result in full first backups in a new machine directory. The third, inheriting your existing backups, is by far the most complex and distinctive, which could leave you supposing that the whole process went wrong. So that is what this article examines.

Once the first inheriting backup has been made, don’t look inside your backup folder unless you’re sitting down, as what you see may cause alarm. Instead of the normal three volume backups of Macintosh HD, Macintosh HD - Data and Recovery, you should see no less than six, with a set of what appear to be duplicates with the number 1 appended to their names. How Catalina gets there is a little different from a regular automatic backup.

That first interited backup starts with confirmation of your choice in the log. In this case, I’m migrating between two MacBook Pros, which happen to have identical machine names:
User chose to inherit backup at path: /Volumes/ExternalSSD2/Backups.backupdb/Howard’s MacBook Pro
Inherited machine directory: /Volumes/ExternalSSD2/Backups.backupdb/Howard’s MacBook Pro

TM has a much better way of telling the old from the new, because it uses UUIDs instead of machine names. It then works through each of the existing (inherited) backups in turn, recording their inheritance one by one with a succession of log entries like
Volume store '/Volumes/ExternalSSD2/Backups.backupdb/Howard’s MacBook Pro/2019-11-11-125737/Macintosh HD - Data' (originally for volume UUID A86D5F30-2372-44D6-BA86-E92B079DDF56) has been inherited by volume UUID A170B5D8-7895-423E-94C3-3D161CB4D4B6)

It then notes that the Data volume needs special treatment here:
Inheritance scan is required for '/System/Volumes/Data' (current volume UUID A170B5D8-7895-423E-94C3-3D161CB4D4B6, previous volume UUID A86D5F30-2372-44D6-BA86-E92B079DDF56

As is normal at this stage in a scheduled backup, TM next takes snapshots of the System and Data volumes, declares them to be ‘stable’, and mounts them both. It then encounters problems peculiar to this first inherited backup: it can’t mount the previous ‘reference’ snapshots for the current volumes (as they have different UUIDs, etc.), and can’t find event markers for those volumes either. In the next Event Collection phase, in which TM works out what it needs to back up from each volume, it decides to perform ‘first backups’ for Recovery and Macintosh HD, the System volume.

When TM then examines Macintosh HD - Data, it realises that the UUIDs for their FSEvent databases are different, so it requires a consistency scan to be performed to determine all differences since that last inherited backup, and records that in the log thus:
Running consistency scan - looking for changes after 2019-12-06 22:21:42 +0000
the datestamp here being that of the last inherited backup.

The Event Collection phase is now complete, with three .eventdb files generated, one for each of the volumes to be backed up. Those were created using different strategies: for the System and Recovery volumes they’re simple first backups which contain a complete replica of the volume being backed up. That for the Data volume writes out all the changed files since the last of the inherited backups, as determined by the consistency scan.

TM then enters its Sizing phase, and uses those three .eventdb files to determine the total sizes to be backed up. In this case, the total space required was nearly 45 GB. That’s followed by the Spotlight Inhibitor phase, which doesn’t occur in normal automatic backups, and inhibits Spotlight indexing for certain items. At the same time, TM starts copying the items detailed in the .eventdb files to the new backup, and generating all the hard links for items which haven’t changed since the previous backup.

When copying of items to be backed up is complete, TM unmounts the local snapshots, marks the new snapshots as ‘reference’, just as it normally does, and performs its routine backup thinning. The total time taken to perform this first inherited back up, to a largely empty local SATA SSD over USB-C (USB 3.1 gen 2), was 51 minutes, an average of slightly less than 1 GB per minute. TM’s sequence is marked with the final log entry of
Backup completed successfully.

What we’re provided with in this new backup consists of those three fresh backups, named according to the volume names, here Macintosh HD for the System volume, Macintosh HD - Data for the Data volume, and Recovery for the Recovery volume. In addition to those are directory hard links to the last inherited backup from the old machine, named just the same but with a 1 appended to the volume name. Being hard links, they look just the same as the original backup, but when you check the UUID used to name the folder, you’ll see that it’s the old machine’s UUID, and different from that in the fresh backups.

After the next backup, one of those six drops out, that for the inherited Data volume backup, but the others are retained, at least for the time being.

Using the log entries from this and other recent backups, I can now provide a fuller picture of the mechanism of TM backing up in Catalina 10.15.2:

The lessons which I’ve learned here include:

• When TM inherits backups, it may generate additional volumes in its backups.
• Some of those additional volumes are just directory hard links, so effectively occupy no space on the backup storage.
• Handling inherited volumes in this way can lead to very long backup times, even when the size of the backups is relatively small, and the storage medium relatively high speed.
• Migrating an old backup set to Catalina could readily take a very long time.
• The best plan when upgrading from an earlier version of macOS to Catalina is probably not to inherit your old backups, but to start with a fresh backup set.
• Inheriting a backup set from a previous Mac running Catalina to a new Mac can also take a very long time for the first backup, but may actually prove a good choice.
• Time Machine in Catalina works in ways which may appear mysterious, but it’s actually much smarter than might appear. Give it time.

This being the first time that I have observed a consistency scan being made in Catalina, I have been able to improve detection and reporting of backing up in Catalina in my free utility T2M2.

T2M2 version 1.10 is now available from here: t2m210
from Downloads above, from its Product Page, and through its auto-update mechanism.