Matt Godden

human : artist

Bring content into view.

Becoming a Lord of Time…

Disclaimer:

A couple of years after writing this, I found the officially sanctioned way of doing what I’m doing here. It’s based on the Time Machine command-line utilities. I’ve used it since, and it works well.

Here it is: https://www.baligu.com/pondini/TM/B6.html

If you want to see what’s happening while time machine is doing its run, you can try this from the command line:

log stream –style syslog –predicate ‘senderImagePath contains[cd] “TimeMachine”‘ –info

Anyway, back to the original article:

…or, how to make Time Machine treat a duplicated and enlarged source volume as the original, and continue incremental backups.

It’s not supposed to be possible, but after 3 days of research, and multiple 4-8 hour backup sessions, I’ve cracked it – done something that, as far as I can tell, noone else believes can be done, or has documented how to do. If you follow the instructions here, using only free tools, you’ll be able to do it as well.

The Problem:

You have a Time Machine drive handling backup for multiple drives attached to your system. For example:

Boot / User: 500gb, Photos: 900GB.

Right now, your Time Machine backup is around 1.4TB minimum. On a 2TB drive, that leaves you with 600GB for historical versions of files. Every time you change a file in any way, another copy of the file is added to the Time Machine volume.

Let’s assume your Photos drive is 1TB, and you need to move the contents onto a larger drive before it runs out of space.

You plug in a new 2TB drive, format it with the same name, copy the contents of the Photos drive across, remove the old Photos drive.

You let Time Machine do its thing.

Time Machine will treat the new 2TB Photos drive as a different drive from the original, and perform a full backup of the drive, even though the data on it is identical in every way. Using Carbon Copy Cloner, or Disk Utility’s Restore function will not get around this.

Your Time machine storage now requires: Boot / User: 500GB, Photos (old): 900GB, Photos (new): 900GB, for a total of 2300GB. You’ve now got a backup that’s larger than your 2TB Time Machine volume, and importantly, Time Machine will delete all your historical backups in order to make room for what will effectively be two identical copies of most of your photos.

The Cause:

This happens because Time Machine uses the UUID of the drive to identify it. The UUID is assigned to the drive when it is formatted in Disk Utility, it’s effectively random, and is unaffected by changes to the name of a drive. This means you can change the name of your drive without triggering a full backup, it also means the integrity of your Time Machine backups can’t be effected by temporarily plugging in another drive of the same name, even if the contents are mostly identical.

In general, it’s a safety feature, but as above, it has a serious drawback.

The Solution:

In order to make the enlarged drive behave as a continuation of the old one, you have to fool Time Machine into thinking the new drive is the old one. To do this, you have to copy the data correctly, alter the new drive’s UUID to match the original, then alter the original drive’s UUID so it doesn’t conflict.

Tools You’ll Need:

Note: this is how I made it work – some stuff here may not be totally necessary, but as anyone who used SCSI back in the day knows, superstition is an important part of technology.

  1. A separate bootable MacOS drive / partition where you’ll do all the tasks (to avoid the possibility that your normal system will record what you do in the filesystem events record), and in which you’ve switched off Time Machine. We’ll refer to it as “Tools“. Not the (probably internal) drive you use normally, which we’ll refer to as “MyMac“.
  2. The old (nearly full) drive – “Photos” for this example.
  3. The new larger drive.
  4. A USB thumb drive.
  5. A copy of Shirt-Pocket’s SuperDuper.
  6. A plain text file to act as a scratchpad for copying and pasting things (there’s a pre-formatted version of the whole process below, as a cheat-sheet once you read the process and understand what to do).

Method:

  1. Boot your mac from the normal MyMac drive.
    1. Run a Time Machine backup.
    2. Switch off Time Machine in System Preferences.
  2. Reboot to Tools.
    1. Download and install SuperDuper (to Applications on the Tools drive).
    2. Open Disk Utility
      1. Plug in and format the new larger drive as a standard Mac volume (HFS+ Journalled, case insensitive – make it match the drive you want to clone). The name doesn’t matter.
      2. Plug in and format the USB thumb Drive as a standard Mac volume.
      3. Get info on the old Photos drive, and note down its UUID in your text file. (Depending on the version of Disk Utility you have, you might have to get this from the System Information in About This Mac.)
      4. Select your Photos drive on the left, and use the Restore function to copy it onto the new larger drive (probably called “Untitled”).
      5. Wait some hours while it does its thing. Restore uses block copy which ensures the files aren’t touched or changed by being copied.
      6. Note down the UUID of the new version of Photos on your text file. This is so you can ensure it’s changed later on.
    3. Go to Finder, navigate to where you have installed SuperDuper (Applications).
      1. Right click on SuperDuper, choose “Show Package Contents”, then navigate to Contents / MacOS /
      2. Make sure you can see the exec file SDDiskTool.
    4. Open Terminal.
      1. change directory to the MacOS directory above – you’re going to be using SDDiskTool from the command line, but your comand has to be run from within this directory. The easiest way to do this is (the angle brackets are for actions don’t type them) :
        cd <drag the "MacOS" title icon in the titlebar of the window to here> <hit enter>
      2. Get the UUID in encoded form from the original Photos drive:
        ./SDDiskTool -g <drag old Photos source disk from Finder> <enter>
      3. You’ll see a string of characters returned to the next line, before your command prompt. This is the encoded UUID. Important: Copy those characters to your text file for safe keeping. Be careful selecting them, as they’ll run into the name of your machine at the command prompt.
      4. Set the encoded UUID to the new Photos drive:
        sudo ./SDDiskTool -s <paste the encoded uuid> <drag new Photos target disk from Finder> <enter>
      5. Enter the admin password for your Tools drive system Admin account.
    5. Quit Disk Utility (it has to be relaunched to see the new UUID)
    6. Eject BOTH Photos drives in Finder.
    7. Relaunch Disk Utility and mount the new Photos drive.
      1. Copy the UUID to your text file, and check it matches the original Photos drive version.
      2. Unmount the new Photos drive.
      3. Remount the old Photos drive.
    8. Repeat this process to assign the UUID from the USB thumb drive to your old Photos drive, so that when you reboot to MyMac it won’t confuse Time machine (or, to be super safe physically unplug the old photos drive, do step 9, then reboot to Tools and do this step).
    9. Reboot to MyMac and (eject the old Photos drive if you haven’t changed its UUID) then manually trigger a Time Machine backup – you should be able to tell pretty quickly if it’s worked by the size of the backup that’ll be performed. If it’s the same, or larger than your Photos drive, it hasn’t worked. In which case, stop it, delete the .inprogress file from the Backups.backupdb folder on your Time Machine drive, and start the process from scratch – that’s why you kept the encoded UUID numbers, if you’ve overwritten the old Photos drive UUID with that from the thumbdrive, the encoded value is the only way to assign it. If you open Console, go to System Log, All Messages on the left, then fill in the filter search field on the top right with com.apple.backupd prior to triggering the backup, it’ll tell you how much will be backed up from your various drives. If you’ve done a backup immediately prior to this whole process, then the first backup you do afterwards should be negligible.
    10. If it all worked OK, turn Time Machine automatic backups back on.
    11. If it all goes wrong, and you can’t get the UUIDs to copy, or the copying to stick – my suggestion is to go into the Time Machine history browsing interface when you’re on your whole computer in a Finder window, where you can see all your drives, right click on the photos drive in your most recent level of backup, and delete all backups of photos (they’re safe on your old Photos drive). That will then clear off all your photos backups, meaning that there’s space on the drive to put an entire fresh backup of Photos onto the Time Machine drive, without deleting the historical backups from your Boot / User drive. This is basically where you were going to end up in the first place.

Standard Disclaimer: I take no responsibility for you hosing all of your data and backups doing this. It’s working for me, and I pieced it together and adapted it from bits around the web – mostly relating to how SuperDuper handles working with multiple drives. I suggest doing a practice run with a couple of thumbdrives to make sure you can do it properly.

Cheat Sheet:

1 install Superduper
2 launch terminal
3 cd to inside superduper bundle contents / MacOS
4 ./SDDiskTool -g <drag source disk> <enter>
5 copy encoded uuid
6 sudo ./SDDiskTool -s <paste the uuid> <drag target disk> <enter>
7 enter password
8 unmount disk, quit disk utility, relaunch disk utility and remount disk
9 Write & Check UUIDs
 
 Drive:
 Current UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX <- The drive you're cloning *to*
 Desired UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX <- The drive you're cloning *from*
 Encoded UUID: XXXXXXXXXXXXXXXX
 Altered UUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX <- Drive you're cloning *to*
                                                       after the process, should match Desired UUID.

Dedicated in part to the memory of the late James “Pondini” Pond.

Thanks to Dave Nanian and Shirt Pocket Software for producing SDDiskTool.

If this article was of use, a donation would help support my projects.