Encrypted APFS clones

[wildthing]

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]

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]

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]

Originally Posted by dnanian

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?

Thanks

[dnanian]

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]

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

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]

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 APFS...now if they can only improve the performance, etc...

[wildthing]

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?