Aller au contenu principal

Frequently Asked Questions about encrypting the backup volume

  • Mise à jour

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

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

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.

I restored my backup to another Mac that had FileVault enabled, and now I can't unlock the restored 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 copy 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 backing up to an APFS volume that previously had FileVault enabled, the destination can't be unlocked on startup

After backing up 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 backup 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 copy 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 copy 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 copy 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 backup 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. 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.