Skip to content

Notes on Creating an Encrypted Bootable SuperDuper Backup

SuperDuper icon

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

This is an advanced, technical process. These are my notes that I share in case they help. They are NOT a step-by-step guide of the kind at I might typically publish. This is something that might not be stable, and should only ever be part of a wider backup strategy.

This process is destructive — I assume the luxury of working on a brand new drive without any other data.

NEVER run the commands below on your live disks without understanding what they do, which device you are acting on and checking carefully that you mean what you have typed. YOU MUST HAVE ANOTHER COPY OF YOUR DATA IN CASE THE WORST HAPPENS.

Obviously, I do not accept any responsibility and cannot help if you break things by using these notes. Hard hats must be worn beyond this point. All contractors must report to the site office.

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

In 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.

Like this post?

If you would like to support the time and effort I have put into my tutorials and writing, please consider making a donation.

4 Comments

  1. Jay wrote:

    Thanks for this.

    As of 10.10.5, encrypting the disk creates an Apple_Boot partition, but it’s too small for recovery (in my case it was 130MB or so). But, instead of running the gpt commands, I was able to merge the Apple_Boot partition with the recovery partition:

    sudo diskutil mergePartitions JHFS+ “Recovery HD” disk2s6 disk2s3

    where disk2s3 is the partition I had originally created, and disk2s6 was created when I encrypted the backup volume. (BTW, instead of running the diskutil coreStorage commands, I was able to just right-click on the volume in the Finder and select “Encrypt Disk…”. The Finder then ran the coreStorage commands on my behalf.)

    So, from the beginning. First I partitioned my disk (1 TB drive) from the Terminal (because I wanted more control of the volume size than Disk Utility allows) like so:

    sudo diskutil partitionDisk disk2 3 GPT JHFS+ “Clone HD” 251G JHFS+ ” Recovery HD” 520M JHFS+ “Backup HD” 700G

    Then in the Finder, I encrypted “Clone HD” by right-clicking on it in the Finder and selecting Encrypt Disk…

    Back at the Terminal:

    sudo diskutil mergePartitions JHFS+ “Recovery HD” disk2s6 disk2s3

    Then run the ditto and bless commands per your instructions.

    Finally, I did the backup to Clone HD.

    The “Backup HD” I’m using for Time Machine, which I told Time Machine to encrypt (and which created another Apple_Boot volume… it looks like Core Storage just does that now by default. It names these volumes “Boot OS X” but if you mount them, they’re empty. And they’re too small too be useful, about 134 MB in my case.)

    Saturday, January 9, 2016 at 04:14 | Permalink |
  2. Emily wrote:

    Hey guys!
    Looking at various posts on this topic, it seems that all one has to do is encrypt the backup volume, (OS 10.11.4, via the contextual menu), then let SuperDuper rip. SuperDuper blesses the volume once the backup is completed.
    What I don’t get is, how is SuperDuper able to read and write to the volume without authenticating? After all, to do a Smart Backup, SuperDuper must be able to read the files on the target disk in order to determine which need updating, no? Clearly, I am missing something. And, please correct me if I’m wrong about the setup process.

    Thursday, May 12, 2016 at 01:06 | Permalink |
  3. Peter wrote:

    @Emily:

    I haven’t tried your approach of just right-clicking and letting OS X do its thing with the drive. My understanding is that the Recovery HD partition would need to be on the encrypted disk in order for the volume to be able to be blessed and become successfully bootable later, but I could be wrong! This certainly would be easier than my method above!

    From the point of view of authentication, OS X stores the encryption passphrase in the keychain if you encrypt in this way. So, mounting that encrypted volume later under the same user account is completely transparent — the passphrase is available in the unlocked keychain. Once unlocked and mounted, any application, including SuperDuper, can read and write files on the volume as normal.

    Tuesday, May 31, 2016 at 19:16 | Permalink |
  4. @joely wrote:

    January 11, 2017

    I made a bootable encrypted clone using SuperDuper on OS X 10.11.

    All I had to do was to reformat the Samsung External T3 SSD with Disk Utility to be Mac OS Extended (Journaled, Encrypted) like this:

    Disk Utility for Mac: Protect a disk with a password using Disk Utility
    https://support.apple.com/kb/PH22246?locale=en_US

    Then I cloned my system drive with SuperDuper from my Macbook Pro onto the external SSD.

    That’s all I had to do.

    After that I could boot off the external device and everything was fine.

    And everything was encrypted by Disk Utility and passwords were prompted for and accepted at the appropriate times.

    At one time, I believe this article was helpful. But now I think it could get someone pointed in the wrong direction.

    On the other hand, with the appropriate caveats, this article would really make people appreciate how things are, as of now!

    You obviously went to a lot of work to create this article and in no way do I mean to disrespect your hard & good work!

    Peace, @joely

    Wednesday, January 11, 2017 at 23:21 | Permalink |

Post a Comment

On some sites, you must be logged in to post a comment. This is not the case on this site.
Your email address is not made public or shared. Required fields are marked with *.
*
*
*

Posting a comment signifies you accept the privacy policy.
Please note — your comment will not appear straight away, as all comments are held for approval.