Quantcast
Channel: Carbon Copy Cloner | Bombich Software - Advanced Topics
Viewing all 257 articles
Browse latest View live

What is CCC's Privileged Helper Tool?

$
0
0
Product: 
ccc5

At its core, Carbon Copy Cloner is a product that is designed to make bootable backups of your Mac's operating system. In order for CCC to be able to make copies of system files, CCC needs to have the privilege of copying files that can't be read nor written by just any user – CCC requires elevated privileges to copy macOS system files. Likewise, CCC is often tasked with copying the data associated with multiple users. macOS prevents you from accessing files that belong to other users. If you, as the administrator of the Mac, want CCC to back up everybody's files, then again, CCC requires elevated privileges.

Acquiring elevated privileges on macOS

There are a few different ways to perform a task on macOS with elevated privileges. The simplest – and least secure – method to do this would be to prompt the user to authenticate when he opens the application, and then relaunch the application as the "root" user. The application would then have all of the privileges it needs. This would grant far too much privilege, though, because it also gives the user (or malware that is exploiting the application) privileged access to other users' files.

A better way to securely acquire elevated privileges is to isolate the code that requires those privileges into a separate, "faceless" application. This is a common practice known as privilege separation. Even here, though, there is a right way and a wrong way for the isolated application to gain elevated privileges. The antiquated technique is for the parent application to ask for administrator authentication, then change the owner of the privileged application to the root user, then set a special mode on that application that allows that application to run with the privileges of the owner of the application (root). While this is a popular technique on Linux and much, much older versions of Mac OS X, there is still a significant potential vulnerability with this approach – any user can open that privileged application and potentially use it as a puppet to perform privileged tasks. Apple specifically discourages this practice:

Note: Older software sometimes sets the setuid and setgid bits for the executable file, and sets the owner and group of the file to the privilege level it needs (often with the root user and the wheel group). Then when the user runs that tool, it runs with the elevated privileges of the tool’s owner and group rather than with the privileges of the user who executed it. This technique is strongly discouraged because the user has the ability to manipulate the execution environment by creating additional file descriptors, changing environment variables, and so on, making it relatively difficult to do in a safe way.

Adhering to a higher standard of security

Starting in Mac OS X 10.6 (Snow Leopard), Apple introduced a more secure paradigm for performing tasks with elevated privileges. Rather than blindly granting privileged access to an application, developers can ask the system to install a "privileged helper tool". macOS then invokes the privileged helper tool on demand, and the calling application can only communicate with the helper when it has met stringent requirements:

  • The calling application and the privileged helper tool must be code signed (and valid)
  • The calling application must be one of the applications that is specifically approved to make requests to that specific helper
  • The calling application must have a valid authorization reference

These requirements prevent unauthorized use of the helper tool and they prevent maliciously modified applications from making requests to the helper tool.

CCC has leveraged a privileged helper tool since version 3 and Mac OS X Snow Leopard – right from the start. This architecture is not only more secure and future-proof than using setuid binaries, it also affords us, for example, the ability to perform backup tasks when no users are logged in to the system.

Related Documentation


Downgrading an APFS-formatted Fusion volume from Mojave

$
0
0
Product: 
ccc5

If you upgraded your Mac to macOS Mojave and have decided to downgrade for one reason or another, the procedure is usually pretty straightforward. Fusion volumes, however, introduce a complication. Upon upgrading to Mojave, a Fusion volume will be converted from HFS+ to APFS. If you want to downgrade to High Sierra (or any earlier OS), you must reformat that Fusion volume as HFS+. Because APFS Fusion volumes are not handled gracefully by High Sierra, however, the procedure is a bit tedious. The following steps will help you downgrade your Mojave Fusion volume to High Sierra.

Warning: These instructions will permanently delete the contents of the two devices that belong to your Mac's internal Fusion device. If you're uncomfortable with any of the steps in this process, please don't hesitate to ask us for help.

  1. Boot from your CCC bootable backup that you intend to restore from (e.g. macOS High Sierra or earlier).
  2. Choose "About this Mac" from the Apple menu to verify that your Mac is booted from your backup volume.
  3. Open Disk Utility.
  4. Choose "Show all devices" from the View menu.
  5. Identify the two devices that belong to the APFS Fusion volume. Typically one will be an SSD and the other will be an HDD, and both should be in the "Internal Devices" section of Disk Utility's sidebar.
  6. Erase the SSD Fusion member as "Mac OS Extended, Journaled". Name it "FusionSSD" so it's easy to identify later.
  7. Erase the HDD Fusion member as "Mac OS Extended, Journaled". Name it "FusionHDD" so it's easy to identify later.
  8. Quit out of Disk Utility.
  9. Open Carbon Copy Cloner.
  10. Click on the "FusionHDD" disk in CCC's sidebar.
  11. Click the "Recovery HD..." button at the bottom of the window.
  12. Click the "Create Recovery HD" button. If that button is disabled, don't worry – this step isn't essential.
  13. Quit out of CCC
  14. Open the Terminal application, type the following command, then press the Return key:
    diskutil list
  15. In the list of devices and volumes, find and make a note of the device identifier (in the IDENTIFIER column) associated with FusionSSD and FusionHDD. For FusionSSD, we will use the whole device identifier, e.g. disk1, whereas for the FusionHDD, we will use the volume device identifier, e.g. disk5s2.
  16. Type the following command in the Terminal, substituting the device identifiers noted in the previous step, then press the Return key:
    diskutil cs create "Macintosh HD"SSD_Whole_Device_IdentifierHDD_volume_identifier
  17. The previous command will create an empty Fusion device, and print out a "Logical Volume Group" identifier. Select that identifier and copy it to the clipboard.
  18. Type the following command in the Terminal, substituting the logical volume group identifier noted in the previous step, then press the Return key:
    diskutil cs createVolume Logical_Volume_Group JHFS+ "Macintosh HD" 100%
  19. Quit out of the Terminal application.
  20. Open Carbon Copy Cloner.
  21. Create and run a new task, specifying your backup disk as the source and the new "Macintosh HD" Fusion volume as the destination.
  22. When the restore task is complete, open the Startup Disk Preference Pane in the System Preferences application. Reset the startup disk to Macintosh HD, then reboot.

Frequently asked questions about scheduled tasks

$
0
0
Product: 
ccc5

Does CCC have to be running for a scheduled task to run?

No. Once you have saved your tasks, you can quit CCC. Even if tasks are running, it's OK to quit CCC -- they will continue to run. A helper application, named "com.bombich.ccchelper" will be running quietly in the background, handling task operations. This helper application also loads automatically when you restart your computer, so you don't have to launch CCC again unless you want to make changes to your task configurations or scheduling.

What happens if no one is logged in when a task is scheduled to run?

The scheduled task will run whether someone is logged in to the machine or not. You can also log in or log out while tasks are running and the tasks will continue to run.

Will CCC run when the computer is turned off?

If your backup task is configured to "Wake or power on the system", CCC will schedule a "Wake or power on" event with the Power Management service and your system will turn on shortly before the task is scheduled to run.

FileVault exception

There is one notable exception to powering on the system for a scheduled task: If you have FileVault enabled on your startup disk, your computer would turn on, but it would not proceed past the FileVault authentication prompt. It is not possible for CCC to subvert this security feature, so the Wake or power on the system option will be disabled if FileVault is enabled on your startup disk. This limitation is applicable only when the system is turned off; CCC can wake a system with FileVault protection enabled and proceed to run a backup task.

Related Documentation

Will CCC run when the my laptop's lid is closed?

If your laptop is running on battery power, the system will not wake while the lid is closed and CCC backup tasks will not run. If your laptop is plugged in to AC power, then CCC can wake the system to start your scheduled task if the lid is closed. See the section above for the settings that indicate whether a task can wake the system.

How is system sleep handled?

By default, CCC will wake your computer when your tasks are scheduled to run. You can change this setting in the Runtime Conditions section when scheduling a task. As long as your Mac is running on AC power, CCC will prevent the system from sleeping for the duration of a backup task.

Related Documentation

Why does my laptop sometimes go to sleep during a backup task?

If your Mac is a laptop, note that CCC will only be able to wake the system or prevent idle sleep if the system is running on AC power. CCC will attempt to thwart sleep while the system is running on battery power, but macOS may sleep the system anyway if there is no user activity while running on battery power.

Why does my screen turn on shortly before a backup task starts?

By default, CCC schedules a wake event to occur 20 seconds before a scheduled task is configured to run. Whether the system is sleeping or not, macOS turns on the display when a scheduled wake event occurs, and there is nothing that CCC can do to prevent this. If you prefer that your display does not turn on, e.g. in the middle of the night, use the Run this task when the system next wakes setting instead to have CCC tasks run during macOS Dark Wake cycles (aka PowerNap, aka Maintenance Wake).

What if the backup disk is not available when a task is scheduled to run?

If your backup disk is attached to your Mac and unmounted, CCC will attempt to mount the backup volume, then proceed with the backup task if that is successful. If the volume cannot be mounted or is not attached to your Mac, CCC will, by default, report an error, then run the task immediately when the backup disk is reattached to your Mac. You can fine-tune CCC's handling of this scenario using the options at the bottom of the Scheduler panel.

Can I stop a backup task before it finishes?

Yes, you can stop the backup task at any time. The next time you run the backup task, CCC will copy only the files that have changed or were missed since the last backup task.

How can I disable/suspend a task?

If CCC's sidebar is not revealed, reveal it by choosing Show Sidebar from CCC's View menu. To disable a task, right-click on that task in the sidebar and choose Disable from the contextual menu. Use the same procedure to re-enable the task. If you would like to disable all tasks, choose Disable all tasks... from the CCC menubar application, or hold down Command+Option and choose Disable All Tasks & Quit from the Carbon Copy Cloner menu.

Can I configure a task to run immediately after the computer is turned on?

CCC doesn't offer an option specifically to run tasks on startup. Running a task immediately after the system is turned on often introduces a lot of extra disk activity that will compete with the disk activity that occurs normally during system startup. Also, it makes less sense to run backup tasks after the computer has been off, because no files have been modified while the system was off. We recommend configuring backup tasks to run sometime toward the end of your work day instead. You can also configure the task to shut down your Mac when the task completes.

If your work day does not end at a regular time, but begins at a fairly consistent time, then there may be one other option available to you. You can configure a backup task to run before your work day begins, and then configure that task to "Wake or power on the system". CCC will then schedule a "wake or power on" energy saver event, and then after the system powers on at that time, CCC will run your scheduled task. Note that this option is not available if you have FileVault enabled on your Mac's startup disk.

Related Documentation

Performance Suggestions

$
0
0
Product: 
ccc5

There are several factors that affect the performance of your backup tasks. Here we describe the most common conditions that affect backup performance, and offer some suggestions for mitigating the effects of those conditions.

Reduce the number of files considered for backup

CCC analyzes all of the files that are included in your backup set for consideration to be copied. If you have a particularly high number of files on your source volume, you may want to put some thought into how your files are organized. For example, if you have a large number of files that never change (perhaps some old, completed projects), you can collect these into a folder named "Archives", back it up once, then exclude it from future backups. CCC will not delete excluded items from your destination (unless you ask it to using Advanced Settings), so as long as you keep the original on your source volume, you will always have two copies of your archived content. Because these items are excluded from your daily backups, CCC will not spend time or RAM enumerating through those files for changes.

Related Documentation

Hard drive performance and interface bandwidth

Performance will be worse for smaller rotational hard drives (e.g. physically smaller, like those in 2.5" hard drive enclosures), for older hard drives, and for hard drives that are nearly full and thus more likely to be fragmented. You will also get longer copy times when you have lots of small files vs. a volume filled with just a few very large files. Finally, you will see better performance with faster/more efficient interfaces — Thunderbolt is faster than Firewire, Firewire 800 is faster than USB 2.0, etc.

When you consider purchasing an external hard drive for backup, we recommend enclosures that have multiple interfaces (e.g. Firewire and USB, or Thunderbolt and USB). Depending on how you use the Firewire or USB interfaces on your Mac, you may find that you get better performance or reliability when trying a different interface on your external backup disk. Additionally, if your source volume is nearly full, we recommend that you replace it with a larger hard drive to avoid the performance implications of filesystem fragmentation.

Filesystem performance and hardware type

It's important to choose the right filesystem for the hardware that you have. If you have an older, rotational HDD, you should format that device using the "Mac OS Extended, Journaled" (HFS+) format. APFS is the new, modern standard, but its performance on rotational devices is inferior to HFS+. Apple still recommends HFS+ for rotational HDD devices, and that's our recommendation as well.

Spotlight Indexing

Anything that causes CCC to compete for bandwidth to your source or destination volume will increase the amount of time that it takes to back up your data. Spotlight indexing is one such process that CCC typically must compete with for disk bandwidth. As you copy new data to your destination volume, for example, Spotlight wants to read those "new" files so it can index their contents. Having a Spotlight index of your backup volume may be unnecessary as you probably want to search for files only on your source volume. To disable Spotlight indexing on a volume that is dedicated to backup, drag the icon of the destination volume into the "Privacy" tab of Spotlight Preference Pane in the System Preferences application. If you do want the backup volume indexed, drag its icon out of the "Privacy" tab after the cloning and indexing will start immediately.

Find and replace corrupted files

CCC offers an advanced option to "Find and replace corrupted files". When using this option, CCC will re-read every file on the source and every file on the destination, calculating a checksum of each file. CCC then compares these checksums to see if a file should be recopied. While this is an excellent method for finding unreadable files on the source or destination, it will dramatically increase the amount of time that your backup task takes, and it will also increase CPU and hard drive bandwidth consumption on your Mac. We recommend limiting the use of this option to weekly or monthly, and scheduling such tasks to run when you are not typically using your Mac.

Other applications and conditions that can lead to performance problems

Over the years we have received numerous queries about poorer performance than what is expected. Careful analysis of the system log and Activity Monitor will usually reveal the culprit. Here are some things that we usually look for:

  • Other backup software copying simultaneously to the same volume, a different volume on the same disk, or across the same interface as CCC's destination.
  • Utilities that watch filesystem activity and do things when file changes are detected. Antivirus software is a common culprit, but we have also seen problems caused by other watcher applications, such as memeod and Western Digital's SmartWare.
  • Slow interfaces — USB hubs (including the ports on a USB keyboard or display) and even some USB cables can reduce the bandwidth to your disk dramatically. If you're using USB, be sure that your device is plugged directly into one of the USB ports on your Mac.
  • Daisy chaining Firewire devices is usually OK, though some enclosures can stall the entire Firewire bus when given too much bandwidth. If you see this behavior, try switching the order of devices in the chain, or attach your backup disk directly to a Firewire port on your Mac.
  • Using a wireless network connection to connect to a network volume. If you're seeing poor performance with a wireless connection, compare the performance when using a wired (ethernet) connection.

Use the Console application to view the contents of the system log. If you're still having trouble identifying a performance problem, we're here to help.

Related Documentation

Working with FileVault Encryption

$
0
0
Product: 
ccc5

CCC is fully qualified for use with FileVault-protected volumes (HFS+ and APFS). CCC offers some advice around enabling encryption in the Disk Center.

Enabling encryption on a volume that contains (or will contain) an installation of macOS

If your goal is to create a bootable, encrypted backup, use the following procedure:

  1. Follow CCC's documentation to properly format the destination volume. Do not format the volume as encrypted.
  2. Use CCC to back up your startup disk to the unencrypted destination volume.
  3. Click on the destination volume in CCC's Disk Center, then click the Recovery HD button to create a Recovery HD volume. Note: You must be logged in to an administrator account to perform this step. [This step is unnecessary if your destination is an APFS-formatted volume]
  4. Open the Startup Disk preference pane and restart your Mac from backup volume.
  5. Enable FileVault encryption in the Security & Privacy preference pane of the System Preferences application.
  6. Reboot your Mac (it will reboot from the backup volume).
  7. Open the Startup Disk preference pane and restart your Mac from your production startup volume.
  8. Configure CCC for regular backups to your encrypted backup volume.

Note: You do not have to wait for the conversion process to complete before using the backup disk. Additionally, you do not have to remain booted from the backup disk for the conversion process to complete. You can simply enable FileVault encryption, then immediately reboot from your primary startup disk and the conversion process will carry on in the background. Encryption will continue as long as the backup disk is attached. macOS doesn't offer a convenient method to see conversion progress, but you can type diskutil apfs list (or diskutil cs list if the applicable volume is HFS+ formatted) in the Terminal application to see conversion progress. Some users have found that conversion may not resume until you log in to an admin account while booted from your production startup volume, so try that if conversion appears to be stalled.

What if I don't want my personal data to ever be on the destination in unencrypted form?

Enabling FileVault on the destination means that the volume starts out unencrypted, and then over the course of several hours the data is encrypted in place. If the encryption conversion process completes successfully, then no trace of the encrypted data will be left on that disk. If the conversion process fails for any reason, however, then the data on that disk is potentially recoverable. If this is not acceptable, then we recommend that you exclude any sensitive data from the initial backup task. Don't exclude your whole home folder — you must include at least one folder from your home directory so that you can log in to that account on the backup. After you have booted from the backup volume and enabled FileVault, you can then reboot from the production startup disk, remove the exclusions from your backup task, then run the backup task again to copy the remainder of your data. Any data that is copied to a volume that is in the midst of encryption conversion will be encrypted immediately.

Enabling encryption on a volume that will not contain an installation of macOS

If your backup volume won't be a bootable backup of macOS, simply right-click on that volume in the Finder and choose the option to encrypt the volume. If your Mac is running macOS High Sierra or later, please note that macOS will convert an HFS+ formatted volume to APFS when you enable encryption in this manner.

Finder option

Related Documentation

Frequently Asked Questions about encrypting the backup volume

$
0
0
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 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 -

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.  
  3. Click on the FileVault tab
  4. Click the padlock icon in the lower-left corner to allow changes
  5. Click on the "Turn on FileVault..." button
  6. Choose the option to "Create a recovery key and do not use my iCloud account"
  7. 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.
  8. Click the Cancel button, then quit the System Preferences application

Restoring from a disk image

$
0
0
Product: 
ccc5

You can access the contents of a disk image the same way that you access other volumes and external hard drives on macOS. Double-click on the disk image file to mount its filesystem, then navigate the filesystem in the Finder to access individual files and folders. If you have the permission to access the files that you would like to restore, simply drag those items to the volume that you would like to restore them to.

Restoring individual items or an entire disk image to another hard drive using CCC

While you cannot boot macOS from a disk image directly, you can restore the disk image to a volume. When you use CCC to restore the disk image to a volume, the resulting restored volume will be bootable (assuming that you had initially backed up a bootable system). To restore files or an entire filesystem from a disk image:

  1. Launch CCC
  2. Select Restore from disk image... from the Source selector and locate your backup disk image. CCC will mount the disk image for you.
  3. Choose a volume from the Destination selector. You may choose the startup disk as a destination, but CCC will not permit you to restore system files to the currently-running OS.
  4. If you do not want to restore everything, choose Some files... from the Clone menu (below the Source selector) and deselect any item that you do not wish to restore.
  5. Click the Clone button. The files will be restored to their original locations.

Restoring system files to your startup disk

If you want to restore system files to your startup disk, you must start up your Macintosh from an installation of macOS on another hard drive, such as a bootable backup created by CCC. Once you have booted your Mac from another volume, follow the steps from the previous section.

Restoring system files to your startup disk when you don't have a bootable backup

If you do not have an installation of macOS on another hard drive, you can boot your Mac from your macOS Recovery volume and use Disk Utility to restore the entire disk image:

High Sierra and Mojave

Note: The destination volume format must match the format of the disk image that you're restoring from. This limitation is specific to Disk Utility – if you're restoring from a disk image using CCC, CCC can restore an APFS disk image to an HFS+ volume, and you can restore an HFS+ disk image to an APFS volume. Use Disk Utility as a last resort.

  1. Hold down Command+R while you restart your computer.
  2. Choose Disk Utility in the Utilities application.
  3. Choose Show All Devices from the View menu.
  4. Click on the device you want to restore to in the sidebar (see this article for specific formatting instructions).
  5. Click the Erase button in the toolbar and proceed to erase the device using the GUID Partition Map partitioning scheme, and the format that matches your source disk image.
  6. Reselect the volume that you would like to restore to. If you are restoring to an APFS volume, choose the parent APFS container.
  7. Choose Open Disk Image... from the File menu and select the disk image file that you would like to restore from.
  8. Choose Restore... from the Edit menu.
  9. Select the mounted disk image volume that you would like to restore. If you are restoring to an APFS volume, choose the container that is the parent of the disk image volume you are trying to restore.
  10. Click the Restore button.

El Capitan and Sierra

  1. Hold down Command+R while you restart your computer
  2. Choose Disk Utility in the Utilities application
  3. Click on the volume you want to restore to in the sidebar
  4. Choose Restore... from the Edit menu
  5. Click on the Image... button and locate the disk image that you would like to restore
  6. Click the Restore button

Yosemite

  1. Hold down Command+R while you restart your computer
  2. Choose "Disk Utility" in the Utilities application
  3. From the File menu, choose Open Disk Image... and locate the disk image that you would like to restore
  4. In the list in the pane on the left, click on the mounted disk image's volume
  5. Click on the Restore tab on the right side of the window
  6. Drag the mounted disk image to the Source field. If the Source field does not accept the dragged volume, right-click on the disk image's mounted volume and choose Set as source from the contextual menu.
  7. Drag the hard drive that you would like to restore to into the Destination field
  8. Check the box to erase the destination (if present), then click on the Restore button.
  9. Restart your Mac from your newly restored volume, then use CCC to restore the Recovery HD volume from the archive on your startup disk.

Using Migration Assistant to migrate data from a disk image

If you have a clean installation of macOS and simply want to restore your user data from a full-system backup on a disk image, you can use Migration Assistant for this task. Simply mount the disk image, then open Migration Assistant and proceed as directed, using the mounted disk image as the source. Note that Migration Assistant will only accept a disk image that has a full system backup, it will not accept a disk image that has only user data.

Migration Assistant and Yosemite, El Capitan

On Yosemite and El Capitan, Migration Assistant will ask that you close all applications, and it will then log you out before presenting migration options. This poses a problem for migrating data from a disk image because the disk image will be unmounted when you are logged out, and Migration Assistant doesn't offer any interface to choose a disk image. To work around this problem, you can use our Mount disk image for Migration Assistant application. Simply drag the disk image containing your full system backup onto the application and it will guide you through a fairly simple procedure that will make the disk image available to Migration Assistant after a short delay.

Preliminary tests indicate that this workaround is not required on Sierra and later OSes.

Advanced Settings

$
0
0
Product: 
ccc5

CCC's Advanced Settings are helpful in specific situations, but are not generally required for routine use. Some of these settings involve more risk, so please use them with caution, and don't hesitate to ask questions via the Ask a question about CCC... menu item in CCC's Help menu if the explanations below are insufficient for your particular scenario.

To access the advanced settings, click on the Advanced Settings button below CCC's Source selector.

Advanced settings button

Use strict volume identification

By default, CCC uses the name and Universally Unique Identifier (UUID) of your source and destination to positively identify those volumes. By verifying both of these identifiers, there is less risk in, for example, backing up to a volume that has the same name as your usual destination but is not actually the destination.

While beneficial, this behavior can sometimes have the wrong result. For example, if you rotate between a pair of external hard drives, CCC will not backup to both of them even though they have the same name (e.g. Offsite Backup). CCC will instead claim that the UUID of one of the volumes does not match that of the originally chosen destination.

To accommodate a "rotating pair of backup volumes" solution, you can uncheck this option to indicate that CCC should only use the volume name to identify the destination volume. When deselecting this option, be vigilant that you do not rename your destination volume and that you never attach another non-backup volume to your Mac that is named the same as your destination volume.

This option is automatically disabled when the destination volume does not have a UUID. Network volumes and some third-party filesystems, for example, do not have volume UUIDs.

Note: This setting is only applicable to the destination volume. CCC always uses the name and UUID to positively identify the source volume.

Note: If your rotating destination volumes are encrypted, CCC will only be able to unlock and mount the original encrypted volume selected as the destination for your backup task. CCC must have a unique identifier of the destination volume in order to unlock that volume, and CCC will only retain that information about one destination volume for a particular task. If you would like to rotate a pair of backup disks that are encrypted, we recommend using two separate tasks for that purpose; one for each encrypted destination.

Protect root-level items

If you have files and folders on your destination volume that you would like to be left alone, yet you want to keep your backup "clean", use the Protect root-level items option. This option is enabled by default when CCC's SafetyNet option is enabled. To understand how this feature works, suppose you have these items on your source volume:

And you have these items on the destination volume:

With the Protect root-level items option, the Videos folder will not be moved to the _CCC SafetyNet folder because it is unique to the root level of the destination. The Users folder is not unique to the root of the destination, though, so its contents will be updated to match the source. As a result, the olduseraccount folder will be moved to the _CCC SafetyNet folder (or deleted if you have disabled the SafetyNet).

Find and replace corrupted files, "Backup Health Check"

CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. If the checksums differ ,CCC will recopy the file. This option will increase your backup time, but it will expose any corrupted files within your backup set on the source and destination.

Media failures occur on nearly every hard drive at some point in the hard drive's life. These errors affect your data randomly, and go undetected until an attempt is made to read data from the failed sector of media. If a file has not been modified since a previous (successful) backup, CCC will not ordinarily attempt to read every byte of that file's content. As a result, it is possible for a corrupted file to go unnoticed on your source or destination volume. Obviously this is a concern if the file is important, and one day you actually need to recover the contents of that file.

Frequent use of the checksum calculation option is unnecessary and may be a burden upon your productivity, so CCC offers weekly and monthly options to limit how frequently the checksumming occurs. 

Note: CCC will never replace a valid file on your destination with an unreadable, corrupt file from the source. If CCC cannot read a file on your source volume, any existing backup of that file will remain intact on your backup volume and CCC will report an error, advising you to replace the source file with the intact backup version. The Find and replace corrupted files setting will only automatically replace corrupted files on the destination, and only when the source file is completely readable.

What is a "corrupted" or "unreadable" file?

With regard to files on the source, CCC's Find and replace corrupted files option specifically refers to files that cannot be physically read from the disk. It does not refer to files that have been mistakenly or maliciously altered such that they cannot be opened by the application that created them.

Using the "Find and replace corrupted files" option to verify your backup

CCC's checksum option verifies the integrity of the files on your destination volume before files are copied, it is not a verification of files that have just been written. In general, the checksum of a file immediately after it is written to disk is of questionable value. Most disks have a write cache, and file data goes to the cache before it is written to actual media. If you write a file and then immediately ask to read it back, as much as x amount of data (where x = the size of the cache) is going to come from the volatile cache. If any of the file's data comes from the write cache, then the checksum doesn't reflect the status of the data on the permanent media, and that really defeats the purpose of checksumming the file in the first place.

If you want to verify the integrity of the files on your destination immediately after copying files, a subsequent backup with CCC's Find and replace corrupted files option is the best way to do that. You can even automate this process by creating a second task that uses this option, then select the second task in the "Run another backup task" popup menu in the After task runs section of advanced settings.

Troubleshooting Options

Run a deletion pass first

When the CCC SafetyNet option is disabled, CCC typically deletes unique items from the destination as it encounters them. CCC iterates through the folders on your source alphabetically, so some files are often copied to the destination before all of the files that will be deleted have been deleted from the destination. If your destination volume has very little free space, CCC may not be able to complete a backup to that volume. This option will cause CCC to run a deletion pass through the entire destination before copying files. Use of this option will make your backup task take longer.

This option will only be enabled when the SafetyNet option is disabled.

Don't update newer files on the destination

Files on the source are generally considered to be the authoritative master, and CCC will recopy a file if the modification date is at all different — newer or older — on the source and destination. Occasionally there are circumstances where the modification date of files on the destination is altered after a backup task runs (e.g. by anti-virus applications), and this alteration causes CCC to copy these files every time. This option can work around these circumstances when the root cause of the modification date alteration cannot be addressed.

Don't preserve permissions

This setting will avoid the errors generated by network volumes that disallow the modification of permissions and ownership on some files. It will also prevent CCC from enabling ownership on the destination volume. Use of this option while backing up applications or macOS system files will prevent those items from working correctly on the destination.

Don't preserve extended attributes

This setting will disable support for reading and writing extended attributes, such as Finder Info, resource forks, and other application-proprietary attributes. Extended attributes store data about the file. Apple explicitly recommends that developers do not store irreplaceable user data in extended attributes when saving a file, because extended attributes are not supported by every filesystem, and could be silently dropped (e.g. by the Finder) when copying a file.

This option is helpful in cases where the source or destination filesystem offers exceptionally poor performance for reading and writing extended attributes, or offers very limited support for macOS native extended attributes such that many errors are reported when trying to copy these metadata.

Related Documentation


Performance Suggestions

$
0
0
Product: 
ccc5

There are several factors that affect the performance of your backup tasks. Here we describe the most common conditions that affect backup performance, and offer some suggestions for mitigating the effects of those conditions.

Reduce the number of files considered for backup

CCC analyzes all of the files that are included in your backup set for consideration to be copied. If you have a particularly high number of files on your source volume, you may want to put some thought into how your files are organized. For example, if you have a large number of files that never change (perhaps some old, completed projects), you can collect these into a folder named "Archives", back it up once, then exclude it from future backups. CCC will not delete excluded items from your destination (unless you ask it to using Advanced Settings), so as long as you keep the original on your source volume, you will always have two copies of your archived content. Because these items are excluded from your daily backups, CCC will not spend time or RAM enumerating through those files for changes.

Related Documentation

Hard drive performance and interface bandwidth

Performance will be worse for smaller rotational hard drives (e.g. physically smaller, like those in 2.5" hard drive enclosures), for older hard drives, and for hard drives that are nearly full and thus more likely to be fragmented. You will also get longer copy times when you have lots of small files vs. a volume filled with just a few very large files. Finally, you will see better performance with faster/more efficient interfaces — Thunderbolt is faster than Firewire, Firewire 800 is faster than USB 2.0, etc.

When you consider purchasing an external hard drive for backup, we recommend enclosures that have multiple interfaces (e.g. Firewire and USB, or Thunderbolt and USB). Depending on how you use the Firewire or USB interfaces on your Mac, you may find that you get better performance or reliability when trying a different interface on your external backup disk. Additionally, if your source volume is nearly full, we recommend that you replace it with a larger hard drive to avoid the performance implications of filesystem fragmentation.

Filesystem performance and hardware type

It's important to choose the right filesystem for the hardware that you have. If you have an older, rotational HDD, you should format that device using the "Mac OS Extended, Journaled" (HFS+) format. APFS is the new, modern standard, but its performance on rotational devices is inferior to HFS+. Apple still recommends HFS+ for rotational HDD devices, and that's our recommendation as well.

Spotlight Indexing

Anything that causes CCC to compete for bandwidth to your source or destination volume will increase the amount of time that it takes to back up your data. Spotlight indexing is one such process that CCC typically must compete with for disk bandwidth. As you copy new data to your destination volume, for example, Spotlight wants to read those "new" files so it can index their contents. Having a Spotlight index of your backup volume may be unnecessary as you probably want to search for files only on your source volume. To disable Spotlight indexing on a volume that is dedicated to backup, drag the icon of the destination volume into the "Privacy" tab of Spotlight Preference Pane in the System Preferences application. If you do want the backup volume indexed, drag its icon out of the "Privacy" tab after the cloning and indexing will start immediately.

Find and replace corrupted files

CCC offers an advanced option to "Find and replace corrupted files". When using this option, CCC will re-read every file on the source and every file on the destination, calculating a checksum of each file. CCC then compares these checksums to see if a file should be recopied. While this is an excellent method for finding unreadable files on the source or destination, it will dramatically increase the amount of time that your backup task takes, and it will also increase CPU and hard drive bandwidth consumption on your Mac. We recommend limiting the use of this option to weekly or monthly, and scheduling such tasks to run when you are not typically using your Mac.

Target Disk Mode is slow

In fact it's unbelievably slow. If you attach an SSD-bearing Mac in Target Disk Mode to another Mac via a USB-C cable (so both at 10Gb/s connections), you might expect to get incredible speed (e.g. >500MB/s). You will be sorely disappointed by speeds of less than 20MB/s; slower than USB 2.0. For better performance, we recommend that you avoid Target Disk Mode. Boot the target Mac from the volume you're trying to restore instead. Not only will you get better performance, but you also have the assurance that the Mac can boot from the OS that you're restoring to it.

Other applications and conditions that can lead to performance problems

Over the years we have received numerous queries about poorer performance than what is expected. Careful analysis of the system log and Activity Monitor will usually reveal the culprit. Here are some things that we usually look for:

  • Other backup software copying simultaneously to the same volume, a different volume on the same disk, or across the same interface as CCC's destination.
  • Utilities that watch filesystem activity and do things when file changes are detected. Antivirus software is a common culprit, but we have also seen problems caused by other watcher applications, such as memeod and Western Digital's SmartWare.
  • Slow interfaces — USB hubs (including the ports on a USB keyboard or display) and even some USB cables can reduce the bandwidth to your disk dramatically. If you're using USB, be sure that your device is plugged directly into one of the USB ports on your Mac.
  • Daisy chaining Firewire devices is usually OK, though some enclosures can stall the entire Firewire bus when given too much bandwidth. If you see this behavior, try switching the order of devices in the chain, or attach your backup disk directly to a Firewire port on your Mac.
  • Using a wireless network connection to connect to a network volume. If you're seeing poor performance with a wireless connection, compare the performance when using a wired (ethernet) connection.

Use the Console application to view the contents of the system log. If you're still having trouble identifying a performance problem, we're here to help.

Related Documentation

Frequently Asked Questions about encrypting the backup volume

$
0
0
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 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

Advanced Settings

$
0
0
Product: 
ccc5

CCC's Advanced Settings are helpful in specific situations, but are not generally required for routine use. Some of these settings involve more risk, so please use them with caution, and don't hesitate to ask questions via the Ask a question about CCC... menu item in CCC's Help menu if the explanations below are insufficient for your particular scenario.

To access the advanced settings, click on the Advanced Settings button below CCC's Source selector.

Advanced settings button

Use strict volume identification

By default, CCC uses the name and Universally Unique Identifier (UUID) of your source and destination to positively identify those volumes. By verifying both of these identifiers, there is less risk in, for example, backing up to a volume that has the same name as your usual destination but is not actually the destination.

While beneficial, this behavior can sometimes have the wrong result. For example, if you rotate between a pair of external hard drives, CCC will not backup to both of them even though they have the same name (e.g. Offsite Backup). CCC will instead claim that the UUID of one of the volumes does not match that of the originally chosen destination.

To accommodate a "rotating pair of backup volumes" solution, you can uncheck this option to indicate that CCC should only use the volume name to identify the destination volume. When deselecting this option, be vigilant that you do not rename your destination volume and that you never attach another non-backup volume to your Mac that is named the same as your destination volume.

This option is automatically disabled when the destination volume does not have a UUID. Network volumes and some third-party filesystems, for example, do not have volume UUIDs.

Note: This setting is only applicable to the destination volume. CCC always uses the name and UUID to positively identify the source volume.

Note: If your rotating destination volumes are encrypted, CCC will only be able to unlock and mount the original encrypted volume selected as the destination for your backup task. CCC must have a unique identifier of the destination volume in order to unlock that volume, and CCC will only retain that information about one destination volume for a particular task. If you would like to rotate a pair of backup disks that are encrypted, we recommend using two separate tasks for that purpose; one for each encrypted destination.

Protect root-level items

If you have files and folders that are unique to the root-level on your destination volume and you want them to be left alone, yet you want to keep your backup "clean", use the Protect root-level items option. This option is enabled by default when CCC's SafetyNet option is enabled. To understand how this feature works, suppose you have these items on your source volume:

And you have these items on the destination volume:

With the Protect root-level items option, the Videos folder will not be moved to the _CCC SafetyNet folder because it is unique to the root level of the destination. The Users folder is not unique to the root of the destination (it also exists on the source), though, so its contents will be updated to match the source. As a result, the olduseraccount folder will be moved to the _CCC SafetyNet folder (or deleted if you have disabled the SafetyNet).

Find and replace corrupted files, "Backup Health Check"

CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. If the checksums differ ,CCC will recopy the file. This option will increase your backup time, but it will expose any corrupted files within your backup set on the source and destination.

Media failures occur on nearly every hard drive at some point in the hard drive's life. These errors affect your data randomly, and go undetected until an attempt is made to read data from the failed sector of media. If a file has not been modified since a previous (successful) backup, CCC will not ordinarily attempt to read every byte of that file's content. As a result, it is possible for a corrupted file to go unnoticed on your source or destination volume. Obviously this is a concern if the file is important, and one day you actually need to recover the contents of that file.

Frequent use of the checksum calculation option is unnecessary and may be a burden upon your productivity, so CCC offers weekly and monthly options to limit how frequently the checksumming occurs. 

Note: CCC will never replace a valid file on your destination with an unreadable, corrupt file from the source. If CCC cannot read a file on your source volume, any existing backup of that file will remain intact on your backup volume and CCC will report an error, advising you to replace the source file with the intact backup version. The Find and replace corrupted files setting will only automatically replace corrupted files on the destination, and only when the source file is completely readable.

What is a "corrupted" or "unreadable" file?

With regard to files on the source, CCC's Find and replace corrupted files option specifically refers to files that cannot be physically read from the disk. It does not refer to files that have been mistakenly or maliciously altered such that they cannot be opened by the application that created them.

Using the "Find and replace corrupted files" option to verify your backup

CCC's checksum option verifies the integrity of the files on your destination volume before files are copied, it is not a verification of files that have just been written. In general, the checksum of a file immediately after it is written to disk is of questionable value. Most disks have a write cache, and file data goes to the cache before it is written to actual media. If you write a file and then immediately ask to read it back, as much as x amount of data (where x = the size of the cache) is going to come from the volatile cache. If any of the file's data comes from the write cache, then the checksum doesn't reflect the status of the data on the permanent media, and that really defeats the purpose of checksumming the file in the first place.

If you want to verify the integrity of the files on your destination immediately after copying files, a subsequent backup with CCC's Find and replace corrupted files option is the best way to do that. You can even automate this process by creating a second task that uses this option, then select the second task in the "Run another backup task" popup menu in the After task runs section of advanced settings.

Troubleshooting Options

Run a deletion pass first

When the CCC SafetyNet option is disabled, CCC typically deletes unique items from the destination as it encounters them. CCC iterates through the folders on your source alphabetically, so some files are often copied to the destination before all of the files that will be deleted have been deleted from the destination. If your destination volume has very little free space, CCC may not be able to complete a backup to that volume. This option will cause CCC to run a deletion pass through the entire destination before copying files. Use of this option will make your backup task take longer.

This option will only be enabled when the SafetyNet option is disabled.

Don't update newer files on the destination

Files on the source are generally considered to be the authoritative master, and CCC will recopy a file if the modification date is at all different — newer or older — on the source and destination. Occasionally there are circumstances where the modification date of files on the destination is altered after a backup task runs (e.g. by anti-virus applications), and this alteration causes CCC to copy these files every time. This option can work around these circumstances when the root cause of the modification date alteration cannot be addressed.

Don't preserve permissions

This setting will avoid the errors generated by network volumes that disallow the modification of permissions and ownership on some files. It will also prevent CCC from enabling ownership on the destination volume. Use of this option while backing up applications or macOS system files will prevent those items from working correctly on the destination.

Don't preserve extended attributes

This setting will disable support for reading and writing extended attributes, such as Finder Info, resource forks, and other application-proprietary attributes. Extended attributes store data about the file. Apple explicitly recommends that developers do not store irreplaceable user data in extended attributes when saving a file, because extended attributes are not supported by every filesystem, and could be silently dropped (e.g. by the Finder) when copying a file.

This option is helpful in cases where the source or destination filesystem offers exceptionally poor performance for reading and writing extended attributes, or offers very limited support for macOS native extended attributes such that many errors are reported when trying to copy these metadata.

Related Documentation

Performing actions Before and After the backup task

$
0
0
Product: 
ccc5

Often when you have a backup task that runs on a scheduled basis, there are associated tasks that you would like to perform before or after files are actually copied. CCC offers the option to run shell scripts before and after a backup task, unmount or set the destination as the startup disk, run another CCC backup task, and power management options such as restart and shutdown. If you would like to perform any of these pre or post clone tasks, click the Advanced Settings button below CCC's Source selector.

Mounting the source or destination volume before a backup task begins

Without any additional configuration, CCC will attempt to mount your source and destination volumes before a backup task begins. This applies to many different volume types — ordinary volumes on locally-attached hard drives, disk images, network volumes, encrypted volumes – even encrypted volumes on remote Macs. If your source or destination volume is on a disk that is physically attached to your Mac (e.g. via Firewire, Thunderbolt, or USB), but it is not mounted, CCC can "see" that device and will attempt to mount it. If your source or destination is a network volume, CCC will obtain the credentials that you use to mount that device when you create the backup task, and will use those credentials to mount the volume before the task begins.

This also applies for nested volumes. For example, suppose you are backing up to a disk image on a network volume. CCC will first attempt to mount the network volume, then it will attempt to mount the disk image. Likewise, suppose you have a task configured to back up the contents of a folder on an encrypted volume. If you have saved the encrypted volume's passphrase in CCC's keychain, CCC will unlock and mount the encrypted volume before the backup task begins.

CCC's attempts to mount the source and destination volumes occur automatically before any other tasks, including pre clone shell scripts (described below), therefore it is not necessary to implement a shell script to pre-mount the source or destination.

Little Snitch may prevent the automated mounting of network volumes

If you're using Little Snitch to monitor and filter your inbound and outbound network traffic, you may find that CCC has trouble automatically mounting a network volume. If you run into this problem, configure Little Snitch to allow network access to the NetAuthSysAgent system service. NetAuthSysAgent is the macOS system service that fulfills application requests to mount network volumes.

SafetyNet Pruning

SafetyNet pruning is covered in more detail in this section of CCC's documentation.

Destination volume options

If you would like CCC to unmount your destination volume at the end of the backup task, choose Unmount the destination volume from the Destination volume management menu. If your destination is a folder, the text will be Unmount the underlying volume. If the destination is a disk image, CCC always unmounts the disk image volume, so this setting refers to the underlying physical volume upon which the disk image resides.

CCC will not forcefully unmount the destination volume. If an application has open files on the destination volume, CCC's attempt to unmount the volume will fail. CCC does not report this as an error, though it will make a note of it in the Task History window.

Yosemite users have an option to set the destination volume as the startup disk. Starting in El Capitan, however, Apple's System Integrity Protection prevents third-party applications from changing the startup disk setting. We do not recommend disabling System Integrity Protection to make this feature work, rather we recommend that you use the Startup Disk Preference Pane to change the startup disk selection.

Power management options

By default, at the end of a backup task, CCC will not perform any power management tasks. Instead, the system will perform as defined by the settings in the Energy Saver preference pane. For example, if you have the system configured to idle sleep after 20 minutes, the system will go to sleep if there hasn't been any user activity in the last 20 minutes. CCC activity is not considered user activity, so often the system will go to sleep immediately after CCC finishes a backup task.

If you choose one of the options from the Power management menu, CCC will reboot or shut down your Mac when the backup task finishes. The reboot and shutdown options are not forceful. If you have a document open with unsaved modifications, for example, the application would prompt you to save the document. If a save dialog is not attended to, the shutdown or reboot request will time out.

Turn off the computer if it was previously off

If your backup task is scheduled to run on a regular basis, this option will be enabled in the Power Management popup menu. This option is applicable if you would like to have CCC shut down your Mac at the end of the task, but only in cases where the Mac was booted at the task's scheduled run time. If your backup task runs when the system has been on for a while or has been sleeping, CCC will not shut down the Mac when using this option.

Power Management options are ignored in some cases

Power management options will not be applied to backup tasks that are cancelled (e.g. you click the Stop button). Additionally, power management tasks will not be applied if other CCC backup tasks are running or queued to run immediately after the current task finishes running. If your task is running as part of a Task Group, power management options will be deferred to when all tasks within the group have completed.

Power Management options are applied regardless of task success

Power management options will be applied whether the backup task completes successfully or not. If you prefer for a backup task to perform the power management action only when the backup task exits without error, see the pm_on_success.sh postflight script below.

Run another backup task (task chaining)

If you have more than one CCC backup task configured, the other tasks will be listed in this popup menu. To create a task chain (e.g. to run tasks sequentially), simply choose one of these tasks to have that task run automatically after the current task finishes. Tasks run in this manner will start after the current task has finished completely. Chained tasks will run regardless of the exit status of a preceding task in the chain, e.g. if the first task reports errors or fails to run at all, the second task will still run.

Running shell scripts before and after the backup task

If there is functionality that you need that does not exist within CCC, pre and post clone shell scripts may be the solution for you. Pre clone shell scripts run after CCC has performed "sanity" checks (e.g. are the source and destination volumes present, is connectivity to a remote Macintosh established) but before copying files. If you need your preflight script to run before CCC does the source/destination sanity checks, specify the preflight script as a global preflight script in the Advanced section of CCC's Preferences window. Note that global preflight scripts run prior to every task, they are not task-specific. Also, please bear in mind that CCC automatically attempts to mount the source and destination at the beginning of the task, you should not be implementing a shell script to achieve that functionality. If you're having trouble with CCC pre-mounting the source and destination, please ask us for help rather than attempt to address the issue with a preflight shell script.

Post-clone shell scripts run after CCC has finished copying files and performing its own internal cleanup, but before unmounting any volumes.

CCC passes several parameters to pre and post clone shell scripts. For example, the following shell script:

#!/bin/sh

echo "Running $0"
echo `date`
echo "Source: $1"
echo "Destination: $2"
echo "Third argument: $3" # Exit status for post-clone scripts, underlying volume path for a disk image for pre-clone scripts
echo "Fourth argument: $4" # Destination disk image path, if applicable

 

Would produce the following output (you can redirect this output to a file of your own specification) if implemented as a post clone script:

 

Running /Library/Application Support/com.bombich.ccc/Scripts/postaction.sh
Wed Oct 8 21:55:28 EDT 2014
Source: /
Destination: /Volumes/Offsite Backup
Third argument: 0
Fourth argument:

First parameter

The path to the source volume or folder.

Second parameter

The path to the destination volume or folder. If the destination is a disk image, this is the path to the mounted disk image.

Third parameter

  • Pre clone script: The underlying mountpoint for the volume that holds the destination disk image, if applicable.
  • Post clone script: The exit status of the file copying phase of the backup task.

Fourth parameter

The path to the destination disk image, if applicable.

If your pre clone script exits with a non-zero exit status, it will cause CCC to abort the backup task. This can be used to your advantage if you want to apply preconditions to your backup operation. If you want to be certain that errors in your pre clone shell script never cause the backup task to be aborted, add "exit 0" to the end of your script. If you would like that script to silently cancel the backup task, add "exit 89" to the end of the script. If the script is a global preflight script (specified in the Advanced section of CCC's Preferences window), you can add "exit 104" to the end of the script to cancel the backup task and to avoid recording a Task History event.

The post clone script will run whether the backup task exits successfully or not. If your script should behave differently depending on the result of the task, you can test whether the third parameter is zero (an exit status of "0" means the task ended successfully). For example:

#!/bin/sh

source="$1"
dest="$2"
exitStatus=$3

if [ "$exitStatus" = "0" ]; then
    # foo
else
    # bar
    # Note: Do not assume that $source and $dest are populated
    # These will be empty if source or destination validation fails
fi

If your postflight script exits with a non-zero exit status, CCC will not report this as a failure of the backup task. The failure will be noted in the Task History window, however.

AppleScripts are not supported

You cannot specify an AppleScript as a pre or post clone script, CCC currently only supports running shell scripts.

Shell scripts require a shell interpreter line

CCC does not assume a default shell environment when running your pre or postflight script. Not doing so gives users a great deal of flexibility; they can choose to write their scripts in any shell or programming language (e.g. bash, python, perl, ruby, C). For CCC to execute a shell script as an application, though, the system needs to know what shell should be used to interpret the script, and that value needs to be defined in your shell script. This is done simply by placing a shell interpreter line at the top of the file, e.g. #!/bin/sh.

Security implications of pre and post clone shell scripts

CCC's pre and post clone shell scripts are executed as the System Administrator. To prevent unauthorized modifications to your shell scripts, you should restrict the ownership and permissions of these scripts and to the folder in which they are contained. The parent folder and scripts should be writable only by the root user. For example, running the following in the Terminal application would secure any shell scripts located in the default location for pre and post clone scripts:

sudo chown -R root:wheel /Library/Application\ Support/com.bombich.ccc/Scripts
sudo chmod -R 755 /Library/Application\ Support/com.bombich.ccc/Scripts

Example pre and post clone shell scripts

To use any of these example scripts, download the script and place it somewhere on your startup disk. By default, CCC looks in /Library/Application Support/com.bombich.ccc/Scripts.

parallels_pause.sh
This is a pre clone script that you can use to pause all currently-running Parallels VM containers. This script will also retain state information that can be read by the corresponding parallels_start.sh post clone script to resume these VMs after the backup task has completed. Note: This script relies on command-line tools offered only in Parallels Desktop for Mac Pro or Business Edition. 

parallels_start.sh
This post clone script will resume any Parallels VM containers that were suspended by the parallels_pause.sh pre clone script. Note: This script relies on command-line tools offered only in Parallels Desktop for Mac Pro or Business Edition.

play_sound.sh
If you want to play a unique sound, use this script. You can plug in the path to any audio file of your liking or try one of the examples included.

eject_destination.sh
CCC's option to automatically unmount the destination volume is a volume-level task, not a device task. If you want to eject the destination device, use this post clone script instead. Note that ejecting the destination device will unmount all volumes on the device. Also note that this example script adds a 60-second delay to accommodate macOS's desire to automatically regenerate various cache files. This delay can be adjusted if necessary by editing the script.

pm_on_success.sh
This post clone script will perform the requested power management option (e.g. shutdown, restart, sleep) at the end of the backup task if the backup task completes without errors. Use this in lieu of one of the Power Management postflight options if you prefer the power management action does not occur when a task ends with errors (e.g. if the destination volume is missing).

quit_application.sh and open_application.sh
This pair of scripts can be used to quit and open an application before and after the backup task. Open these scripts in a text editor to define the application that should be quit or opened.

post_to_slack.sh
This postflight script will post the status of your backup task to a Slack channel.

ifttt_maker.sh
This postflight script will post an IFTTT Maker Event of the status of your backup task.

Frequently Asked Questions about encrypting the backup volume

$
0
0
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 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 Personalization Tool.

Performing actions Before and After the backup task

$
0
0
Product: 
ccc5

Often when you have a backup task that runs on a scheduled basis, there are associated tasks that you would like to perform before or after files are actually copied. CCC offers the option to run shell scripts before and after a backup task, unmount or set the destination as the startup disk, run another CCC backup task, and power management options such as restart and shutdown. If you would like to perform any of these pre or post clone tasks, click the Advanced Settings button below CCC's Source selector.

Mounting the source or destination volume before a backup task begins

Without any additional configuration, CCC will attempt to mount your source and destination volumes before a backup task begins. This applies to many different volume types — ordinary volumes on locally-attached hard drives, disk images, network volumes, encrypted volumes – even encrypted volumes on remote Macs. If your source or destination volume is on a disk that is physically attached to your Mac (e.g. via Firewire, Thunderbolt, or USB), but it is not mounted, CCC can "see" that device and will attempt to mount it. If your source or destination is a network volume, CCC will obtain the credentials that you use to mount that device when you create the backup task, and will use those credentials to mount the volume before the task begins.

This also applies for nested volumes. For example, suppose you are backing up to a disk image on a network volume. CCC will first attempt to mount the network volume, then it will attempt to mount the disk image. Likewise, suppose you have a task configured to back up the contents of a folder on an encrypted volume. If you have saved the encrypted volume's passphrase in CCC's keychain, CCC will unlock and mount the encrypted volume before the backup task begins.

CCC's attempts to mount the source and destination volumes occur automatically before any other tasks, including pre clone shell scripts (described below), therefore it is not necessary to implement a shell script to pre-mount the source or destination.

Little Snitch may prevent the automated mounting of network volumes

If you're using Little Snitch to monitor and filter your inbound and outbound network traffic, you may find that CCC has trouble automatically mounting a network volume. If you run into this problem, configure Little Snitch to allow network access to the NetAuthSysAgent system service. NetAuthSysAgent is the macOS system service that fulfills application requests to mount network volumes.

SafetyNet Pruning

SafetyNet pruning is covered in more detail in this section of CCC's documentation.

Destination volume options

If you would like CCC to unmount your destination volume at the end of the backup task, choose Unmount the destination volume from the Destination volume management menu. If your destination is a folder, the text will be Unmount the underlying volume. If the destination is a disk image, CCC always unmounts the disk image volume, so this setting refers to the underlying physical volume upon which the disk image resides.

CCC will not forcefully unmount the destination volume. If an application has open files on the destination volume, CCC's attempt to unmount the volume will fail. CCC does not report this as an error, though it will make a note of it in the Task History window.

Yosemite users have an option to set the destination volume as the startup disk. Starting in El Capitan, however, Apple's System Integrity Protection prevents third-party applications from changing the startup disk setting. We do not recommend disabling System Integrity Protection to make this feature work, rather we recommend that you use the Startup Disk Preference Pane to change the startup disk selection.

Power management options

By default, at the end of a backup task, CCC will not perform any power management tasks. Instead, the system will perform as defined by the settings in the Energy Saver preference pane. For example, if you have the system configured to idle sleep after 20 minutes, the system will go to sleep if there hasn't been any user activity in the last 20 minutes. CCC activity is not considered user activity, so often the system will go to sleep immediately after CCC finishes a backup task.

If you choose one of the options from the Power management menu, CCC will reboot or shut down your Mac when the backup task finishes. The reboot and shutdown options are not forceful. If you have a document open with unsaved modifications, for example, the application would prompt you to save the document. If a save dialog is not attended to, the shutdown or reboot request will time out.

Turn off the computer if it was previously off

If your backup task is scheduled to run on a regular basis, this option will be enabled in the Power Management popup menu. This option is applicable if you would like to have CCC shut down your Mac at the end of the task, but only in cases where the Mac was booted at the task's scheduled run time. If your backup task runs when the system has been on for a while or has been sleeping, CCC will not shut down the Mac when using this option.

Power Management options are ignored in some cases

Power management options will not be applied to backup tasks that are cancelled (e.g. you click the Stop button). Additionally, power management tasks will not be applied if other CCC backup tasks are running or queued to run immediately after the current task finishes running. If your task is running as part of a Task Group, power management options will be deferred to when all tasks within the group have completed.

Power Management options are applied regardless of task success

Power management options will be applied whether the backup task completes successfully or not. If you prefer for a backup task to perform the power management action only when the backup task exits without error, see the pm_on_success.sh postflight script below.

Run another backup task (task chaining)

If you have more than one CCC backup task configured, the other tasks will be listed in this popup menu. To create a task chain (e.g. to run tasks sequentially), simply choose one of these tasks to have that task run automatically after the current task finishes. Tasks run in this manner will start after the current task has finished completely. Chained tasks will run regardless of the exit status of a preceding task in the chain, e.g. if the first task reports errors or fails to run at all, the second task will still run.

Running shell scripts before and after the backup task

If there is functionality that you need that does not exist within CCC, pre and post clone shell scripts may be the solution for you. Pre clone shell scripts run after CCC has performed "sanity" checks (e.g. are the source and destination volumes present, is connectivity to a remote Macintosh established) but before copying files. If you need your preflight script to run before CCC does the source/destination sanity checks, specify the preflight script as a global preflight script in the Advanced section of CCC's Preferences window. Note that global preflight scripts run prior to every task, they are not task-specific. Also, please bear in mind that CCC automatically attempts to mount the source and destination at the beginning of the task, you should not be implementing a shell script to achieve that functionality. If you're having trouble with CCC pre-mounting the source and destination, please ask us for help rather than attempt to address the issue with a preflight shell script.

Post-clone shell scripts run after CCC has finished copying files and performing its own internal cleanup, but before unmounting any volumes.

CCC passes several parameters to pre and post clone shell scripts. For example, the following shell script:

#!/bin/sh

echo "Running $0"
echo `date`
echo "Source: $1"
echo "Destination: $2"
echo "Third argument: $3" # Exit status for post-clone scripts, underlying volume path for a disk image for pre-clone scripts
echo "Fourth argument: $4" # Destination disk image path, if applicable

 

Would produce the following output (you can redirect this output to a file of your own specification) if implemented as a post clone script:

 

Running /Library/Application Support/com.bombich.ccc/Scripts/postaction.sh
Wed Oct 8 21:55:28 EDT 2014
Source: /
Destination: /Volumes/Offsite Backup
Third argument: 0
Fourth argument:

First parameter

The path to the source volume or folder. If the source volume is APFS-formatted, then this path will usually be the path to a temporary, read-only snapshot of the source (or the path to the source folder on the temporary, read-only snapshot).

Second parameter

The path to the destination volume or folder. If the destination is a disk image, this is the path to the mounted disk image.

Third parameter

  • Pre clone script: The underlying mountpoint for the volume that holds the destination disk image, if applicable.
  • Post clone script: The exit status of the file copying phase of the backup task.

Fourth parameter

The path to the destination disk image, if applicable.

If your pre clone script exits with a non-zero exit status, it will cause CCC to abort the backup task. This can be used to your advantage if you want to apply preconditions to your backup operation. If you want to be certain that errors in your pre clone shell script never cause the backup task to be aborted, add "exit 0" to the end of your script. If you would like that script to silently cancel the backup task, add "exit 89" to the end of the script. If the script is a global preflight script (specified in the Advanced section of CCC's Preferences window), you can add "exit 104" to the end of the script to cancel the backup task and to avoid recording a Task History event.

The post clone script will run whether the backup task exits successfully or not. If your script should behave differently depending on the result of the task, you can test whether the third parameter is zero (an exit status of "0" means the task ended successfully). For example:

#!/bin/sh

source="$1"
dest="$2"
exitStatus=$3

if [ "$exitStatus" = "0" ]; then
    # foo
else
    # bar
    # Note: Do not assume that $source and $dest are populated
    # These will be empty if source or destination validation fails
fi

If your postflight script exits with a non-zero exit status, CCC will not report this as a failure of the backup task. The failure will be noted in the Task History window, however.

AppleScripts are not supported

You cannot specify an AppleScript as a pre or post clone script, CCC currently only supports running shell scripts.

Shell scripts require a shell interpreter line

CCC does not assume a default shell environment when running your pre or postflight script. Not doing so gives users a great deal of flexibility; they can choose to write their scripts in any shell or programming language (e.g. bash, python, perl, ruby, C). For CCC to execute a shell script as an application, though, the system needs to know what shell should be used to interpret the script, and that value needs to be defined in your shell script. This is done simply by placing a shell interpreter line at the top of the file, e.g. #!/bin/sh.

Security implications of pre and post clone shell scripts

CCC's pre and post clone shell scripts are executed as the System Administrator (aka "root"). To prevent unauthorized modifications to your shell scripts, we recommend that you restrict the ownership and permissions of these scripts and to the folder in which they are contained. The parent folder and scripts should be writable only by the root user. For example, running the following in the Terminal application would secure any shell scripts located in the default location for pre and post clone scripts:

sudo chown -R root:wheel /Library/Application\ Support/com.bombich.ccc/Scripts
sudo chmod -R 755 /Library/Application\ Support/com.bombich.ccc/Scripts

To further enhance the security of your pre and postflight scripts, CCC will require that scripts stored in the default location are owned by the root user and writable only by the root user, and that the Scripts folder itself is also owned and writable only by the root user. If a script that resides within the default Scripts folder does not meet these requirements, CCC will refuse to execute that script and the associated task will report an error.

After copying scripts into CCC's Scripts folder or making changes to those scripts, you can choose "Secure CCC's Scripts folder" from CCC's Utilities menu to correct any ownership or permissions concerns. Please note that these additional security requirements are only applied to scripts stored within the /Library/Application Support/com.bombich.ccc/Scripts folder. If you prefer to manage the security of your shell scripts on your own, you may store them in another location.

Example pre and post clone shell scripts

To use any of these example scripts, download the script and place it somewhere on your startup disk. By default, CCC looks in /Library/Application Support/com.bombich.ccc/Scripts.

parallels_pause.sh
This is a pre clone script that you can use to pause all currently-running Parallels VM containers. This script will also retain state information that can be read by the corresponding parallels_start.sh post clone script to resume these VMs after the backup task has completed. Note: This script relies on command-line tools offered only in Parallels Desktop for Mac Pro or Business Edition. 

parallels_start.sh
This post clone script will resume any Parallels VM containers that were suspended by the parallels_pause.sh pre clone script. Note: This script relies on command-line tools offered only in Parallels Desktop for Mac Pro or Business Edition.

play_sound.sh
If you want to play a unique sound, use this script. You can plug in the path to any audio file of your liking or try one of the examples included.

eject_source_and_destination.sh
CCC's option to automatically unmount the destination volume is a volume-level task, not a device task. It's also limited to the destination. If you want to eject the destination device, or if you want to unmount or eject the source, use this post clone script instead. Note that ejecting a device will unmount all volumes on the device. Also note that this example script adds a 60-second delay to accommodate macOS's desire to automatically regenerate various cache files. This delay can be adjusted if necessary by editing the script.

pm_on_success.sh
This post clone script will perform the requested power management option (e.g. shutdown, restart, sleep) at the end of the backup task if the backup task completes without errors. Use this in lieu of one of the Power Management postflight options if you prefer the power management action does not occur when a task ends with errors (e.g. if the destination volume is missing).

quit_application.sh and open_application.sh
This pair of scripts can be used to quit and open an application before and after the backup task. Open these scripts in a text editor to define the application that should be quit or opened.

post_to_slack.sh
This postflight script will post the status of your backup task to a Slack channel.

ifttt_maker.sh
This postflight script will post an IFTTT Maker Event of the status of your backup task.

Advanced Settings

$
0
0
Product: 
ccc5

CCC's Advanced Settings are helpful in specific situations, but are not generally required for routine use. Some of these settings involve more risk, so please use them with caution, and don't hesitate to ask questions via the Ask a question about CCC... menu item in CCC's Help menu if the explanations below are insufficient for your particular scenario.

To access the advanced settings, click on the Advanced Settings button below CCC's Source selector.

Advanced settings button

Use strict volume identification

By default, CCC uses the name and Universally Unique Identifier (UUID) of your source and destination to positively identify those volumes. By verifying both of these identifiers, there is less risk in, for example, backing up to a volume that has the same name as your usual destination but is not actually the destination.

While beneficial, this behavior can sometimes have the wrong result. For example, if you rotate between a pair of external hard drives, CCC will not backup to both of them even though they have the same name (e.g. Offsite Backup). CCC will instead claim that the UUID of one of the volumes does not match that of the originally chosen destination.

To accommodate a "rotating pair of backup volumes" solution, you can uncheck this option to indicate that CCC should only use the volume name to identify the destination volume. When deselecting this option, be vigilant that you do not rename your destination volume and that you never attach another non-backup volume to your Mac that is named the same as your destination volume.

This option is automatically disabled when the destination volume does not have a UUID. Network volumes and some third-party filesystems, for example, do not have volume UUIDs.

Note: This setting is only applicable to the destination volume. CCC always uses the name and UUID to positively identify the source volume.

Note: If your rotating destination volumes are encrypted, CCC will only be able to unlock and mount the original encrypted volume selected as the destination for your backup task. CCC must have a unique identifier of the destination volume in order to unlock that volume, and CCC will only retain that information about one destination volume for a particular task. If you would like to rotate a pair of backup disks that are encrypted, we recommend using two separate tasks for that purpose; one for each encrypted destination.

Protect root-level items

If you have files and folders that are unique to the root-level on your destination volume and you want them to be left alone, yet you want to keep your backup "clean", use the Protect root-level items option. This option is enabled by default when CCC's SafetyNet option is enabled. To understand how this feature works, suppose you have these items on your source volume:

And you have these items on the destination volume:

With the Protect root-level items option, the Videos folder will not be moved to the _CCC SafetyNet folder because it is unique to the root level of the destination. The Users folder is not unique to the root of the destination (it also exists on the source), though, so its contents will be updated to match the source. As a result, the olduseraccount folder will be moved to the _CCC SafetyNet folder (or deleted if you have disabled the SafetyNet).

Find and replace corrupted files, "Backup Health Check"

CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. If the checksums differ ,CCC will recopy the file. This option will increase your backup time, but it will expose any corrupted files within your backup set on the source and destination.

Media failures occur on nearly every hard drive at some point in the hard drive's life. These errors affect your data randomly, and go undetected until an attempt is made to read data from the failed sector of media. If a file has not been modified since a previous (successful) backup, CCC will not ordinarily attempt to read every byte of that file's content. As a result, it is possible for a corrupted file to go unnoticed on your source or destination volume. Obviously this is a concern if the file is important, and one day you actually need to recover the contents of that file.

Frequent use of the checksum calculation option is unnecessary and may be a burden upon your productivity, so CCC offers weekly and monthly options to limit how frequently the checksumming occurs. 

Note: CCC will never replace a valid file on your destination with an unreadable, corrupt file from the source. If CCC cannot read a file on your source volume, any existing backup of that file will remain intact on your backup volume and CCC will report an error, advising you to replace the source file with the intact backup version. The Find and replace corrupted files setting will only automatically replace corrupted files on the destination, and only when the source file is completely readable.

What is a "corrupted" or "unreadable" file?

With regard to files on the source, CCC's Find and replace corrupted files option specifically refers to files that cannot be physically read from the disk. It does not refer to files that have been mistakenly or maliciously altered such that they cannot be opened by the application that created them.

Using the "Find and replace corrupted files" option to verify your backup

CCC's checksum option verifies the integrity of the files on your destination volume before files are copied, it is not a verification of files that have just been written. In general, the checksum of a file immediately after it is written to disk is of questionable value. Most disks have a write cache, and file data goes to the cache before it is written to actual media. If you write a file and then immediately ask to read it back, as much as x amount of data (where x = the size of the cache) is going to come from the volatile cache. If any of the file's data comes from the write cache, then the checksum doesn't reflect the status of the data on the permanent media, and that really defeats the purpose of checksumming the file in the first place.

If you want to verify the integrity of the files on your destination immediately after copying files, a subsequent backup with CCC's Find and replace corrupted files option is the best way to do that. You can even automate this process by creating a second task that uses this option, then select the second task in the "Run another backup task" popup menu in the After task runs section of advanced settings.

Troubleshooting Options

Run a deletion pass first

When the CCC SafetyNet option is disabled, CCC typically deletes unique items from the destination as it encounters them. CCC iterates through the folders on your source alphabetically, so some files are often copied to the destination before all of the files that will be deleted have been deleted from the destination. If your destination volume has very little free space, CCC may not be able to complete a backup to that volume. This option will cause CCC to run a deletion pass through the entire destination before copying files. Use of this option will make your backup task take longer.

This option will only be enabled when the SafetyNet option is disabled.

Don't update newer files on the destination

Files on the source are generally considered to be the authoritative master, and CCC will recopy a file if the modification date is at all different — newer or older — on the source and destination. Occasionally there are circumstances where the modification date of files on the destination is altered after a backup task runs (e.g. by anti-virus applications), and this alteration causes CCC to copy these files every time. This option can work around these circumstances when the root cause of the modification date alteration cannot be addressed.

Don't preserve permissions

This setting will avoid the errors generated by network volumes that disallow the modification of permissions and ownership on some files. It will also prevent CCC from enabling ownership on the destination volume. Use of this option while backing up applications or macOS system files will prevent those items from working correctly on the destination.

Don't preserve extended attributes

This setting will disable support for reading and writing extended attributes, such as Finder Info, resource forks, and other application-proprietary attributes. Extended attributes store data about the file. Apple explicitly recommends that developers do not store irreplaceable user data in extended attributes when saving a file, because extended attributes are not supported by every filesystem, and could be silently dropped (e.g. by the Finder) when copying a file.

This option is helpful in cases where the source or destination filesystem offers exceptionally poor performance for reading and writing extended attributes, or offers very limited support for macOS native extended attributes such that many errors are reported when trying to copy these metadata.

Related Documentation


Excluding files and folders from a backup task

$
0
0
Product: 
ccc5

By default, CCC will copy everything from the volume or folder that you specify as the source. If you do not want to copy every item from the source, you can define a task filter to limit what items will be copied. Choose Copy Some Files from the popup menu underneath the Source selector, or click on the Task Filter button (Task Filter button icon) to open the Task Filters panel.

Default Filter Behavior

The CCC task filter offers two paradigms for defining the task filter. The task filter can either include everything by default or the filter can exclude everything by default. Which behavior you choose depends on what you want CCC to do with new items that are added to the source.

Include everything by default: Define what is excluded

CCC's default behavior is to include everything by default. In this mode you define what is excluded from the backup task by unchecking the box next to an item in the file list. This mode is simplest for users that only want to exclude a handful of items, but generally back up everything because you don't have to revisit the task filter to indicate that new items should be included in the backup task. If you add a file or folder to the source (e.g. in the future after defining your task filter), and that item is not in a folder that you have excluded from the backup task, that item will automatically be included in the backup task.

Exclude everything by default: Define what is included

In this mode, everything is excluded by default, and you define what is included in the backup task by checking the box next to an item in the file list. If you add an item to the source in the future, and that item is not in a folder that is specifically included by the task filter, that item will not be backed up. This mode is helpful in cases where you only want to back up a handful of items on a volume whose subfolders frequently change.

Calculating disk usage and Protected Size

You can right-click on any folder and choose Refresh size to have CCC enumerate the contents of that folder and evaluate the task filter against its contents. CCC will report the total size of the folder and the protected size of the folder (i.e. how much data is included in the backup task). You can also click on the Refresh Disk Usage button to enumerate the contents of the entire source. This could take a while, especially for network volumes, so consider refreshing the disk usage of individual folders instead. If CCC is in the midst of enumerating a folder, you can right-click on that folder to stop enumeration, or click again on the Refresh Disk Usage button to stop the calculation.

Source and destination options

Finder's Trash is excluded by default

By default, CCC won't copy the contents of the Finder Trash because, well, it's Trash. If you want CCC to back up your Trash, open the Task Filter window, then uncheck the Don't copy Finder's Trash box to remove the exclusion. See this section of CCC's documentation to learn more about the idiosyncrasies of the Finder Trash mechanism and how it relates to backing up and restoring the content of the Trash.

Excluded files are not deleted from the destination

When you exclude an item from the CCC backup task, this tells CCC, "Do not copy that item". That does not, however, indicate that CCC should delete that item from the destination, e.g. if it had been copied there by a previous backup task. In fact, excluding an item from the backup task implicitly protects that item on the destination. If you have items on the destination that are now excluded from a backup task that you no longer want to retain on the destination, you can simply remove them from the destination by dragging them to the Trash. If you would like CCC to facilitate that cleanup, check the Remove excluded files checkbox.

This option is ignored if your task is configured with the Don't delete anything SafetyNet setting. This setting also will not override CCC's explicit protections placed on the _CCC SafetyNet folder, so when this option is used in conjunction with CCC's "SafetyNet On" setting, items will be moved to the SafetyNet folder rather than deleted immediately.

Please carefully consider the scope of effect that this option will have when using the Exclude everything by default filter behavior.

The Protect root level items setting is described in more detail in the Advanced Settings article.

Custom Filters

If the files you want to match are scattered across your filesystem, it may be tedious to manually locate each of them and create conventional rules (i.e. check or uncheck the item in the file list). To address this, CCC offers custom filter options in which you define a filter rule using an expression. Choose Show custom filters from the gear menu to reveal the custom filters table.

To add a custom filter rule, click the + button in the custom rules table header, or drag a file or folder from the file list into the custom filters table to add that item as a template. To reorder custom filters, simply drag and drop the items in the custom filters table. Custom filter rules will be evaluated by the task filter before conventional filter rules.

Anchored path filter

An anchored path filter defines a rule using an absolute path relative to the root of the source. /Library/Caches, for example, is an anchored path filter because it starts with a "/". This filter would match /Library/Caches, but would not match /Users/someuser/Library/Caches. You can also include wildcards in the expression, e.g. /Users/*/Library/Caches would match the Library/Caches folder in each user home folder.

Subpath filter

A subpath filter defines a rule using a partial path or filename that does not start with "/". Continuing the example above, Library/Caches would match /Library/Caches and  /Users/someuser/Library/Caches. Wildcards are accepted in the expression; to match a particular file type, use an expression like *.mov to match all .mov files.

Wildcard characters

Wildcard characters can be added to an expression to match a wider range of files and folders. * will match one or more characters in any single file or folder name, e.g. *.mov will match all movie files.

/**/ will match one or more path components, e.g. /Users/**/*.jpg will match any JPEG photos in any user home folders, but won't match JPEG photos elsewhere, e.g. those in /Library/Desktop Pictures. You would also use the ** wildcard when defining an inclusion rule that should copy all items within a particular folder and its subfolders. For example, /Users/yourname/Documents would include only that folder itself, not any of its contents. /Users/yourname/Documents/** would include the Documents folder, all of its contents, and the contents of every subfolder within it.

If you specify additional path components after a ** wildcard, then that wildcard is only applicable up to a match against the path component that follows the wildcard. For example, the exclusion rule /Data/**/Marine/Invertebrates would exclude /Data/2018/Marine/Invertebrates, but it would not exclude /Data/2018/Marine/Benthic/Marine/Invertebrates. In the latter case, **/Marine matches 2018/Marine, but then the the next path component fails to match (and we are deliberately choosing to not allow the ** wildcard to match 2018/Marine/Benthic in this case).

? can be used to match any single character, e.g. *.mp? will match both .mp3 and .mp4 files. Use the ? wildcard sparingly, it will greatly increase the amount of time required to evaluate the task filter.

Expert settings

Custom filter rules are usually applied to include or exclude an item. Exclusions, however, are actually composed of two behaviors: a matching item on the source will not be copied (Hide the item from the copier), and a matching item on the destination will be protected (Protect the item from the copier). Likewise, Inclusions indicate that a matching item on the source will be copied (Show the item to the copier) and a matching item on the destination may be deleted (Risk the item). Occasionally it's helpful to define a rule that affects only matching items on the source or only on matching items on the destination. For example, if you have a folder named "Archives" on the destination that does not exist on the source, that item won't appear in the source list so it cannot be excluded (and thus protected) in the conventional manner. You could add an /ArchivesProtect rule to explicitly protect that item on the destination.

Including folders and their content with the 'Exclude everything by default' filter behavior and custom rules

Including a folder or a bundle file and its contents via a custom rule requires a non-intuitive expression, because the filter rule must match multiple path components. To include a folder and all of its contents, add ** to the end of the filter expression. For example, to include the Photos Library from your home directory, the following expression would apply as an inclusion rule:

/Users/johnny/Pictures.Photos Library.photolibrary**

Exporting and Importing filters

A whole task filter can be imported or exported via the gear menu. When importing a filter, the current filter will be replaced with the filter you're importing. CCC will automatically purge conventional rules from the filter if they are not applicable to the currently-selected source. For example, f you had excluded /Applications in the filter, but /Applications does not exist on the current source, that rule will be removed from the filter to avoid unexpected results should an /Applications folder ever be added to the source. This purging is not applicable to custom filter rules.

You can also export individual or groups of custom filter rules. Select the rule(s), then simply drag the items onto your Desktop. To import custom rules from a file exported in this manner, simply drag the file into the custom filter rules table.

Items automatically excluded

Carbon Copy Cloner excludes some items from the backup task by default. A complete list of exclusions along with an explanation for the exclusion is available in this section of the documentation. If you would like to visualize the items that are automatically excluded, hold down the Option key while clicking on the Task Filter button to open the Task Filters window.

The CCC SafetyNet folder, "_CCC SafetyNet" is excluded by a global filter. See the Frequently asked questions about the Carbon Copy Cloner SafetyNet section of the documentation to learn how to restore items from that folder.

Additionally, CCC will exclude and protect system folders if you select the startup disk or a non-HFS+/APFS formatted volume as the destination. If you would like to restore a specific item, such as the contents of /Library/Application Support, this protection can be avoided by choosing a specific folder at the source and destination via the Choose a folder options in the Source and Destination selectors. With great power comes great responsibility — take care to avoid overwriting your system files.

Related documentation

Performance Suggestions

$
0
0
Product: 
ccc5

There are several factors that affect the performance of your backup tasks. Here we describe the most common conditions that affect backup performance, and offer some suggestions for mitigating the effects of those conditions.

Reduce the number of files considered for backup

CCC analyzes all of the files that are included in your backup set for consideration to be copied. If you have a particularly high number of files on your source volume, you may want to put some thought into how your files are organized. For example, if you have a large number of files that never change (perhaps some old, completed projects), you can collect these into a folder named "Archives", back it up once, then exclude it from future backups. CCC will not delete excluded items from your destination (unless you ask it to using Advanced Settings), so as long as you keep the original on your source volume, you will always have two copies of your archived content. Because these items are excluded from your daily backups, CCC will not spend time or RAM enumerating through those files for changes.

Related Documentation

Hard drive performance and interface bandwidth

Performance will be worse for smaller rotational hard drives (e.g. physically smaller, like those in 2.5" hard drive enclosures), for older hard drives, and for hard drives that are nearly full and thus more likely to be fragmented. You will also get longer copy times when you have lots of small files vs. a volume filled with just a few very large files. Finally, you will see better performance with faster/more efficient interfaces — Thunderbolt is faster than Firewire, Firewire 800 is faster than USB 2.0, etc.

When you consider purchasing an external hard drive for backup, we recommend enclosures that have multiple interfaces (e.g. Firewire and USB, or Thunderbolt and USB). Depending on how you use the Firewire or USB interfaces on your Mac, you may find that you get better performance or reliability when trying a different interface on your external backup disk. Additionally, if your source volume is nearly full, we recommend that you replace it with a larger hard drive to avoid the performance implications of filesystem fragmentation.

Filesystem performance and hardware type

It's important to choose the right filesystem for the hardware that you have. If you have an older, rotational HDD, you should format that device using the "Mac OS Extended, Journaled" (HFS+) format. APFS is the new, modern standard, but its performance on rotational devices is inferior to HFS+. Apple still recommends HFS+ for rotational HDD devices, and that's our recommendation as well.

Spotlight Indexing

Anything that causes CCC to compete for bandwidth to your source or destination volume will increase the amount of time that it takes to back up your data. Spotlight indexing is one such process that CCC typically must compete with for disk bandwidth. As you copy new data to your destination volume, for example, Spotlight wants to read those "new" files so it can index their contents. Having a Spotlight index of your backup volume may be unnecessary as you probably want to search for files only on your source volume. To disable Spotlight indexing on a volume that is dedicated to backup, drag the icon of the destination volume into the "Privacy" tab of Spotlight Preference Pane in the System Preferences application. If you do want the backup volume indexed, drag its icon out of the "Privacy" tab after the cloning and indexing will start immediately.

Find and replace corrupted files

CCC offers an advanced option to "Find and replace corrupted files". When using this option, CCC will re-read every file on the source and every file on the destination, calculating a checksum of each file. CCC then compares these checksums to see if a file should be recopied. While this is an excellent method for finding unreadable files on the source or destination, it will dramatically increase the amount of time that your backup task takes, and it will also increase CPU and hard drive bandwidth consumption on your Mac. We recommend limiting the use of this option to weekly or monthly, and scheduling such tasks to run when you are not typically using your Mac.

Target Disk Mode is slow

In fact it's unbelievably slow. If you attach an SSD-bearing Mac in Target Disk Mode to another Mac via a USB-C cable (so both at 10Gb/s connections), you might expect to get incredible speed (e.g. >500MB/s). You will be sorely disappointed by speeds of less than 20MB/s; slower than USB 2.0. For better performance, we recommend that you avoid Target Disk Mode. Boot the target Mac from the volume you're trying to restore instead. Not only will you get better performance, but you also have the assurance that the Mac can boot from the OS that you're restoring to it.

Other applications and conditions that can lead to performance problems

Over the years we have received numerous queries about poorer performance than what is expected. Careful analysis of the system log and Activity Monitor will usually reveal the culprit. Here are some things that we usually look for:

  • Other backup software copying simultaneously to the same volume, a different volume on the same disk, or across the same interface as CCC's destination.
  • Utilities that watch filesystem activity and do things when file changes are detected. Antivirus software is a common culprit, but we have also seen problems caused by other watcher applications, such as memeod and Western Digital's SmartWare.
  • Slow interfaces — USB hubs (including the ports on a USB keyboard or display) and even some USB cables can reduce the bandwidth to your disk dramatically. If you're using USB, be sure that your device is plugged directly into one of the USB ports on your Mac.
  • Daisy chaining Firewire devices is usually OK, though some enclosures can stall the entire Firewire bus when given too much bandwidth. If you see this behavior, try switching the order of devices in the chain, or attach your backup disk directly to a Firewire port on your Mac.
  • Using a wireless network connection to connect to a network volume. If you're seeing poor performance with a wireless connection, compare the performance when using a wired (ethernet) connection.
  • Symantec's Digital Loss Prevention (DLP) can cause performance problems when backing up a specific Microsoft font cache (e.g. /Users/yourname/Library/Containers/com.microsoft.Outlook/Data/Library/Application Support/Microsoft/FontPreviewCache). The problem appears to be specific to DLP's ability to cope with the dorky emojis that Microsoft uses in the file names in this folder (i.e. replacing the word "family" with the 👪 family emoji). Exclude that FontPreviewCache folder from your backup task to avoid the performance problem.

Use the Console application to view the contents of the system log. If you're still having trouble identifying a performance problem, we're here to help.

Related Documentation

Using Carbon Copy Cloner to back up to/from another Macintosh on your network

$
0
0
Product: 
ccc5

Carbon Copy Cloner offers the option of securely copying your selected data to another Macintosh on your network (or anywhere on the Internet for that matter) via the Remote Macintosh... options in the Source and Destination selectors. After a brief setup procedure to establish trust between your Mac and the destination Mac, simply choose the source or destination volume/folder on the remote Mac and CCC will take care of the rest.

Before setting up CCC to back up to a remote Macintosh, you must:

  1. Confirm that the remote Macintosh is running a supported OS (OS X 10.7 or later)
  2. Enable Remote Login in the Sharing Preference Pane on the remote Macintosh
  3. Verify that any firewalls between the two Macs are permitting "secure shell" traffic over port 22 (or a custom port that you specify).

Enabling Remote Login on the remote Macintosh

To enable Remote Login on your remote Macintosh:

  1. Log in to that machine as an admin user.
  2. Open the System Preferences application.
  3. Open the Sharing Preference Pane.
  4. Check the box next to Remote Login.
  5. Be sure to allow access to All users, or explicitly add the Administrators group to the list of restricted users and groups.
  6. Make a note of your remote Mac's hostname. The hostname is indicated underneath the Computer Name text field. In the screenshot below, "Apollo.local" is the hostname of the remote Macintosh.
Enable Remote Login

Configuring a Remote Macintosh source or destination

With the Remote Login service enabled on the remote Mac, the next step is to choose Remote Macintosh... from CCC's Source or Destination selector. CCC will present a browser that lists any hosts on your local network that advertise the Remote Login service. Find and select your remote Mac in this list, then click the Connect button. If you do not see your Mac listed here, type in the hostname of your remote Mac, then click the Connect button. If the remote Mac is not on your local network, you may need to specify the IP address of the public-facing router that your Mac resides behind. Be sure to configure the router to forward port 22 traffic to the IP address that is assigned to the remote Mac.

Connect to host

Once CCC has established a connection to the remote Mac, you will be prompted to install a Mac-specific Public Key Authentication (PKA) key pair onto the remote Mac. You must provide the username and password of an admin user on the remote Mac to permit this, and that admin user must have a non-blank password. Those requirements are only for the initial public key installation. For future authentication requests, CCC will use the PKA key pair.

Note: This step establishes a high level of trust between the local and remote Mac; this is required to correctly preserve system files. The local Mac will have access to all data on the remote Mac, and administrative users on the remote Mac can gain access to the data that you back up to that Mac. Both Macs should be within your administrative control.

 

Authenticate to the remote Mac

Install Key

Once you have connected to the remote Mac and installed CCC's key on that system, CCC will present a volume browser. Select the volume or folder to use as the source or destination for your task. Note: avoid selecting a volume or folder that contains an apostrophe (').

Connect to host

Bandwidth management options

CCC offers two options that can help you address bandwidth concerns. The option to Compress data passed over the network can greatly reduce your backup time and total bandwidth used. The time savings depend on just how slow the connection is between the two Macs. If you have a connection that is slower than 10MB/s, compression will make the transfer faster. If your bandwidth is better than that, compression may actually slow down your transfer. CCC will not compress certain file types that are already compressed, such as graphics files, movies, and compressed archives. Specifying the option to compress data passed over the network does not create a proprietary or compressed backup; files are automatically decompressed on the destination volume on the remote Macintosh.

CCC also offers a bandwidth limitation option. If your ISP requires that your transfers stay below a certain rate, you can specify that rate here. Note that CCC errs on the conservative side with this rate, so the average transfer rate may be slightly lower than the limitation that you specify.

De-authenticating a remote Macintosh

If you no longer wish to use a particular remote Macintosh, you can click the Deauthenticate... button to remove CCC's PKA key pair from the remote Mac.

Remote Macintosh prerequisites

At this time, CCC requires the use of the root account (though it does not have to be enabled) on both the source and destination Macs. To successfully back up to a remote Macintosh, you must have administrative privileges on both machines.

CCC also requires that the remote Macintosh be running macOS 10.7 or later. Non-Macintosh systems are not supported with the Remote Macintosh feature.

Note for Yosemite, El Capitan, & Sierra users: If your source contains macOS Yosemite (or later) system files, the Remote Macintosh must be running macOS 10.9.5 or later. If the Remote Macintosh is not running 10.9.5 or later and you attempt to back up macOS Yosemite (or later) system files, the backup task will report numerous "Input/output" ("Media") errors. Filesystem changes introduced on Yosemite cannot be accommodated by older OSes. Apple added support for those filesystem changes in 10.9.5 to offer a modest amount of backwards compatibility.

Additional pointers for advanced users

Carbon Copy Cloner's public key-based authentication is designed to work with no additional configuration of the services required for backing up over a network connection. CCC uses rsync over an ssh tunnel to perform the backup. If you do make modifications to the sshd configuration, you should consider how that may affect your backup. For example, CCC requires use of the root account over ssh. If you set the "PermitRootLogin" key in the sshd_config file to "no", you will not be able to use CCC to or from that machine. It's an important distinction to note that the root account does not have to be enabled, but sshd must permit the use of the root account. The "PubkeyAuthentication" key must also not be set to "no", because Public Key Authentication is required for CCC to authenticate to the remote Mac. CCC will attempt to proactively present these configuration scenarios to you if authentication problems are encountered.

Additionally, the initial Public Key Authentication (PKA) setup requires the use of an admin user on the remote Macintosh. That admin user account must have a non-blank password, and the Remote Login service must permit password-based authentication. These requirements apply only to the initial installation of CCC's PKA credentials. Once CCC has installed these credentials on the remote Mac, CCC will use PKA for authentication to the remote Mac.

Troubleshooting connectivity problems to a remote Macintosh

Problems connecting to a remote Macintosh generally are caused by configuration problems with the Remote Login service on the remote Macintosh. Try the following if you are having trouble making a backup to a remote Mac:

  1. Verify that the Remote Login service is enabled in the Sharing preference pane on the Remote Macintosh.
  2. Verify that access to the Remote Login service is allowed for All users.
  3. Re-select Remote Macintosh from CCC's Source or Destination selector and verify that authentication to the remote Mac is configured.
  4. Verify that your firewall and the remote Mac's firewall permits traffic on port 22. If you have an application firewall in place (e.g. Little Snitch), verify that access is granted to CCC's privileged helper tool, "com.bombich.ccchelper".
  5. If your local Mac and remote Mac are not on the same network (e.g. you're connecting across a VPN or through a router and over the Internet), confirm that a connection can be established between the two Macs. How you do this will vary from one scenario to the next, but you can generally verify connectivity by typing "ssh root@192.168.1.1" into the Terminal application (replace 192.168.1.1 with the hostname or IP address of your remote Mac). If you see a request for a password, then connectivity is established. If not, your network configuration isn't permitting the traffic, or the hostname that you're connecting to is invalid or unavailable. If you are accessing a remote Mac that is behind a router, consult the router's port forwarding documentation and verify that port 22 traffic is directed to the internal IP address of the remote Mac.

VPN and port forwarding configuration is outside of the scope of support for CCC, though our support staff will make every effort to identify whether problems are occurring within that configuration or within the service configuration on your remote Mac. If you have worked through the troubleshooting steps above and are still having trouble backing up to a remote Macintosh, please choose Report a problem from CCC's Help menu and submit a support request.

Meraki router intercepts Secure Shell traffic

Some users that have a Meraki router involved in their configuration have reported that its default configuration will interrupt Secure Shell traffic. The firewall rule that causes interference is in place to protect the network from vulnerabilities that are irrelevant between two modern Macs. Nonetheless, the firewall intercepts traffic after initially allowing a connection, which is presented by CCC as a "lost connection" or a failure to authenticate to the remote Mac. The following steps correct the Meraki configuration concern:

  1. Log into the Meraki as an administrative user and open the "Security report"
  2. Filter the log for SSH events
  3. Click the "SSH_EVENT_REPOVERFLOW" event from the list to open it and review the blocked event
  4. To allow the blocked traffic of this type, click "Yes" to add this event to the whitelist.

Thomson Gateway router intercepts Secure Shell traffic

Similar to the problem described above for Meraki router, the Thomson Gateway router can also cause interference that appears as an authentication failure. Forwarding traffic to a non-standard secure shell port (e.g. 2222, then be sure to specify that port when connecting to the Remote Macintosh in CCC) resolves the problem.

A note about access privileges to backed up data

While logged in to your remote Macintosh, you may not have permission to view the contents of your backup in the Finder. Your access to the files will be based on the unique id that is associated with the user account that you're logged in to on the remote Macintosh and the one associated with the account(s) on the other Mac(s) that you're backing up. The first administrator account always gets a uid of "501", and subsequent accounts are assigned incrementally higher uids — 502, 503, etc. For security and privacy purposes, macOS restricts access to the contents of user home directories to the owners of those home directories, and these restrictions are preserved when your data is backed up to a remote Macintosh.

To learn what user id is associated with your account:

  1. Open System Preferences and click on the User Accounts preference pane.
  2. Click on the lock and authenticate.
  3. Control+click on your account in the accounts table and choose "Advanced options".

You will see your User ID in the panel that appears.

This may be annoying from the perspective of trying to access those files on your remote Macintosh, but it is important for CCC to preserve the ownership and permissions information when backing up your data. If/when you want to do a restore, you could do either of the following:

a) Attach the external drive directly to the machine that you want to restore files to — the accounts on those systems will be able to access their backed up files.

b) Do a restore directly within CCC from the original source Macintosh.

If you must have read access to some of this data (e.g. the original Mac is gone, the user account changed, etc.), you can change the ownership of the home folder and its contents in the Finder:

  1. Choose Get Info from Finder's File menu.
  2. In the Sharing and Permissions section at the bottom, click on the lock icon to make the permissions editable.
  3. Click on the + button.
  4. In the window that appears, select your account, then click the Select button.
  5. Set the access privileges to Read & Write.
  6. Click on the Gear menu and choose to apply the change to enclosed items.

Making bootable backups on remote Macs

If you are attempting to create a bootable backup of your Mac, you should attach the backup disk directly to your local Mac for an initial backup task. After verifying that the backup volume is bootable, you can then attach that disk to a remote Macintosh and proceed with regular backups. You should also repeat the local backup any time you apply major operating system upgrades so that any helper partitions on the backup disk can be updated accordingly.

Related Documentation

Working with FileVault Encryption

$
0
0
Product: 
ccc5

CCC is fully qualified for use with FileVault-protected volumes (HFS+ and APFS). CCC offers some advice around enabling encryption in the Disk Center.

Enabling encryption on a volume that contains (or will contain) an installation of macOS

If your goal is to create a bootable, encrypted backup, use the following procedure:

  1. Follow CCC's documentation to properly format the destination volume. Do not format the volume as encrypted. Choose APFS if your Mac is a T2 Mac (e.g. iMacPro, any new Mac produced in late 2018).
  2. Use CCC to back up your startup disk to the unencrypted destination volume.
  3. Click on the destination volume in CCC's Disk Center, then click the Recovery HD button to create a Recovery HD volume. Note: You must be logged in to an administrator account to perform this step. [This step is unnecessary if your destination is an APFS-formatted volume]
  4. Open the Startup Disk preference pane and restart your Mac from backup volume.
  5. Enable FileVault encryption in the Security & Privacy preference pane of the System Preferences application.
  6. Reboot your Mac (it will reboot from the backup volume).
  7. Open the Startup Disk preference pane and restart your Mac from your production startup volume.
  8. Configure CCC for regular backups to your encrypted backup volume.

Note: You do not have to wait for the conversion process to complete before using the backup disk. Additionally, you do not have to remain booted from the backup disk for the conversion process to complete. You can simply enable FileVault encryption, then immediately reboot from your primary startup disk and the conversion process will carry on in the background. Encryption will continue as long as the backup disk is attached. macOS doesn't offer a convenient method to see conversion progress, but you can type diskutil apfs list (or diskutil cs list if the applicable volume is HFS+ formatted) in the Terminal application to see conversion progress. Some users have found that conversion may not resume until you log in to an admin account while booted from your production startup volume, so try that if conversion appears to be stalled.

What if I don't want my personal data to ever be on the destination in unencrypted form?

Enabling FileVault on the destination means that the volume starts out unencrypted, and then over the course of several hours the data is encrypted in place. If the encryption conversion process completes successfully, then no trace of the unencrypted data will be left on that disk. If the conversion process fails for any reason, however, then the data on that disk is potentially recoverable. If this is not acceptable, then we recommend that you exclude any sensitive data from the initial backup task. Don't exclude your whole home folder — you must include at least one folder from your home directory so that you can log in to that account on the backup. After you have booted from the backup volume and enabled FileVault, you can then reboot from the production startup disk, remove the exclusions from your backup task, then run the backup task again to copy the remainder of your data. Any data that is copied to a volume that is in the midst of encryption conversion will be encrypted immediately.

Enabling encryption on a volume that will not contain an installation of macOS

If your backup volume won't be a bootable backup of macOS, simply right-click on that volume in the Finder and choose the option to encrypt the volume. If your Mac is running macOS High Sierra or later, please note that macOS will convert an HFS+ formatted volume to APFS when you enable encryption in this manner.

Finder option

Related Documentation

Frequently Asked Questions about encrypting the backup volume

$
0
0
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). 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 Personalization Tool.

Viewing all 257 articles
Browse latest View live