10

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
  • And not a word about what is the disk you're backing up to itself? Is it completely separate disk drive? What filesystem is it using? – poige Nov 26 '19 at 5:34
  • @poige: I've been using this disk to backup on Mojave without issue; it's Seagate Backup+ 8tb, formatted HFS+ with Core Storage encryption enabled. The issue clearly isn't the disk or file-system, as Catalina will backup to it, it just won't inherit the existing (6tb of) backup history. – Haravikk Nov 26 '19 at 9:57
  • @klanomath: That's exactly the command I used (is there another way to do this?); it doesn't seem to matter though as associating a snapshot volume with a source volume doesn't do anything without being able to inherit the machine directory. That said, one of my volumes has been renamed, and tmutil associatedisk renamed the associated snapshot volume, so tmutil clearly recognises those as valid, it just won't accept the machine directory as such. – Haravikk Nov 26 '19 at 10:01
  • I had the same problem with my Lacie Rugged Disk. In my situation I didn't have any data on my disk and I was about to back up for the first time. After I got the Invalid target Error. I wasn't able to even access the drive. I solved this my plugin into a windows laptop and then formatting the drive. – Himsara Gallege Nov 26 '19 at 10:29
6
+500

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 & 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.

  • Thanks so much, this is really useful information! I've added xattr -l output for my machine directory to the original question, I don't see anything that looks amiss, the values all seem consistent with the old Mac-Mini that I temporarily used while waiting for my new machine. I haven't got another TM backup disk handy to compare against though. Except for the recovery set being misidentified as 0 (only folder in .RecoverySets was 1) which I've already corrected, but hasn't made a difference so far. – Haravikk Nov 26 '19 at 14:20
  • @Haravikk Your posted ext_attr reveals that the machine dir wasn't inherited successfully: After a successful inheritance I would have expected the ModelID to be Macmini8,1. You'd have to replace ModelID (and the other three IDs with the current values (of the new Mac mini) manually. Same with xattr -l /Volumes/Backup/Backups.backupdb/Haravikks\ Mac/[date]/Macintosh\ HD. Backup of all metadata (copy Terminal output and paste it in a text file) is required. – klanomath Nov 26 '19 at 14:35
  • No need, thanks to the information you gave I've managed to force the correct values into the extended attributes of my machine directory, and Time Machine is once again running backups! I'm going to award the full bounty, but to complete the answer would you be able to add a brief guide of how to insert the BackupMachineAddress, ModelID and HostUUID values, just for completeness sake? I could always edit these in myself if you prefer, or maybe it would be neater as a separate answer as one possible fix (your info being the starting point for others who may not have the exact same issue) – Haravikk Nov 26 '19 at 17:09
  • @Haravikk My answer was in parts speculative. I haven't expected that just force-updating BackupMachineAddress, ModelID and HostUUID in the extended attributes would be sufficient to "inherit" the backup disk. Aù contraire: I expected that the host's plist has to be edited and some attributes of the volumes inside Backups.backupdb/Haravikks\ Mac/[date]/. You may edit my answer if I missed something or something is unclear. – klanomath Nov 26 '19 at 17:57
  • Sorry, forgot to say but it actually seems the plist only refers to the destination (the entire backup volume) not any specific machine directory. Time Machine was happy to accept the disk as a destination, but when running a backup wasn't finding a machine directory with my machine UUID, so was creating a new one, which is what inheriting normally fixes. I think I'll give my solution as a separate answer as an example, but mark yours as correct, since it gives all the important information. – Haravikk Nov 26 '19 at 18:13
3

Building upon the information provided in @klanomath's answer, I was able to figure out a specific solution to my exact case (others may differ).

In my case the problem was the extended attributes attached to the machine directory, for some reason Time Machine didn't like them. However, after forcing the correct values in I was able to sort these out.

If you believe you're experiencing the same issue, the following steps should help you to resolve it. Before you begin you'll need some information, you can find all of these by going to Apple menu -> About This Mac and clicking System Report:

  • ModelID: The model of your Mac, found under Hardware, as Model Identifier, for example mine is Macmini8,1 for a 2018 Mac-Mini.
  • HostUUID: The unique identifier for your system, also under Hardware as Hardware UUID, the value resembles: 12345678-1234-1234-1234-1234567890abcd.
  • MachineAddress: This is your machine's MAC (network) address; under Network select your primary ethernet (en0). In this section you should see an entry for ARPResolvedHardwareAddress, your MAC address is the value that resembles 12:34:56:78:90:ab.

Now perform the following steps:

  1. Open Terminal.app
  2. Navigate into your backup volume (cd /Volumes/Backup/Backups.backupdb, substituting the path as appropriate).
  3. Get the current attributes for your machine directory with xattr -l "Haravikks Mac" (substitute in the correct name for your machine directory). Save these somewhere, in case you make a mistake.
  4. Elevate to root (this will make running the following commands a lot easier, but take care while doing so) using the command sudo su, you'll be asked for your password. If you're not running in an admin account, you can switch to one with su admin first (substitute the short name of your admin account).
  5. First let's set the model ID with: /System/Library/Extensions/TMSafetyNet.kext/Contents/Helpers/bypass xattr -w 'com.apple.backupd.ModelID' 'Macmini8,1' "Haravikks Mac" making sure to substitute your own model ID and machine directory name.
  6. Next, we'll set the machine address: /System/Library/Extensions/TMSafetyNet.kext/Contents/Helpers/bypass xattr -x -w 'com.apple.backupd.BackupMachineAddress' "$(printf '%s\0' '12:34:56:78:90:ab' | xxd -p)" "Haravikks Mac" again substitute your own values. Note the use of printf here, this is to ensure the value is null-terminated*.
  7. Finally, let's set the host UUID: /System/Library/Extensions/TMSafetyNet.kext/Contents/Helpers/bypass xattr -x -w 'com.apple.backupd.HostUUID' "$(printf '%s\0' '12345678-1234-1234-1234-1234567890abcd' | xxd -p)" "Haravikks Mac" swapping for your own values. Again we're using printf to terminate with a null character.
  8. If you already set the drive as a destination in Time Machine, you shouldn't need to do anything further. If not, add it now, if all went well you won't be asked to inherit (but if you are, accept, as it means you were close enough).
  9. If necessary, use tmutil associatedisk to relink volumes whose ID may have changed (if it's a new machine, or you erased a drive, then these will need to be associated).
  10. Run a backup to make sure everything is now working as expected.

NOTE: We're using the Time Machine bypass tool (in TMSafetyNet.kext) to avoid the extra security that normally prevents modification of Time Machine data. Be very careful about using this (don't use it to mess around with the contents of your backups).

NOTE 2: If you get the error "Operation not permitted" while running any of the commands, it means you need to go into System Preferences -> Security & Privacy, under the Privacy tab find Full Disk Access, and make sure to grant this to Terminal (tick it if it's there, or add it with the plus button). You'll need to quit and reopen Terminal after doing this, so make sure you remember where you were in the steps above.

NOTE 3: *It may not be necessary to null-terminate BackupMachineAddress and HostUUID, but that's how values supplied by Time Machine itself are structured, so for completeness' sake I'm keeping this behaviour.

While this is the correct answer for my specific case of "Invalid Target", from my searching it seems there are a bunch of similar, but not identical, cases so my answer may not help with all of them.

Klanomath's answer provided all the information I needed to figure out my own specific solution which is why I've marked it as the correct answer, hopefully it help others, and please feel free to add additional answers if you're able to solve similar issues that also give "Invalid Target" errors.

  • Great answer, this summarises the above answer well. Tip: putting a null byte in an arg using process substitution like that won't work in bash. You want to convert it to hex using xxd, then feed that to xattr -w -x. E.g.: xattr -x -w mykey "$(printf "%s\0" myval | xxd -p)" myfile – hraban Dec 23 '19 at 3:37
  • 1
    Huh, seems to be a bash specific quirk? Or at least zsh does not behave this way (null bytes are preserved). In any event, I've edited the affected commands, thanks for making me aware of this! – Haravikk Dec 24 '19 at 7:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .