Frequently Asked Questions about encrypting the backup volume

Printer-Friendly Version
Product: 
ccc5

Can I back up an encrypted volume to a non-encrypted volume?

Yes.

If I back up an encrypted volume to a non-encrypted volume, will the copied files be encrypted on the destination?

No, encryption occurs at a much lower level than copying files. When an application reads a file from the encrypted source volume, macOS decrypts the file on-the-fly, so the application only ever has access to the decrypted contents of the file. Whether your backed-up files are encrypted on the destination depends on whether encryption is enabled on the destination volume. If you want the contents of your backup volume to be encrypted, follow the procedure documented here to enable encryption.

Will Carbon Copy Cloner enable encryption on my backup volume?

No. You can enable encryption in the Security & Privacy preference pane while booted from your bootable backup, or in the Finder by right-clicking on your backup volume.

Do I have to wait for encryption to complete before rebooting from my production volume?

No. Once you have enabled encryption on the backup volume, you can reboot from your production startup disk and the encryption process will continue in the background.

What happens if I change my account password on the source volume? Does the encryption password on the backup volume get updated automatically?

The encryption password(s) on the backup volume will not be automatically updated when you change the password for an account on the source volume. When you boot from the backup volume, you may notice that your user account icon is a generic icon, and the text indicates "[Update needed]". The update that is required is within the proprietary encryption key bundle that macOS maintains for your encrypted volume. This encryption key is not maintained on the backup volume, and it is Apple-proprietary, so it isn't something that CCC can or should modify. To update the encryption password on the destination volume:

  1. Choose the backup volume as the startup disk in the Startup Disk preference pane and restart your computer. You will be required to provide the old password to unlock the volume on startup.
  2. Open the Users & Groups preference pane in the System preferences application.
  3. Click on the user whose password was reset on the source volume and reset that user's password again. Resetting the password while booted from the backup volume will update the encryption key for that user on the backup volume.
  4. Reset the password for any other user accounts whose password was reset on the original source.

I enabled encryption on my 3TB USB backup disk. Why can't I boot from that volume any more?

Some versions of OS X have difficulty recognizing USB devices that have been encrypted with FileVault. The Western Digital My Passport Ultra 3TB disk, for example, works fine as a bootable device when not encrypted. In our tests, however, this device was no longer recognizable when FileVault encryption was enabled. This problem appears to be limited to OS X 10.11 El Capitan. The same volume was accessible using older and newer OSes, and also functioned fine as an encrypted startup device using older and newer OSes.

I formatted my destination as encrypted, and it's bootable. Why do you recommend cloning to a non-encrypted volume first?

We generally recommend that people establish a bootable backup on a non-encrypted volume, and then enable FileVault while booted from the destination. Some people have discovered, however, that a pre-encrypted volume can (will usually) function as a bootable device. So why do we recommend the former? There are a couple notable differences between pre-encrypting the disk vs. enabling FileVault after booting from the not-encrypted disk. When you enable FileVault via the Security Preference Pane:

  • You get a sanity check that a recovery volume exists (this avoids spending lots of time copying files only to find out that the volume might not be bootable)
  • You get the opportunity to store a recovery key with Apple
  • You can unlock the disk with selected accounts
  • You get a nicer UI on startup to unlock the disk (e.g. it's similar to the LoginWindow interface), vs. a less-polished looking Unlock Disk interface
  • APFS-specific: You avoid a 24-second startup delay that occurs when the system can't find the "disk" user in the system's directory service on a pre-encrypted APFS volume.

One drawback to enabling FileVault via the Security Preference Pane, however, is that changes to account passwords on the source volume aren't immediately reflected on the backup as far as unlocking the disk is concerned. The old account passwords would be required until you boot from the backup and specifically re-enable those accounts in the Security Preference Pane (at which time the disk's EncryptionKey is remastered).

As far as the backups are concerned, there's no difference between these two methods. There is still an order-of-operations concern with pre-encrypting the disk if your disk is formatted using Apple's legacy HFS+ filesystem format (the steps below are not applicable to APFS – with APFS, simply erase the disk as an encrypted APFS volume in Disk Utility). You'd want to approach it in this manner:

  1. Erase the destination device (unencrypted!)
  2. Click on the freshly-erased disk in CCC's sidebar and create a recovery volume on that disk
  3. Go back to Disk Utility and erase the volume now, not the whole disk (as was emphasized in the instructions above). Now you can choose the option to encrypt the volume. By erasing just the volume here, not the whole disk, the hidden recovery partition that CCC created won't be destroyed.
  4. Open CCC and configure your backup task

In general, either procedure is fine, it really is the same as far as the backup is concerned. We generally prefer the Security Preference Pane method, however, because it yields the same UI behavior you are expecting if you have enabled FileVault on your production startup volume. Many people become concerned when the Disk Utility-encrypted volume shows any behavioral difference at all with regard to unlocking the disk on startup, and that concern is best avoided by enabling FileVault in the Security Preference Pane.

I restored my backup to another Mac that had FileVault enabled, and now I can't unlock the cloned volume.

Encryption is a volume-specific endeavor, and when it's enabled via FileVault, it's also tied to the user accounts on that specific installation of macOS. If you clone another installation of macOS onto a volume that has FileVault enabled, the user accounts from the "foreign" (source) OS will not be able to unlock the FileVault-encrypted destination volume. To avoid this scenario, you should erase the destination volume as a non-encrypted volume. When erasing an APFS volume, be careful to erase the whole APFS container, not just the encrypted volume within the container.

Please note that this concern is not applicable to restoring a backup to the original source volume. In that case, the OS on the backup volume is not foreign; the user accounts on the backup volume match the user accounts on the original source. In that scenario, FileVault will continue to function normally.

I haven't enabled FileVault, why does CCC indicate that the SSD in my T2-based Mac is encrypted?

New Macs that have Apple's T2 controller chip (e.g. the iMac Pro and the Mid-2018 MacBook Pro) support new security measures for the internal startup disk. When volumes on that disk are formatted as APFS, those volumes intrinsically benefit from at-rest encryption. A password is not required to unlock these volumes (that password is "baked" into the Mac's hardware), but the volume is encrypted automatically.

The Startup Security Utility may not work correctly after restoring to an encrypted-at-rest volume on T2-based Macs

The at-rest encryption described above involves a volume-specific "secure access token", which each user account must obtain access to if that user requires administrative privileges over startup security settings. Because this token is volume-specific, cloning the token from one volume to another will not produce the correct result. Additionally, user accounts that have access to the token on the source won't automatically have access to the token on a cloned volume.

Apple does not offer a method for creating this token on a volume that is not the current startup disk, so CCC cannot offer a postflight method that automatically creates that token. Apple does, however, offer a utility for granting access to the secure token for specific users on the current startup disk. If you find that you're unable to modify settings in the Startup Security Utility while booted from the macOS Recovery volume (e.g. "No administrator was found"), reboot from your cloned volume, then paste the following into the Terminal application to grant access to the secure token to your user account (replace "yourname" with the short name of your user account):

sysadminctl interactive -secureTokenOn yourname -password -

If the procedure above does not work for you...

We found one other mechanism that seems to convince the system to generate the secure token. If you start the process to enable FileVault, but cancel it at the last moment, the system should create the secure token:

  1. Open the Security & Privacy Preference Pane in the System Preferences application
  2. Click on the FileVault tab
  3. Click the padlock icon in the lower-left corner to allow changes
  4. Click on the "Turn on FileVault..." button
  5. Choose the option to "Create a recovery key and do not use my iCloud account"
  6. I know you're getting nervous at this point that you're about to enable FileVault, but that's not going to happen yet as long as you choose the option to create a Recovery key. Click Continue.
  7. Click the Cancel button, then quit the System Preferences application

After cloning to an APFS Encrypted volume, the destination can't be unlocked on startup, or has a 24-second stall during startup

Both of these conditions are caused by the same underlying problem: None of the current user accounts on the destination is allowed to unlock the disk. There are generally two ways to get to this result:

  • The volume was erased as an encrypted volume, thus no user account was associated with the unlocking of that volume, or
  • The user accounts that are allowed to unlock the disk belonged to some previous installation of macOS on that volume

Our advice in both of these cases is to repeat the restore procedure, paying particular attention to the step where you erase the destination in Disk Utility before proceeding with the cloning task. You should erase the destination as "APFS", not "APFS (Encrypted)". Additionally, you should erase the whole destination device, not just the destination volume. Disk Utility makes this unintuitive, it's imperative that you select Show All Devices from Disk Utility's View menu so you can see the device inheritance.

I don't want to erase my destination again, is there any way to fix this?

If you can't unlock the cloned volume on startup, then you can decrypt the destination volume using the diskutil command-line utility. For example, running the following command in the Terminal application would decrypt a volume named "CCC Backup":

diskutil ap decrypt "/Volumes/CCC Backup"

After decrypting the backup volume, you can then boot from it and enable FileVault in the Security & Privacy Preference Pane in the System Preferences application.

If you can boot your Mac from the backup, but you're seeing a stall during startup, you can resolve that matter by decrypting the volume as indicated above, or by creating a new user account that has a Secure Access Token. Only the macOS Setup Assistant has the ability to create the first secure access token, so follow these steps while booted from the volume you're trying to repair:

  1. Mojave+ only: Grant Full Disk Access to the Terminal application
  2. Open the Terminal application and run the following commands, substituting your own volume name as applicable:
    sudo rm "/var/db/.AppleSetupDone"
    sudo rm "/var/db/dslocal/nodes/Default/secureaccesstoken.plist"
  3. Restart the system
  4. Setup Assistant will ask you to create a new user. Create the new user account with default settings. A simple name like "tokenuser" will do, don't login with an Apple ID.
  5. Immediately log out of the new user account, and log in using one of your own admin user accounts.
  6. Open the Terminal application and run the following commands, substituting your own user names as applicable:
    sysadminctl -secureTokenOn youraccount -password - -adminUser tokenuser -adminPassword -
    sysadminctl interactive -deleteUser tokenuser