Shirt Pocket Discussions

Shirt Pocket Discussions (
-   General (
-   -   Encrypted APFS clones (

wildthing 02-04-2018 04:09 PM

Encrypted APFS clones
I have several questions regarding encrypted clones and APFS.
  1. This thread describes a method for creating bootable encrypted clones. Does it still work with APFS using the latest SuperDuper?
  2. In the same thread, Dave said "if you want an encrypted backup but don't care about bootability ... you can do that, too...". How would you do that, and does that still work with APFS?
  3. Is it possible to configure a clone such that a unique high-entropy random passphrase is required to decrypt it, and it cannot be decrypted using any of the macOS account passwords that reside in the OS that's been cloned?

The reason for question 3 is that macOS account passwords usually need to be memorized by a human, and therefore tend to have much lower entropy than truly random long passphrases. Furthermore my backup drives are transported to, and stored in, various offsite locations. For this reason I want this additional level of protection on my backups, compared to my actual computers which stay at home.

Before APFS came along, I was able to create clones which were both bootable and encrypted using SuperDuper, and which required a unique passphrase which was totally distinct from any of the macOS account passwords. I did this by using Disk Utility to first create an HFS+ volume encrypted with a unique high-entropy random passphrase, and then cloning to it using SuperDuper. When I booted from the clone, the following happened:
  • I was FIRST prompted to decrypt the drive - the prompt was usually (but not always) for a user called "[Update Needed]". A this point I HAD to type the unique high-entropy random passphrase for the drive - macOS account passwords were NOT accepted
  • I THEN got a normal macOS login screen where I could select a macOS account, and then log in as normal

When I tried to do the same thing with APFS using the latest SuperDuper 3.1.4, I found that SuperDuper replaced my encrypted APFS volume with a plain old non-encrypted APFS volume - which is not what I wanted.

Has the capability to generate bootable encrypted clones that require a distinct passphrase vanished with the move to APFS?

dnanian 02-04-2018 04:21 PM

1. You don't have to do anything special with APFS encrypted clones. It's easiest to copy unencrypted, boot from the backup and turn encryption on, but you can also format as encrypted and Smart Update to it.

2. You wouldn't, since it's not an issue with APFS.

3. Yes, format as encrypted with your own passphrase before copying...with Smart Update. I believe that will work. It certainly won't make it *unencrypted* (don't erase!).

wildthing 02-04-2018 04:27 PM

Aha! So if you use Smart Update, it still works even though the target volume is empty - and it preserves your existing APFS volume which was earlier encrypted with a unique passphrase. Whereas if you use Erase then Copy, it replaces your encrypted APFS volume with a non-encrypted APFS volume.

That certainly makes sense and is very logical! I will give it a go and see if it works! :)

flyingout 02-04-2018 09:01 PM


Originally Posted by dnanian (Post 34132)
1. You don't have to do anything special with APFS encrypted clones. It's easiest to copy unencrypted, boot from the backup and turn encryption on, but you can also format as encrypted and Smart Update to it.

If I may dig a bit deeper. I have been reorganizing my backups, some of which have moved to a new big APFS formatted drive.

These don't really need to be bootable but I'd rather all clones be done the same way and my primary clones are bootable on HFS+ volumes.

I prepared these by installing High Sierra to fresh APFS volumes, logging on and activating FileVault, then doing Smart Updates. (version 3.1.4)

Two questions:

1. I'm getting UpdatePreboot errors After Successful Copy, which I believe you have mentioned previously.


( 01:01:39 PM | Info |      UpdatePreboot: Exiting Update Preboot operation with overall error=(0=success)=-69568
| 01:01:39 PM | Error | Error: -69568: An APFS crypto user was not found in the Open Directory user database

Is this a result of the way I set things up? Any solution?

2. When I can I tend to avoid copying first and encrypting after, fearing that the plaintext files might not be sufficiently wiped in the process. Is this concern not justified? Might copying first solve the Preboot issues?


dnanian 02-04-2018 09:18 PM

You need to erase the destination from the hardware - the very top of the drive - so it creates a new APFS superblock and container.

wildthing 02-05-2018 05:45 AM

OK, I tried using Smart Update on an empty pre-encrypted APFS volume - and it worked perfectly :D

When SuperDuper completes the backup, the target volume is preserved as "APFS (Encrypted)" - and when I boot from it the following happens:
  • First I get a prompt for "Disk Password", which only accepts the high-entropy random passphrase. The macOS account passwords are not accepted here.
  • Then it appears to decrypt the drive (progress bar takes quite a long time)
  • Finally a regular macOS login screen appears, where I can log in with one of the macOS accounts

This is the exact behaviour I wanted - a bootable, encrypted clone that requires a distinct passphrase.

It's interesting that the prompt for the disk passphrase says "Disk Password" rather than login for user "[Update Needed]".

Looking back at my notes, when I was using HFS+ the disk passphrase prompts were very inconsistent. Sometimes it was "Disk Password", sometimes it was both "Disk Password" and "Guest User", and other times it was both "Updated Needed" and "Guest User". It seemed to be random which one appeared. I've no idea why. I wonder if it's more consistent now with APFS.

dnanian 02-05-2018 11:00 AM

Yep, it should work. That's what the Preboot volume is for (well, one of the things). The whole thing is much better managed with if they can only improve the performance, etc...

wildthing 02-05-2018 11:00 AM

Hmm, after doing these APFS clones, Time Machine is now running for the first time since running SuperDuper - and it's suddenly decided it needs to re-copy everything, instead of the usual delta.

As there is nearly 900 GB on my primary drive it's taking more than a day, and is making my laptop very hot.

Is this a coincidence?

dnanian 02-05-2018 11:34 AM

If you booted from another drive, it's possible Time Machine reset its own drive selections. TM is a bit of a black box, as you know... but it wouldn't do it because you made a copy.

wildthing 02-05-2018 12:44 PM

OK, I did boot from another drive - the clone - in order to test it.

Now that you mention it, when I booted up from the clone I did notice Time Machine starting a backup, up so I clicked "Skip This Backup" to stop it.

I don't recall this happening before, but maybe I just didn't notice it before - or maybe I was lucky.

I wonder if Time Machine starting up on the clone caused it to do a full re-sync next time it ran on the primary drive - and if so, how to prevent it happening in future. Maybe I should just turn off Time Machine, immediately after booting up on the clone.

dnanian 02-05-2018 01:09 PM

Again, any behavior here is undocumented by Apple. It's hard to know what it might or might not do.

You can, of course, use tmutil from a before/after copy script to do things with Time Machine. You could, for example, turn it off before copying and then turn it on after. That could potentially have it be off on the backup. But, any copy failures would leave TM off, which you'd have to watch out for.

wildthing 02-05-2018 01:28 PM

OK, thanks for the suggestions.

All times are GMT -4. The time now is 03:09 AM.

Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2018, vBulletin Solutions, Inc.