Inheriting Time Machine Backup: Invalid Target So I got myself a shiny new Mac Mini, finally got everything transferred over from my old machine, and want to resume backing up using my existing Time Machine disk and backup history (as I've basically transplanted the dead old machine to the new one).

However I just can't get Time Machine to inherit the backup.

Every time I've done this in the past, I would simply choose the volume as a backup disk, and Time Machine would automatically ask me if I wanted to inherit the backup, but it's not doing this this time.

So I tried running the following command instead:

sudo tmutil inheritbackup /Volumes/Backup/Backups.backupdb/Haravikks\ Mac


But I get the following error:

sudo tmutil inheritbackup /Volumes/Backup/Backups.backupdb/Haravikks\ Mac
Usage: tmutil inheritbackup machine_directory
       tmutil inheritbackup sparse_bundle
/Volumes/Backup/Backups.backupdb/Haravikks Mac: Invalid target


The older system was running Mojave, while the new one is Catalina.

I've tried associating all of my disks instead (using tmutil associatedisk /path/to/volume /path/to/snapshot_volume, but if I begin a backup, Time Machine is still determined to start fresh (which I don't have space for) and creates a new machine directory (Haravikks Mac 2), even though the machine name of my new computer is identical.

I've also already given Terminal full disk access (because it's basically useless otherwise, thanks Apple) as that's usually the culprit for other mysterious invalid operations, but tmutil inheritbackup still won't take.

Is there any way that I can find out why Time Machine/tmutil consider my old machine directory invalid? There's nothing in the logs, and tmutil doesn't appear to have a flag for giving more verbose output (unless I've missed it?).

Failing that, is there some way can I force Time Machine to inherit a machine directory?

Update: In case it helps any, I've been noticing a lot of Spotlight related (mdworker) activity on the disk, strange since nothing is being added to it. Could this be related? Again, this didn't happen under Mojave (the disk would sleep between backups).

Update 2: Thanks so much to klanomath for an explanation of where else Time Machine stores data, here's the xattr -l listing for my machine directory:

xattr -l /Volumes/Backup/Backups.backupdb/Haravikks\ Mac
LastModTime: 1574418303756056852
com.apple.backupd.BackupMachineAddress:
00000000  63 38 3A 62 63 3A 63 38 3A 61 33 3A 33 33 3A 31  |c8:bc:c8:a3:33:1|
00000010  31 00                                            |1.|
00000012
com.apple.backupd.HasRecoverySet: YES
com.apple.backupd.HostUUID:
00000000  39 31 31 42 33 43 37 46 2D 35 42 36 36 2D 35 39  |911B3C7F-5B66-59|
00000010  45 30 2D 39 36 41 43 2D 39 31 42 37 35 38 38 43  |E0-96AC-91B7588C|
00000020  44 43 38 46 00                                   |DC8F.|
00000025
com.apple.backupd.ModelID: Macmini4,1
com.apple.backupd.RecoverySetName: 0
All relevant UUIDs and other Time Machine metadata are stored in /Library/Preferences/com.apple.TimeMachine.plist on the host side (the Mac to be backed up)! The file contains (probably the old) hostUUID (hardware), destination volume UUID (backup volume) and all IncludedVolumeUUIDs (source volumes). To get your current volume IDs use diskutil info diskXsY and the volumeID of the vanished Mojave volume is in the plist. The new hostUUID (hardware) and MAC are available in System Infomation.app > Hardware and Hardware > Ethernet-cards.

The com.apple.TimeMachine.plist may be populated with new UUIDs partly, you also have to grab the old com.apple.TimeMachine.plist from the backup.

All relevant Time Machine metadata on the side of the destination disk (the backup volume) are stored as extended attributes attached to the machine folder and subsequent snapshots and the included volumes:

machine folder

Example:

xattr -l /Volumes/Backup/Backups.backupdb/Haravikks\ Mac


and the volume folder(s) (in the latest backup of the old Mac). 

Example:

xattr -l /Volumes/Backup/Backups.backupdb/Haravikks\ Mac/2019-10-19-125832/Macintosh\ HD


(This is a lot of back &amp; forth. Best is to collect all data in some data sheet. Then it's easier to compare all plist entries/extended attributes and extract the proper ones)

After associating and inheriting a machine directory I expect various UUIDs and other data to be equal in the plist and the extended attributes on the one hand and the hardware/disk info of the new Mac on the other hand.

This is: BackupMachineAddress, HostUUID, ModelID and RecoveryPartitionVolumeUUID (
if available) on the host folder and various UUIDs in the plist.



If tmutil initiated inheritance fails, one has to use enforced adoption (or marry rich and get a larger backup drive):

To modify the extended attributs you have to read out (to reapply them later) and remove the ACLs of Backups.backupdb and Backups.backupdb/Haravikks\ Mac because both folders are heavily protected. Then apply new extended attributes (partly extracted from the plist and the new hardware info) and reinstate the ACLs you removed previously.

To get the ACLs use ls -le [folder1|2]. To remove the ACLs use sudo chmod -N [folder1] [folder2]. To apply new extended attributes use sudo xattr -w [ext_attr] [value] [/path/to/folder].

Examples:

If you found a ModelID Macmini4,1 in the extended attributes of /Volumes/Backup/Backups.backupdb/Haravikks\ Mac but the ModelID of the new Mac is Macmini8,1 you would have to update it like this:

sudo xattr -w com.apple.backupd.ModelID Macmini8,1 /Volumes/Backup/Backups.backupdb/Haravikks\ Mac


To update BackupMachineAddress (a MAC address of the new Mac) and HostUUID (the Hardware-UUID of the new Mac) use:

sudo xattr -w com.apple.backupd.BackupMachineAddress ac:87:b5:ca:c4:7a /Volumes/Backup/Backups.backupdb/Haravikks\ Mac
sudo xattr -w com.apple.backupd.HostUUID A7D80431-E567-389A-CC33-8321E461D431 /Volumes/Backup/Backups.backupdb/Haravikks\ Mac


To restore the ACLs use sudo chmod +a 'group:everyone deny ... writeextattr,chown' [folder1] [folder2]

Afterwards unmount the backup volume. Mount the backup volume again, open the Time Machine PrefPane and wait until the window is populated with the proper dest volume(s).



If you post all relevant data (which is a lot and somehow private) I could work out all commands properly.



This is untested and some "joy of experimentation" is required but it should work finally - somehow (|⚒)! At least it sheds some light on the files and attributes Time Machine uses to determine the validity of backup machine directories and what to change to re-establish assignments.