Carbon Copy Cloner
Knowledge Base > Carbon Copy Cloner 5

Frequently Asked Questions about encrypting the backup volume

This documentation is for an older version of CCC. You can find the latest version here.
Last updated on 8 juillet 2020

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 (for a backup volume that does not have an installation of macOS).

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 password do I use to unlock my encrypted volume?

When you boot your Mac from the backup volume and enable FileVault in System Preferences, you explicitly choose which user accounts will be allowed to unlock that volume. To unlock the volume in the future, enter the password to any of those user accounts. Do not attempt to use the Recovery Key or your Apple ID account password to unlock the volume — those passwords will not unlock the volume.

If you erased your backup volume as encrypted in Disk Utility, then you will use the password that you specified in Disk Utility to unlock the volume.

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.

Can I create a bootable backup on a pre-encrypted volume? Why do you recommend cloning to a non-encrypted volume first?

Catalina users: It is not possible to create a bootable backup on a pre-encrypted backup disk, Apple's tools just don't permit this. You can enable FileVault after establishing your initial backup, and then CCC can maintain a bootable backup on your FileVault-encrypted backup volume.

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 function as a bootable device with versions of macOS prior to Catalina. 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). 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 can't enable FileVault, I'm told that my account cannot be used to manage encryption on this Mac

The Startup Security Utility reports that authentication is needed, but no administrators can be found

After cloning to an APFS volume that previously had FileVault enabled, the destination can't be unlocked on startup

After cloning to an APFS Encrypted volume there is a 24-second stall during startup

All of these conditions are caused by the same underlying problem: users on the affected volume do not have access to the volume's Secure Token. 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

Solution: Erase the destination in Disk Utility before proceeding with the cloning task. You should erase the destination as "APFS", not "APFS (Encrypted)". For more technical users, we offer some additional background information below.

APFS volumes that contain an installation of macOS will each have a unique "secure access token". Access to this token allows users to do things like unlock the volume (e.g. if FileVault is enabled) and to change startup security settings. Because this token is volume-specific, it can't be copied to another volume; it has to be regenerated. In addition to this Secure Token, APFS volumes also have a list of users or keys that are "bound" to the volume. These "cryptographic users" are defined within the volume metadata, not within any particular file on the volume. As a result, these bound cryptographic users cannot be modified by CCC nor transferred from one volume to another. This cryptographic user list is proprietary to Apple; only Apple tools can modify the list, and only Apple tools can generate a SecureToken.

While the SecureToken-endowed users and the cryptographic users are usually in sync on a particular volume, these lists are decoupled, and it is possible to get them out of sync. If you clone a system to a pre-encrypted APFS volume, for example, the destination has only one "Disk" crypto user. None of the user accounts on the system that you copied will be (nor can be) included in the crypto users list of that volume. Likewise, if you clone an installation of macOS to a volume that already has an installation of macOS, then you will be overwriting the user accounts that are currently in the crypto user list with new, foreign user accounts. Those new user accounts are not only missing from the crypto user list, but it will be impossible to add them to the crypto user list if all of the previous crypto users were deleted. To avoid both of these scenarios, it's important to clone to a volume that has either crypto users that match those users that exist on the source, or to a destination that has no crypto users at all (e.g. a freshly erased, non-encrypted volume).

Manually regenerating a SecureToken

Apple does not offer a method for creating a SecureToken for a user 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 in a very limited number of circumstances. If the current startup disk has no crypto users (diskutil ap listUsers / returns "No cryptographic users"), or if one of the crypto users is still present on the current startup disk, then you can use the sysadminctl utility to generate a SecureToken for your administrator account, e.g. in the Terminal application:

sysadminctl interactive -secureTokenOn yourname -password -

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

Related Apple Bug Reports

  • rdar://46168739 — diskutil updatePreboot doesn't remove deleted crypto users

My YubiKey authentication device can't unlock my encrypted backup volume on startup

YubiKey users discovered that the default keystroke input speed of the Yubikey is too fast for the Mac's firmware, resulting in dropped characters. You can solve this by decreasing the key input rate using the YubiKey Manager.