SuperDuper is one of my favourite backup applications for the Mac, and I use it as part of my backup and recovery strategy.
One of its benefits is creating a bootable clone, so in the case of any trouble, you can connect the backup drive, hold Option/Alt and boot your alternative system.
The world has changed since I first used this tool, and full-disk encryption is now essential for maintaining privacy and “not-having-your-life-turned-upside-down” in the event of a loss of control of the drive with your life on it. FileVault on OS X since Lion works beautifully for your boot drive, but unfortunately I had to sacrifice the bootability of my SuperDuper backup in order to ensure it was encrypted.
Recently, a drive failure on my SuperDuper backup drive (yep, they do happen, and that’s why we back up!) required me to replace the drive. That gives a good excuse to play, and try and make a bootable and encrypted backup — FileVault-style, but on an external disk that we manage ourselves.
I succeeded! Unfortunately, as is often the case with things one is playing about with, I fiddled and failed and tried again so many times I am not sure if I can completely replicate the process. However, I offer these notes as to roughly what I did in case they help others with the same ambition.
Big, Important, Scary Disclaimers
OK, ready? 🙂
Create a New GPT Disklabel and Basic Layout
We can use Disk Utility to format with the GPT disklabel and make a rough partition layout. I chose a slightly more complex partition layout, but others may want just one big partition for their data. (Don’t make it just yet, we need at least two partitions, even if your data just goes in one big one.)
It is useful to enable Disk Utility’s debug menu:
defaults write com.apple.DiskUtility DUDebugMenuEnabled 1
We can go to Debug > Show every partition which provides a visual look at partitions such as the EFI boot partition.
This rough partition layout should be at least two partitions, including a really small (1 GB is fine) partition to hold the Recovery HD, needed to boot the encrypted volume later. In all cases, use Journaled HFS+.
This should also ensure that the EFI boot partition is created with index 1. We don’t need to worry too much about the EFI boot partition, just that it is there.
Create a CoreStorage Volume Group
On the big partition where you actually want the cloned data sitting, we need to now create a CoreStorage Volume Group (VG) in that space. Substitute MyEncryptedClone for a group name of your choice!
The identifier for the physical disk I am using is disk2. This will appear throughout these commands and may need substituting in another environment.
First, determine the disk identifier of this big area of the disk:
diskutil list disk2
It should be clear which one it is from the size! Mine is disk2s4.
diskutil cs create MyEncryptedClone disk2s4
Create an Encrypted Volume Inside the VG
diskutil cs createVolume MyEncryptedClone jhfs+ MyEncryptedCloneVolume 100% -stdinpassphrase
You’ll be able to set the passphrase when prompted. Obviously, store this securely somehow!
Run your Initial SuperDuper or Other Clone
Use your backup application as normal, targeting this new encrypted volume.
Prepare the Recovery HD Partition Type
That little 1 GB partition from earlier now needs to serve as the Recovery HD for this disk, which will, in concert with the EFI boot partition I believe, allows the system to boot from the encrypted logical volume.
We actually need to erase and re-create the GPT partition with the correct type UUID for an Apple_Boot partition.
During running these commands, OS X might re-mount the volumes whenever they change, which is annoying, as you have to
diskutil unmount them before you can run gpt again.
sudo gpt show disk2
Determine the current start block of the little partition you made. You’ll have to figure out from the index (cross-referencing this from
diskutil part‘s output as to which order the partitions come in. The size, which I believe is the block count, of my ~1 GB partition was 2359296.
The index of my little partition was 3. Note down the start block of this partition (mine is 2768936), so we can re-create it in exactly the same spot later.
sudo gpt remove -i 3 disk2
We should now have free space, starting at the block number we identified, that we will use to re-create the partition with the correct GPT GUID for an Apple_Boot volume.
sudo gpt add -b 2768936 -i 3 -t 426F6F74-0000-11AA-AA11-00306543ECAC disk2
diskutil list, you should now see an Apple_Boot Recovery HD volume. Get the disk identifier for this new volume (mine is disk2s3).
Note that because the partition was formatted before we deleted and re-created it, and it occupies the same space, it doesn’t seem to need reformatting, although it might be a good idea.
Clone the Recovery HD
We will mount the Recovery HD from the live system, and clone it to this new volume. Ascertain the current Recovery HD disk identifier:
diskutil list disk0
My existing Recovery HD is disk0s3.
diskutil mount disk0s3
This should mount the Recovery HD in /Volumes/Recovery HD.
Now, we mount the new one, using its disk identifier:
diskutil mount disk2s3
This will mount in /Volumes/Recovery HD 1.
Now, we will copy the files from the live Recovery HD to the new one:
sudo ditto -V /Volumes/Recovery\ HD/ /Volumes/Recovery\ HD\ 1/
Bless the Recovery HD
We now need to ‘bless’ the Recovery HD, which roughly translates to marking it as bootable!
sudo bless -folder /Volumes/Recovery\ HD\ 1/System/Library/CoreServices/ -bootefi /Volumes/Recovery\ HD\ 1/System/Library/CoreServices/boot.efi
I now, for the sake of completeness, immediately rebooted (into my normal system!) to be sure I had properly unmounted everything I was messing with before.
Test it Out
I now rebooted again, holding Option/Alt. I saw the volume name of the main CoreStorage LV we made earlier showing on the one-time boot menu. Choosing this (not ‘Macintosh HD’ or ‘Recovery HD’ with the external icon, but the LV name itself), seemed to start the boot process, ask me for the disk key, and then boot into the cloned system!
I am not sure if re-running SuperDuper after this process is going to reset the blessed state on the disk and whether it will be necessary to re-bless the Recovery HD again. I will update this post if I determine that further steps are needed on each backup!
UPDATE: running a SuperDuper Smart Update on the encrypted clone causes no problems in my environment, and the volume continues to be bootable.