I have a large RAID disk, and I want to make it into an even larger RAID disk. I know that Time Machine can “inherit” backups from one machine onto another, so that you don’t get two copies of every file in the backup. Is there any way to “inherit” a old disk onto a new one (potentially with the same name) so I don’t have duplicate backups? From my experience, I think the answer is, No; but I’d love to hear a contrary opinion (and evidence).
Perhaps the terminal command
tmutil associatedisk will do what you want, as described in this article; scroll down to:
Replacing a drive and continuing the same backup
Wow. Just what I wanted. Fingers crossed! I’m not upgrading the disk for a few weeks, but I’ll report back.
My new backup is underway, but I think I can safely say that Nello’s advice should work, but it doesn’t work.
First, Time Machine backups on macOS Extended volumes are very different than on APFS volumes, and the documentation for
tmutil was not fully updated for APFS. The recipe Nello cited was for macOS Extended, and the examples in the man page for
tmutil only show examples for macOS Extended backups.
macOS Extended Time Machine backups have a folder called
Backups.backupdb, while the layout of APFS Time Machine backups is completely opaque to me.
For instance, my backup disk, Curie, which is APFS, has 16 folders in it, with names like
% ls -d /Volumes/Curie/*.previous | wc -l
Inside each of these folders are folders with names of the volumes on my computer that were backed up. But, strangely, only two of the folders have entries for the volume that I copied. This volume is called “Choeropsis” and there are only two entries for it:
% ls -d /Volumes/Curie/*/Choeropsis
However, if you look in Finder, there are more than thirty incremental backups on Curie, every one has a backup for Choeropsis, and the dates don’t line up with the dates in the folder names shown in Terminal. (Some match, some do not).
After a bunch of dead ends, I figured out that the following commands should re-associate my new Choeropsis disk with the copy in the Time Machine backup. When I executed these commands, only the new copy of Choeropsis was mounted, and Time Machine was turned off.
% sudo tmutil associatedisk /Volumes/Choeropsis /Volumes/Curie/2023-11-27-174608.previous/Choeropsis
% sudo tmutil associatedisk /Volumes/Choeropsis /Volumes/Curie/2023-11-27-150743.previous/Choeropsis
at least, these two commands were accepted as if they were executed. (Also, FWIW, it appears that the
-a flag only causes an error message if you use it with APFS volumes, so don’t do that).
After executing the above commands, I turned Time Machine back on, and at first thought everything was copacetic. But then I realized that Time Machine had turned off backups for this new disk (Choeropsis was in the exclusion list).
I removed Choeropsis from the exclusion list, and a backup is underway. After 6 hours, it has backed up 1.6 TB of data, so clearly the disk association did not work. I’ll let it go for a while, but there isn’t enough room on the Time Machine volume for it to complete (the Time Machine volume is 24 TB, Choeropsis has 13 TB of data on it), so I’ll have to erase the Time Machine volume and start over.
Apple, if you were a youngster, we’d say you had so much promise. But now you just seem to pile cruft upon cruft, and not update the man pages!
A quick high-level summary:
TM over HFS+ (TMH), if I remember correctly, has a date-stamped folder for each backup with that
Backups.backupdb folder. Within each is a folder for each volume backed up. Within each of those is a per-file clone of all the backed-up data. Hard-links are used to avoid unnecessary duplication of data (so two files or folders that are identical on consecutive backups will actually be hard-links to a single copy of that file or folder).
TM over APFS (TMA) uses APFS snapshots instead. When accessed from command-line tools, you will see a date-stamped folder corresponding to the most recent backup. It will contain a folder for each backed-up volume. There will also be a
backup_manifest.plist, which contains metadata about every backup:
$ ls -l /Volumes/Time\ Machine
drwxr-xr-x@ 5 root wheel 160 Nov 29 11:45 2023-11-29-114638.previous
-rw-r--r--@ 1 root wheel 66053 Nov 29 11:46 backup_manifest.plist
$ ls -l /Volumes/Time\ Machine/2023-11-29-114638.previous
drwxr-xr-x@ 20 root wheel 640 Nov 29 11:46 Balrog - Data
% ls -l /Volumes/Time\ Machine/2023-11-29-114638.previous/Balrog\ -\ Data
drwxrwxr-x@ 65 root admin 2080 Nov 27 11:32 Applications
-rw-r--r--@ 1 root wheel 0 Nov 29 11:46 Icon?
drwxr-xr-x@ 74 root wheel 2368 Oct 25 17:34 Library
dr-xr-xr-x@ 2 root wheel 64 Oct 18 2020 Network
But from the command-line, you won’t see the historic backups, because they are all APFS snapshots. You can see them with the
diskutil command. First, use
diskutil list to show all your volumes:
$ diskutil list
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *4.0 TB disk2
1: EFI EFI 209.7 MB disk2s1
2: Apple_APFS Container disk3 4.0 TB disk2s2
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +4.0 TB disk3
Physical Store disk2s2
1: APFS Volume Time Machine 1.8 TB disk3s2
In the above example, my external TM disk is
/dev/disk2, and its APFS container (
/dev/disk2s2) is used to construct a synthetic
/dev/disk3. The TM volume within that synthetic disk is
With that, I can request the information about the TM volume with a
diskutil info command:
$ diskutil info disk3s2
Device Identifier: disk3s2
Mount Point: /Volumes/Time Machine
APFS Snapshots are defined upon this APFS Volume. Snapshot list:
Snapshot UUID: 9F990D84-5DB9-471F-805C-AF00A3F0BD61
Snapshot UUID: 48F3DD07-3FC6-4A47-931D-956A653D1F8B
As you can see, there is one APFS snapshot for every backup and each one has a name identifying the fact that it was created by Time Machine and has the date of the backup. You can mount the snapshots individually, if you like (e.g. for scripted access to backed-up content).
Using the Finder, however, this is all hidden. Instead of seeing the last-backup folder and a plist, it shows you a bunch of disk icons, one corresponding to each of the snapshots:
You can double-click any of these to mount the corresponding snapshot and examine the contents.
UPDATED: November 30, 2023 5:42 PM
tmutil associatedisk clearly did work since your new disk has been added to your existing Time Machine backup.
Perhaps you also have to run ~~
tmutil inheritbackup to make the new disk inherit the backups of the prior disk as described here
I’m know nothing about
tmutil but I have a keen interest in you being successful because I’m about to replace a failing internal HDD with an SSD (as described here) and would also like to:
- Continue using an existing Time Machine backup on an APFS external HDD; and
- Avoid duplicating (within the backup) the content of the failing HDD that I restore to the new SSD.
Unfortunately, this article seems to indicate that is is not possible for an APFS Time Machine backup of a new drive to inherit the (prior) backups of an older drive that it replaces.
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 [Time Machine backups made to APFS disks], 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.
Pay particular attention to the 9th comment and Howard Oakley’s reply in the 10:
You could have tried tmutil associatedisk -a mentioned here:
Managing Time Machine when you replace drives or computers | Creative Tech Support
Would be interesting to know if it works with TMA.
Thank you. Yes, I could, but I deliberately didn’t for several reasons. First, the user shouldn’t have to resort to tmutil for this type of routine procedure. In the past (before APFS) I’ve used volume renaming successfully with TMH. Second, has tmutil been updated to work this sort of trick with TMA? Its man page is still dated 2015, and I can’t see anything new in the current version, although there are several changes which you’d expect for TMA. Third, TMA had added the source to the exclusion list before it had even started the first backup after the disks had changed (there’s a five minute delay after boot). Fourth, TMA did make the association between the source and previous backups in this phantom additional ‘backup’, although it clearly didn’t make this strongly enough to continue to use that. Finally, I think the underlying problem here are the missing snapshots on the source volume, which of course can’t be copied when cloning a disk. Without those, TMA seems unable to back up to the current backup set.
It’s very complex, and doesn’t work ‘seamlessly’.
Frankly, if Howard says that it’s “very complex” then certainly it is beyond me.