- Can I back up an encrypted volume to a non-encrypted volume?
- If I back up an encrypted volume to a non-encrypted volume, will the copied files be encrypted on the destination?
- Will Carbon Copy Cloner enable encryption on my backup volume?
- Do I have to wait for encryption to complete before rebooting from my production volume?
- What happens if I change my account password on the source volume? Does the encryption password on the backup volume get updated automatically?
- I enabled encryption on my 3TB USB backup disk. Why can't I boot from that volume any more?
- I formatted my destination as encrypted, and it's bootable. Why do you recommend cloning to a non-encrypted volume first?
- I restored my backup to another Mac that had FileVault enabled, and now I can't unlock the cloned volume.
- The Startup Security Utility may not work correctly after restoring to an encrypted-at-rest volume on an iMac Pro
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.
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.
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:
- 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.
- Open the Users & Groups preference pane in the System preferences application.
- 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.
- Reset the password for any other user accounts whose password was reset on the original source.
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
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:
- Erase the destination device (unencrypted!)
- Click on the freshly-erased disk in CCC's sidebar and create a recovery volume on that disk
- 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.
- 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.
The Startup Security Utility may not work correctly after restoring to an encrypted-at-rest volume on an iMac Pro
The iMac Pro (and presumably new hardware that Apple announces in the future) supports 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. That encryption 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 creating the token on the current startup disk, and also for granting access to that 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 create the secure access token and grant access to it to your user account (replace "yourname" with the short name of your user account):
sysadminctl interactive -secureTokenOn yourname -password -