tmutil is broken by SIP in Mojave

A diskutil bug unceremoniously erased an entire hard drive of mine a few weeks back.  While I was able to successfully (AFAICT) restore the drive’s contents to it from various backups, the erasure gave the drive a new identity (UUID, specifically).  The next time Time Machine ran, it compounded the diskutil bug by also unceremoniously deleting all my old backups (bar one, the latest), because it didn’t recognise the new drive with identical contents to the old drive as being the same drive, and tried to back it up again, requiring way more space, causing all existing backups to be purged, etc.

Sigh.

It turns out there’s actually a nominally supported way to address exactly this scenario – tmutil associatedisk (kudos to Simon Heimlicher for documenting this).  From the man page:

     associatedisk [-a] mount_point snapshot_volume

             Bind a snapshot volume directory to the specified local disk, thereby reconfigur-

             ing the backup history. Requires root privileges.

             In Mac OS X, HFS+ volumes have a persistent UUID that is assigned when the file

             system is created. Time Machine uses this identifier to make an association

             between a source volume and a snapshot volume. Erasing the source volume creates

             a new file system on the disk, and the previous UUID is not retained. The new

             UUID causes the source volume -> snapshot volume association to be broken. If one

             were just erasing the volume and starting over, it would likely be of no real

             consequence, and the new UUID would not be a concern; when erasing a volume in

             order to clone another volume to it, recreating the association may be desired.

             A concrete example of when and how you would use associatedisk:

             After having problems with a volume, you decide to erase it and manually restore

             its contents from a Time Machine backup or copy of another nature. (I.e., not via

             Time Machine System Restore or Migration Assistant.) On your next incremental

             backup, the data will be copied anew, as though none of it had been backed up

             before. Technically, it is true that the data has not been backed up, given the

             new UUID. However, this is probably not what you want Time Machine to do. You

             would then use associatedisk to reconfigure the backup so it appears that this

             volume has been backed up previously:

             thermopylae:~ thoth$ sudo tmutil associatedisk [-a] “/Volumes/MyNewStuffDisk”

             “/Volumes/Chronoton/Backups.backupdb/thermopylae/Latest/MyStuff”

             The result of the above command would associate the snapshot volume MyStuff in

             the specified snapshot with the source volume MyNewStuffDisk. The snapshot volume

             would also be renamed to match. The -a option tells associatedisk to find all

             snapshot volumes in the same machine directory that match the identity of

             MyStuff, and then perform the association on all of them.

Perfect – and I particularly like the subtext of the prose, which seems to be a subtle acknowledgment that this is a thing that happens frequently, and that macOS’s default behaviour is stupid… “recreating the association may be desired”.  No shit.

Unfortunately, that command doesn’t work in Mojave.  I’m apparently not the first person to notice.

It appears the tightened security, and in particular expansion of SIP to cover many more parts of the system including Time Machine backups, are to blame.  Even granting tmutil Full Disk Access etc in the system security settings is of no use (contrary to the stated purpose of Full Disk Access).

So you have to disable SIP first – which requires a reboot, obnoxiously – and only then does tmutil work again.  You’ll want to enable SIP again once you’re done, most likely, as the protections it provides are useful – it appears tmutil nve eeds to be updated to account for the new protections.

Encrypted RAID volumes in El Capitan

Apple crippled Disk Utility in El Capitan, in their usual name of making good functional things pretty & pretty useless.

Luckily I’m far from the first person to need to create RAID and/or encrypted CoreStorage volumes, in El Capitan.  Florian Knapp has a concise summary of how to set up an encrypted RAID volume.  Tom Nelson (of About.com) has a slightly more detailed tutorial for managing the RAID part.

Now I just wish the hard drive industry would actually push capacities up, like they once did, so that I don’t have to resort to striped RAID sets just to make a disk big enough for Time Machine backups.  It feels like we’ve been effectively stuck at 6 TB for many years now, and affordable 8+ TB drives aren’t really on the horizon (Seagate & Western Digital have offerings, but historically have been bad brands for drive reliability, e.g. Backblaze’s data, plus my own personal experience with their drives).

Update:  macOS Sierra partially restores Disk Utility’s functionality, though not enough to be useful.  It adds a “RAID Assistant” which lets you create unencrypted RAID volumes.  The core Disk Utility app can also initiate manual repair of RAID mirrors, and delete RAID volumes.

It’s something of a mystery why you cannot create encrypted RAID volumes with the RAID Assistant.  It doesn’t offer any encrypted file systems as initialisation options, and attempting to erase the unencrypted RAID volume in Disk Utility, to replace it with an encrypted version, fails with the bullshit error message:

An internal state error occurred
Operation failed…

No shit.

Furthermore, encrypted RAID volumes (or more precisely, any RAID volume that’s part of a CoreStorage Logical Volume Group) don’t get recognised as RAID volumes in Sierra’s Disk Utility unless you connect the underlying drives while Disk Utility is running.  Even then it’s hit or miss whether it’ll correctly recognise not just that it is a RAID set but also that there’s an encrypted CoreStorage volume on the set.  And I’m not even going to try testing if it can actually repair a RAID mirror in that configuration.

To be clear, RAID volumes that don’t have CoreStorage volumes atop them seem to work fine.  It’s evident that Apple simply don’t support encrypted RAID volumes.  Maybe in next year’s macOS – it must be hard adding support for things you already fucking supported until you pointlessly removed support for it.

FWIW, here’s a howto from Macworld on how to use the new RAID Assistant, if encryption isn’t something you want.