Using “tmutil associatedisk” With APFS Destinations
I recently got a new SSD on Prime Day to replace one of my main hard drives. As this drive was included in Time Machine, I wanted the SSD to “adopt” the hard drive’s backup history. This way I could avoid recopying lots of data that was already backed up, which would also require pruning older snapshots.
When you get a new Mac and want to adopt the old Time Machine backup, you want tmutil inheritbackup
. When you keep the same Mac but get a new source drive, you want tmutil associatedisk
.
The command is documented as:
tmutil associatedisk [-a] mount_point snapshot_volume
The -a tells it to find all the snapshots for that volume on the destination, not just the specific one that you pointed it to.
mount_point is just the source volume’s path (in /Volumes, not the device path).
snapshot_volume is the destination within your Time Machine backup. The example shows this as being within the Backups.backupdb folder, but there’s no such folder when using an APFS destination. My first thought was to drag the latest snapshot from Finder into Terminal:
sudo tmutil associatedisk -a /Volumes/Aux /Volumes/.timemachine/C2E8322E-A7EA-44F8-904F-3232671E1412/2025-07-11-091237.backup/2025-07-11-091237.backup/Aux
This does not work. Instead, you need to find the path using Terminal:
sudo tmutil associatedisk /Volumes/Aux /Volumes/TM\ 7/2025-07-11-091237.previous/Aux
It’s important not to have any trailing slashes. And, also, it will fail if you use -a
with an APFS destination. But I guess that’s OK because there’s only one .previous
folder to point it at, anyway, and APFS itself should know the chain of parent snapshots…
Previously:
Update (2025-07-15): associatedisk
worked with one of my drives. However, with another one, it didn’t. I first thought it was working because the amount of data copied and the estimated percent remaining looked right, but it ended up recopying all of the data, and deleting all my old snapshots in order to do that. In the end, the backup failed, as has happened to me with several other APFS Time Machine backups recently. It claimed there wasn’t enough space even though all the snapshots had been pruned and the destination drive was almost twice as large as the sources.
Update (2025-07-21): I rotated backups and again did associatedisk
, but again the incremental backup took much longer and copied much more than expected. fs_usage
showed that it was indeed copying files from the old drive, and it looks to me like they hadn’t actually changed. At this point, I doubt that associatedisk
actually works.
2 Comments RSS · Twitter · Mastodon
Can you not just drag the most recent backup on your TM disk in Finder into the terminal window with the insertion point where you want the path written, and let terminal do the path for you?
That's what I always used to do when mucking around with TM disks... and I did some real hacky stuff before I knew about inheriting backups & associating disks, like cloning UUIDs via an intermediate thumbdrive to move backups to larger disks without TM seeing them as being different.
@Someone Drag and drop was the first thing I tried, but it gave me the path with .timemachine, which doesn’t work. It used to work with HFS+.