Scheduling Basis

CCC offers seven different bases for automating backup tasks, giving you exceptional control over how and when your backup tasks run.

Do not run this task on a schedule

Select this option when you prefer that the task only run when you click the Start button. Note that you do not have to select this option to prevent a scheduled task from running. If you would like to temporarily disable a task, right-click on the task in CCC's sidebar and choose the option to disable the task. Likewise, you can suspend all tasks via the CCC Dashboard.

Run once at the specified time

This option is convenient when you would like to run a task in the near future, but not automatically thereafter. When the task completes, it will be reset to "Do not run this task on a schedule".

Hourly, Daily, Weekly, Monthly

When you want your task to run at specific times or intervals, these options give you the most precision.

When files are modified

This setting causes the task to monitor filesystem activity on the source. When folders are modified on the source, CCC will periodically enumerate the changes in those specific folders to determine how much data has been modified on the source since the task's last successful run. When the changes exceed your specified threshold, the task will run, copying just the items that have changed. This setting also offers a time-based threshold to avoid running the task too frequently.

When a task is actively monitoring the source, the Automation box will present a graphic that indicates how much data has been modified as a percentage of your defined threshold. If the data modification threshold has been reached, but the time threshold has not yet been reached, CCC will indicate that the task will run when the time threshold is met. Data changes are updated approximately every 30 seconds.

When a task is currently monitoring source filesystem activity, task settings cannot be modified (including the thresholds that determine when the task will run). If you would like to make changes to the task settings, click the "pause" button in the Automation box to temporarily suspend monitoring. If you would like to remove the filesystem monitor altogether, click the "stop" button in the Automation box.

CCC will suspend source volume monitoring if a task encounters errors while updating the destination. After reviewing the errors and taking any necessary corrective action, you can click the "play" button to resume monitoring. CCC will also suspend monitoring if the source or destination volume is unmounted, however monitoring will automatically resume when the missing volume is remounted as long as no errors occurred during the last task event.

Overriding Quick Update behavior to perform a complete scan of the source: The main action button will be titled "Run Now" when a task is configured to run when files are modified on the source. You can click that button any time to immediately update the destination using the Quick Update behavior. If you would like the task to perform a complete scan of the source, right-click on the Run Now button and choose Standard Copy.

This option is not available for "transient" destinations: This features relies on the source and destination being reliably available for monitoring. While CCC will accommodate the mounting and unmounting of local volumes for this scheduling option, this option is not currently available for tasks involving network volumes, nor disk image destinations. We welcome your feedback on this, and we will consider making this option available for those types of volumes in the future.

When the source or destination is remounted

Use this option when you want your task to run when your source or destination volume is remounted. When a task is configured in this manner, volume mount notifications are used to trigger the task. A task will only run when both volumes are present and mounted. Note that CCC will not automatically mount the source, for example, if it is not mounted when the destination reappears. Also note that CCC imposes a deliberate 60-second moratorium on task activity when the system is turned on. This task automation option is not designed to run tasks when volumes are mounted on startup.

By default, CCC will immediately run a task configured in this manner when the source or destination reappears. If you prefer, CCC can prompt you to run the task when a volume reappears, and CCC can also present a reminder if the task hasn't run after a particular amount of time. These prompts are presented by the CCC Dashboard, which offers additional settings for how reminders are presented to you. Click on the Activity tab's Settings icon in CCC Dashboard to configure those settings.

Lastly, you can configure a "throttle" to prevent these tasks from running too frequently. If you detach and reattach your backup disk frequently throughout the day, for example, you can configure the task to run no more frequently than once per day. Note that this interval can be specified as a decimal value. For example, if you would like the task to run no more frequently than twice per day, you can configure the threshold as "0.5".

Runtime Conditions

Sometimes time-based scheduling is insufficient to describe exactly how you want your tasks to run. CCC offers runtime conditions which allow you to restrict the running of your tasks under certain conditions when the task is normally scheduled to run.

Defer if another task is writing to the same destination

If you have more than one scheduled task that writes to the same destination volume, you may want to configure the tasks to wait for one another such that only one task is writing to the volume at a time. When you configure a task with this setting and the scheduled run time elapses, CCC will place the task into a queue for deferred execution if another task is already writing to that same destination. Assuming another run time condition does not prevent it, CCC will run the deferred task as soon as the first task finishes writing to the shared destination volume.

Limit which days of the week this task can run

This option allows you to limit a task to running only during weekdays or only during weekend days. This option is not applicable to the "weekly" and "monthly" scheduling settings.

Limit when this task can run

This option allows you to limit a task to running during specific hours of the day. For example, if you don't want your hourly task to run in the afternoons, you could set a start limit of 6PM and an end limit of 12PM. This limit would allow the task to start any time after 6PM and any time up to 12PM, thus preventing the task from running between 12PM and 6PM. If the task is already running (e.g. if it started at 11:55AM), CCC will stop the task if it is still running when the end limit is reached.

Note: Set the task start time before you attempt to set time limits. CCC will not allow you to specify a time limit that does not contain the current start time of the task.

Handling system sleep events

By default, CCC will wake your computer when your tasks are scheduled to run. You can change this setting in the Runtime Conditions section of the Scheduler popover. There are four options:

Wake the system, but skip tasks when the system is off

CCC will configure a wake event to wake the system shortly before the task runs, so the task should run on schedule. If the system is turned off, this wake event will not turn on the system. When the system is restarted (i.e. after having been turned off for a while), any tasks missed while the system was off will run at the next scheduled run time.

Wake or power on the system

CCC will configure a wake or power on event to wake the system or turn it on shortly before the task runs, so the task should run on schedule.

Run when the system next wakes

Upon a wake notification, CCC will run the backup task if its scheduled run time has passed. The task will not run exactly when it is scheduled, though CCC can run tasks during macOS Dark Wake events (aka PowerNap, aka Maintenance Wake), which occur every couple hours. If you want your backup tasks to run in the middle of the night without turning on your display, this is the right option for you.

Run when the system next wakes or powers on

Like the setting above, except that tasks missed when the system was off will start immediately when the system is turned on.

Skip this task

CCC will run the task only at its scheduled run time if the system is awake at that time. Upon a wake event, CCC will not run a backup task if the scheduled run time has passed.

Configuring behavior for when the source or destination is missing at the scheduled run time

Don't send error notifications

By default, CCC will report an error if the source or destination volume is unavailable when the task is scheduled to run. By enabling this option, CCC will suppress these errors. Additionally, if you have configured your task to send an email when errors occur, this option will suppress that email.

This option is not applicable for the When the source or destination is reconnected scheduling setting, because a task configured in that manner will only attempt to run if both the source and destination are present.

Run this task as soon as the missing volume reappears

If a backup task is missed because the source or destination was missing at the scheduled run time, this option will cause CCC to run the backup task as soon as that missing volume reappears.

Related Documentation

• Frequently asked questions about scheduled tasks

If you would like CCC to send your tasks' results via email, you must first configure a sending email account in CCC's Email Settings.

1. Click Preferences in the CCC toolbar.
2. Click the Email Settings button in the toolbar of the Preferences window.
3. Choose from one of the accounts imported from Mail in the Sent From Email popup menu, then verify the details and provide your account credentials in the form that is provided.
4. Click the OK button when you are finished entering your account details.

Note for advanced users: If your SMTP server requires SSL and uses a self-signed security certificate, check the Don't validate the certificate chain checkbox. Alternatively, you can add your server's security certificate to the System keychain in the Keychain Access application and explicitly trust that certificate.

[Optional] Modify the email subject and body template

The subject and body of the email that CCC sends upon task completion can be customized. For example, if you want to know which of your Mac's a particular email is coming from, you could customize the subject of the message:

    Jon's iMac: ##Task Name##: ##Exit Status##

When CCC sends an email notification, it will replace the template values (enclosed in double # characters) with the attributes of your task, e.g.:

    Jon's iMac: Daily Backup: Backup Finished Successfully

Most of the available template values are already present in the default template. You can rearrange the template values and modify the text around them, but do not modify the text inside of the double # characters. If you would like to add a template value:

1. Place the cursor where you would like to place the template value, e.g. in the subject or body text field.
2. Select a template value from the Template values popup menu.
3. Click the Insert button.

When you are finished making changes to your subject and body templates, click on the Save Changes button. This template will be used for all email notifications sent by CCC.

If you have suggestions for additional template values, please let us know!

Send a test email

Click on the Send Test Email... button at the bottom of the window. You will be prompted to provide an email address to send the test email to. When CCC indicates that the test email has been sent, check your email to confirm that you can receive it and that the template provides the information you wish to receive when your tasks complete.

Select a notification level

Close the Preferences window, then select the task to which you would like to add email notifications. Click the Advanced Settings button at the bottom of the window, then select the Postflight tab to reveal the email notification option. There are three notification levels:

• Don't send email: CCC will never send an email when this tasks finishes.
• Send after every run: CCC will send an email at the end of every task (i.e. successful tasks and those that report errors).
• Only send on errors: CCC will send an email only when errors occur for this task.

Select a notification level, then specify the email address(es) that you would like CCC to notify when the task completes. If you would like to have emails sent to multiple addresses, separate those addresses with a comma, or simply press the return key after typing in each address. The recipient text field may only show one address at a time. Use the arrow keys to see each address.

Once you have configured a notification level and recipients, choose Save from CCC's Task menu to save the changes.

Sending email with an SMTP service that requires an App Password

Because CCC sends emails from a background application, possibly when no user is logged in at all, CCC cannot practically support two-factor authentication. Many applications have this same logistical constraint, and most email providers will allow those applications to use the SMTP service, provided that you have created an application-specific password for that purpose. If you attempted to send an email with your Gmail or iCloud account (for example), and you get an error that "the username and password are invalid", or that "authentication failed", you can resolve the problem by creating an App Password.

Solution: Create an App Password for iCloud

Visit your Apple ID account page and create an application-specific password for CCC:

1. Sign in to your Apple ID account page.
2. In the Security section, click the Generate Password... link under the APP-SPECIFIC PASSWORDS heading and follow the steps provided.
3. Paste the application-specific password into the Email Settings panel of CCC's Preferences window.
4. Note: Be sure to use an @mac.com, @me.com, or @icloud.com email address for the user name.

Apple's reference: Using app-specific passwords

Solution: Create an App Password for Yahoo

Visit your Account Security page to generate an application-specific password for CCC:

1. Visit your Account Security page.
2. Click on the Generate app password link at the bottom of the page.
3. Click Select yourapp and choose Other App. Type in CCC as the custom name.
4. Click the Generate button.
5. Copy and paste the application-specific password into the Email Settings panel of CCC's Preferences window. Note: We recommend that you copy and paste the code. If you choose to transcribe it, take care not to insert spaces. The code is presented in four groups, but it does not actually contain spaces; it should be exactly 16 characters.

Solution: Create an App Password for Gmail

Visit your App Passwords page to generate an application-specific password for CCC:

1. Visit your App passwords page.
2. Click Select app and choose Other (custom name). Type in CCC.
3. Click the Generate button.
4. Paste the application-specific password into the Email Settings panel of CCC's Preferences window. Note: We recommend that you copy and paste the code. If you choose to transcribe it, take care not to insert spaces. The code is presented in four groups, but it does not actually contain spaces; it should be exactly 16 characters.
5. Note: Be sure to use an @gmail.com email address for the user name. G Suite accounts are not supported.

Google's reference: Sign in using App Passwords

"Your Gmail account will not permit CCC to send email notifications"

Google is very insistent that developers of third-party applications attain a Google Developer Account and subscribe to Google's proprietary APIs so they can use a special form of authentication with Gmail accounts (OAuth2). Developers that choose to use industry-standard authentication mechanisms instead are unjustly deemed as "less secure", and by default, Google will deny authentication requests from these applications. To add insult to injury, when an application attempts to authenticate to Gmail using the industry-standard authentication methods, Google sends you an email that suggests that the requesting application "doesn't meet modern security standards".

CCC absolutely uses modern security standards — TLS, in particular, to secure all traffic to the SMTP server. TLS has and continues to be the modern security standard for securing email communications. If you get a message that your Gmail account won't permit CCC to send email, we have two suggestions:

• Enable two-step verification on your Google account and then create an application password for CCC [this is our primary recommendation]

— Or —

• Change the settings in your Gmail account that Google disabled

Alternatively, you could just specify a non-Google email account in the Email Settings section of CCC's Preferences window.

Update your SMTP credentials after migrating to new Mac

When you provide your SMTP credentials to CCC, CCC stores them securely in a macOS Keychain file. That keychain file is secured in several ways; it is readable only by the macOS system administrator account, it can only be unlocked by CCC, and it can only be unlocked on the Mac upon which it was originally created. As a result, if you purchase a new Mac and migrate your data to the new Mac, CCC's keychain will not work on the new system and CCC will be unable to send email notifications. After migrating to a new system, open CCC's Email Settings, click the Edit... button, then re-enter your SMTP account credentials.

To access the advanced settings, click the Advanced Settings button at the bottom of the window.

Preflight

See these two sections of documentation for detailed information about the settings available in the Preflight tab:

• Performing actions Before and After the backup task
• Automated maintenance of the CCC SafetyNet folder

File Copying Settings

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 back up 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. This option is also disabled if the originally-selected destination device is not attached.

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

The "root" of the destination refers to the first or top-most folder relative to your selected destination. If you selected a volume named CCC Backup as the destination, then the root level refers to the root of the volume — what you see when you open that volume in the Finder (the middle pane in the screenshot above). If you selected a folder as the destination for your task, then the "items at the root of the destination" refers to the items that you find in that specific folder that you selected as the destination, not the root of the whole volume. When you select a folder as the destination, anything outside of that folder is completely outside of the scope of the backup task, and will be left alone by that particular backup task.

Run a deletion pass first

This setting is only applicable when using a Remote Macintosh source or destination. In all other cases, CCC will automatically perform a deletion pass when necessary

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.

Postflight

See these sections of documentation for detailed information about the settings available in the Postflight tab:

• Postflight verification: Verify files that were copied during the current task event
• Performing actions Before and After the backup task

Performance & Analysis

Maintain a record of transactions

This option enables the collection of a list of files and folders that were modified by each task event. See these articles for more information about CCC's collection and use of transactions:

• Audits: Viewing details about the modifications made by the backup task
• Transaction privacy and disabling transaction collection

Use Quick Update when it's possible to collect a list of modified folders from macOS

macOS operates a service that tracks filesystem activity on locally-attached volumes. This "FSEvents" service can be queried to get a list of folders that have been modified since a particular time. When this feature is enabled, the CCC task will limit its enumeration of the source to only the folders that were modified since the last time this particular task ran successfully. This feature can greatly decrease the overall run time for each backup task event.

This feature assumes that the destination is not modified outside of the task's purview. This is not an insignificant assumption, and that's why this feature is disabled by default. You must assess your usage of the destination when deciding whether to use this feature. If you make modifications to the destination outside of CCC, or by another CCC backup task, then those modifications may not be accommodated for (or corrected, for example, if you deleted something from the destination) when this feature is enabled.

If you ever want to verify that the destination is whole, you can right-click on the Quick Update button and choose the Standard Copy option to have CCC do a one-time enumeration of the entire source and destination.

Quick Update is overridden when some task settings are modified, and when errors are encountered

If you change the source or destination to your backup task, or if you make any modifications to the task Filter, CCC will perform a regular backup when the task next runs. Additionally, if errors were encountered during a backup task event, CCC will use the start time of the last successful event as the basis for collecting a list of modified folders. After the task completes successfully, Quick Update will be used for subsequent task events.

File copier CPU priority

By default, CCC runs its file copier at the default CPU priority for maximum performance. If you find that your backups have a noticeable impact on system performance, you can either schedule your tasks to run at a more convenient time, or you can reduce the CPU priority of the file copier. This will generally make the task take longer, but the task should have a less noticeable impact on system performance.

Find and replace corrupted files, "Backup Health Check"

See this Kbase article for additional details on the "Find and replace corrupted files" option:

• Backup Health Check: Verify before copying, automatically replace corrupted destination files

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 postflight tasks, click the Advanced Settings button at the bottom of CCC's main window.

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

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 a task failure, though it will make a note of the event in the Errors tab of the Task History window.

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. Only the first task in a chain needs to be scheduled to start the chain.

Note: Postflight tasks will not be started if the current task was started via a task group. When you run a task group, we're specifically aiming to run exactly the tasks within that task group, and within the order specified. If you run the task manually, however, or if the task is run separately from the group on its own schedule, then the task's postflight task will be 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 postflight shell scripts may be the solution for you. Preflight 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.

Postflight 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 postflight 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 postflight scripts, underlying volume path for a disk image for preflight 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 postflight 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). On macOS Catalina and later, if the source volume is a System volume, CCC will send the path to a snapshot of the Data sibling of the source as the first parameter.

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. On macOS Catalina and later, if the destination volume is a System volume, CCC will send the path to the Data sibling of the destination as the second parameter, e.g. "/Volumes/CCC Backup - Data".

Third parameter

• Preflight script: The underlying mountpoint for the volume that holds the destination disk image, if applicable.
• Postflight 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 preflight 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 preflight 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 postflight 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
    # task succeeded
else
    # task failed or reported errors
    # 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 postflight 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.

Shell scripts run as the root user

CCC's pre- and postflight shell scripts are executed as the System Administrator (aka "root"). As such, any references to your own shell environment will be invalid. When referencing tools that lie outside of the default $PATH, be sure to either specify the full path to the item (e.g. /usr/local/bin/foo), or export your own $PATH at the top of your script. Likewise, if you make relative references to files (e.g. ~/Desktop/foo.log), those files will be created in the root user account, e.g. /var/root/Desktop/foo.log. Use absolute paths for more reliable results.

Security implications of pre- and postflight shell scripts

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 postflight 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 postflight 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 preflight 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 postflight 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 postflight script will resume any Parallels VM containers that were suspended by the parallels_pause.sh preflight 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 postflight 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 postflight 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.

This article's content is not relevant when snapshot support is enabled on an APFS-formatted destination volume. See Toggling snapshot support and setting a Snapshot Retention Policy for more information on SafetyNet Snapshot retention.

CCC will move previous versions of modified files, as well as files deleted since previous backup tasks to a SafetyNet folder at the root of the destination. If left unmanaged, this SafetyNet folder would eventually consume all free space on your destination volume. To prevent that from happening, CCC prunes the contents of the SafetyNet folder at the beginning of each task if free space is less than 25GB. This limit is automatically adjusted if a 25GB limit is too low for a particular source and destination. You can customize these settings by clicking on the Advanced Settings button at the bottom of CCC's main window.

SafetyNet pruning occurs at the beginning of a backup task, so CCC will never delete an item that was archived in the current backup task. Additionally, pruning is always limited to the contents of the _CCC SafetyNet folder that is at the root of the destination. CCC's pruner won't delete the current versions of files on your destination, nor anything outside of the scope of the CCC backup task. Lastly, archive pruning works at a macro level. If any portion of an archive pushes past the limit that you have imposed, the entire archive (e.g. the time-stamped folder) will be pruned.

Note for "New disk image" destinations: CCC applies more aggressive SafetyNet pruning to disk image volumes. By default, CCC will prune any SafetyNet content older than 1 day.

Automatically prune archived content before copying files

Prune archives in the SafetyNet when free space is less than [xx] GB

If your destination volume has less free space than the limit that you have specified, CCC will prune the oldest archive. CCC will continue to prune the oldest archive until the requested amount of free space has been achieved. Note that if the archives cumulatively consume less space than the limit requested and the destination volume is full, CCC will prune all of the archives.

Auto Adjustment of the SafetyNet Free Space pruning limit

When the Auto Adjust option is enabled (and it's enabled by default), CCC will automatically increase the free space pruning limit if your destination runs out of free space during the backup task. For example, if your pruning limit is set to the default of 25GB, and you have 25GB of free space at the beginning of the backup task, no pruning will be done at the beginning of the task. If that task proceeds to copy more than 25GB of data, however, the destination will become full. CCC will then increase the pruning limit by the larger of either the amount of data copied in the current task, or by the amount of data that was required by the last file CCC attempted to copy. For example, if CCC copied 25GB of data, then the pruning limit would be increased by 25GB. If CCC wanted to copy a 40GB file, however, CCC would not fruitlessly copy 25GB of that file, rather it would immediately increase the pruning limit by 40GB, revisit pruning, and then resume copying.

Prune archives in the SafetyNet when they are older than [xx] days

CCC will prune archives that were created more than "xx" days ago.

Prune archives in the SafetyNet when they are larger than [xx] GB

Starting with the most recent archive, CCC will determine the amount of disk space that each archive consumes. When the cumulative total exceeds the limit that you have imposed, CCC will prune the remaining, older archives. If the newest archive is larger than the limit that you have specified, that archive will be pruned in entirety.

Never prune archives in the SafetyNet

CCC will not automatically prune the contents of the "_CCC SafetyNet" folder at the root of the destination. Archived files may eventually consume all of the free space on the destination, so you should periodically delete older archive folders to maintain enough free space for future backups. You may delete the contents of the SafetyNet folder without harm to the rest of your backup set.

"CCC is pruning my SafetyNet, but the disk is still pretty full at the end of the backup task"

The purpose of CCC's SafetyNet pruning is to make space for additional backups. CCC also avoids pruning items that were very recently archived — after all, it wouldn't make sense to archive an item on the destination, them immediately delete it. To accommodate both of these goals, CCC prunes archives within the SafetyNet before the backup task runs. Pruning the SafetyNet immediately before copying files gives a greater level of assurance that the requested amount of free space (for example) will be available for the current backup. Be sure to consider this detail when specifying your SafetyNet pruning settings. If you want to retain additional space on your backup volume beyond what is required for your CCC backups, specify more liberal limits (e.g. 100GB of free space rather than 25GB).

"Can I use the _CCC SafetyNet folder for long-term archiving of specific items?"

We don't recommend using the SafetyNet for long-term storage. CCC is configured to automatically prune the SafetyNet, by default, when free space on the destination is less than 25GB at the beginning of the backup task, and that limit may increase automatically. CCC doesn't consider whether items in the _CCC SafetyNet folder were placed there by CCC or another application, everything is considered safe to delete when the time is right. If you would like to maintain a permanent archive of items on your backup volume, outside of your CCC backup, we recommend that you create a separate volume on your backup disk for this purpose.

We also recommend that you maintain a backup of your archived data on another volume! If you don't have a backup of your long-term archived items, you're going to lose them forever if your backup disk fails.

"I manually moved the _CCC SafetyNet folder to the Trash, but now I get an error when trying to empty the Trash"

When CCC backs up your startup disk, it runs with the privileges required to access system files that are not normally accessible to your account. Naturally, some of these files will be updated on the source, and subsequently archived on the destination. When you place these items in the Trash (by placing the _CCC SafetyNet folder in the Trash), and subsequently try to empty the Trash, the Finder typically requests that you authenticate to remove these files. Sometimes the Finder is having a bad day, though, and it simply reports the enlightening "-8003" error when you try to empty the Trash (or something equally obtuse). This error isn't defined or documented anywhere, but through trial and error, we have figured out that it simply means "I can't cope with your request to empty the Trash".

The solution is to avoid using the Finder to delete a CCC SafetyNet folder. Choose Delete a SafetyNet Folder from CCC's Utilities menu instead and use that interface to manually remove SafetyNet folders.

Additional References

• Apple Kbase HT201583: You can‘t empty the Trash or move a file to the Trash

Related Documentation

• Frequently asked questions about the CCC SafetyNet

CCC is fully qualified for use with FileVault-protected volumes (HFS+ and APFS).

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

If you're not creating a legacy bootable backup, and if you have no intention of installing macOS onto your backup volume, there are two simple options for encrypting the backup:

• New backup: Erase the backup volume as APFS Encrypted in Disk Utility.
• Existing backup: Right-click on the volume in the Finder and choose the option to encrypt the volume.

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

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

1. Follow CCC's documentation to properly format the destination volume. Choose APFS as the format, do not format the volume as encrypted.
2. Use CCC to back up your startup disk to the unencrypted destination volume. [Big Sur users, use the Legacy Bootable Backup Assistant]
3. Reboot your Mac while holding dow the Option key (Intel Macs) or the Power key (Apple Silicon Macs) and choose your backup disk as the startup disk.
4. Enable FileVault encryption in the Security & Privacy preference pane of the System Preferences application.
5. As soon as the encryption conversion procedure begins, you may reboot your Mac — it will automatically reboot from the production startup disk.
6. Configure CCC for regular backups to your encrypted backup volume.

You do not have to wait for the conversion process to complete before rebooting from your production startup disk

You do not have to wait for the conversion process to complete before using your backup disk. 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 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.

Keep your Mac plugged into AC power for the duration of encryption conversion

We have received a handful of reports from macOS Catalina users indicating that encryption conversion remains permanently paused if AC power is removed during the encryption conversion process. We have been unable to reproduce this result in our test lab — typically encryption conversion pauses when AC power is removed, but then resumes when AC power is restored. The number of reports to us, however, suggests that there is some underlying problem that may be new to macOS Catalina. To avoid this result, we recommend that you keep your Mac plugged in to AC power for the duration of encryption conversion. If you see an indication that encryption conversion is paused, try leaving the system plugged into AC overnight.

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 for most intents and purposes, no trace of the unencrypted data will be left on that disk. There are some caveats however. If your backup volume is an SSD, and if you delete files from the SSD prior to enabling encryption, then the SSD may automatically move the not-yet-encrypted underlying blocks out of rotation (for wear leveling), and those data could be recoverable by experts. Likewise, if the conversion process fails for any reason, then the data on that disk is potentially recoverable. If either of these scenarios 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.

Note for Big Sur users: Do not use the Legacy Bootable Backup Assistant to configure your initial backup task, you will not be able to exclude content from a Full Volume Clone. After the initial Standard Backup has completed, proceed to install Big Sur onto the destination. After installation has completed, enable FileVault, then reboot from your production startup disk and run your CCC backup task again without the exclusions.

Related Documentation

• Frequently Asked Questions about encrypting the backup volume
• The Disk Center
• [Apple Kbase] Learn more about FileVault

CCC maintains a list of certain files and folders that are automatically excluded from a backup task. The contents of this list were determined based on Apple recommendations and years of experience. The following is a list of the items that are excluded along with an explanation of why they are excluded.

Legend:
Items prefixed with a "/" indicate that they will only be ignored if located at the root of the volume.
Items postfixed with a "/*" indicate that only the contents of those folders are ignored, the folders themselves will be copied.
Items postfixed with a "*" indicate that the filename will be matched up to the asterisk.

Filesystem implementation details

• .HFS+ Private Directory Data*
• /.journal
• /.journal_info_block
• .afpDeleted*
• ._*
• .AppleDouble
• .AppleDB
• /lost+found
• Network Trash Folder
• .TemporaryItems

These items only show up if you're running an older OS than what was used to format the source volume, and on some third-party implementations of AFP and SMB network filesystems. These items should never, ever be manipulated by third-party programs.

Volume-specific preferences

• .metadata_never_index
• .metadata_never_index_unless_rootfs
• /.com.apple.timemachine.donotpresent
• .VolumeIcon.icns
• /System/Library/CoreServices/.disk_label*
• /TheVolumeSettingsFolder
• /private/var/db/dslocal/nodes/Default/secureaccesstoken.plist

These items record volume-specific preferences, e.g. for Spotlight, Time Machine, and a custom icon for the volume. Feedback on the exclusion of these items is welcome. Because they are volume-specific preferences, the exclusion of these items from a day-to-day backup seems most appropriate.

Apple-proprietary data stores

• .DocumentRevisions-V100*
• .Spotlight-V100
• /.fseventsd
• /.hotfiles.btree
• /private/var/db/systemstats
• /private/var/folders/*/*/C
• /private/var/folders/*/*/T

These items are Apple-proprietary data stores that get regenerated when absent. Attempting to copy these data stores without unmounting the source and destination is not only futile, it will likely corrupt them (and their respective apps will reject them and recreate them).

The DocumentRevisions data store is used by the Versions feature in macOS. The Versions database stored in this folder contains references to the inode of each file that is under version control. File inodes are volume-specific, so this dataset will have no relevance on a backup volume.

Volume-specific cache files

• /private/var/db/dyld/dyld_*
• /System/Library/Caches/com.apple.bootstamps/*
• /System/Library/Caches/com.apple.corestorage/*

Copying these caches to a new volume will render that volume unbootable. The caches must be regenerated on the new volume as the on-disk location of system files and applications will have changed. macOS automatically regenerates the contents of these folders when CCC is finished updating the backup volume.

NetBoot local data store

• /.com.apple.NetBootX

In the unlikely event that your Macintosh is booted from a Network device, macOS will store local modifications to the filesystem in this folder. These local modifications are not stored in a restorable format, therefore should not be backed up. In general, you should not attempt to back up a NetBooted Mac.

Dynamically-generated devices

• /Volumes/*
• /dev/*
• /automount
• /Network
• /.vol/*
• /net

These items represent special types of folders on macOS. These should not be backed up, they are dynamically created every time you start the machine.

Quota real-time data files

• /.quota.user
• /.quota.group

When these files are copied to a destination volume using an atomic file copying procedure, the macOS kernel will prevent the destination from being gracefully unmounted. The contents of these files is never accurate for the destination volume, so given the kernel's unruly behavior with copies of these files, CCC excludes them. According to the quotacheck man page, these files should be regenerated every time a quota-enabled volume is mounted (e.g. on startup). We have not found that to be consistently true. If you're using quotas, run sudo quotacheck / after restarting from your backup volume or a restored replacement disk to regenerate these files.

Large datastores that are (or should be) erased on startup

• /private/var/vm/*
• /private/tmp/*
• /cores
• /macOS Install Data

macOS stores virtual memory files and your hibernation image (i.e. the contents of RAM are written to disk prior to sleeping) and temporary items in these folders. Depending on how you use macOS and your hardware configuration, this could be more than 50GB of data, and all of it changes from one hour to the next. Having this data for a full-disk restore does you absolutely no good — it makes the backup and restore processes take longer and the files get deleted the next time you boot macOS.

Trash

• .Trash
• .Trashes

Moving an item to the trash is typically considered to be an indication that you are no longer interested in retaining that item. If you don't want CCC to exclude the contents of the Trash, you can modify each task's filter:

1. Choose Copy Some Files from the popup menu underneath the Source selector
2. Click the Inspector button adjacent to that same popup menu to reveal the Task Filter window
3. Uncheck the box next to Don't copy the Finder's Trash
4. Click the Done button

Time Machine backups

These folders store Time Machine backups. Time Machine uses proprietary filesystem devices that Apple explicitly discourages third-party developers from using. Additionally, Apple does not support using a duplicated Time Machine volume and recommends instead that you start a new Time Machine backup on the new disk.

• /Backups.backupdb
• /.MobileBackups
• /.MobileBackups.trash
• /private/var/db/com.apple.backupd.backupVerification

Corrupted iCloud Local Storage

iCloud leverages folders in your home directory for local, offline storage. When corruption occurs within these local data stores, macOS moves/renames the corrupted items into the folders indicated below. macOS doesn't report these corrupted items to you, nor does it attempt to remove them. CCC can't copy the corrupted items, because they're corrupted. To avoid the errors that would occur when trying to copy these corrupted items, CCC excludes the following items from every backup task:

• Library/Mobile Documents.* [Note: This exclusion is specific to Mobile Documents.{something} folders that have a corruption suffix, not to the non-corrupted "Mobile Documents" folder]
• .webtmp

Special files

Files included in this section are application-specific files that have demonstrated unique behavior. The kacta and kactd files, for example, are created by antivirus software and placed into a special type of sandbox that makes them unreadable by any application other than the antivirus software.

The "com.apple.loginwindow" item can be found in each user home folder. Excluding this item prevents the applications that were open during the backup task from opening when you boot from a restored backup. This seems appropriate considering that Apple intends the feature to be used to open the applications that were in use when you log out, restart or shutdown, not at an arbitrary point during the backup task.

• /private/tmp/kacta.txt
• /private/tmp/kactd.txt
• /private/var/audit/*.crash_recovery
• /private/var/audit/current
• /Library/Caches/CrashPlan
• /PGPWDE01
• /PGPWDE02
• /.bzvol
• /.cleverfiles
• /Library/Application Support/Comodo/AntiVirus/Quarantine
• /private/var/spool/qmaster
• $Recycle.Bin
• Library/Preferences/ByHost/com.apple.loginwindow*
• .dropbox.cache
• /private/var/db/atpstatdb*
• .@__thumb
• /.com.prosofteng.DrivePulse.ignore
• com.apple.photolibraryd/tmpoutboundsharing

CCC SafetyNet folders

When CCC's SafetyNet feature is enabled, CCC creates a _CCC SafetyNet folder at the root of the selected destination volume or folder. When CCC encounters an item on the destination that does not exist on the source, or an item that will be replaced with an updated item from the source, that item gets placed into the SafetyNet folder rather than being deleted immediately. The SafetyNet folder is literally a safety net for files on your destination. If you accidentally delete a file from the source and you don't realize it until after your backup task runs, you'll find the item in the SafetyNet folder. Likewise, if you accidentally specify the wrong volume as a destination to a CCC backup task, the mistake does not catastrophically delete every file from the selected destination; you simply recover the items from the _CCC SafetyNet folder.

The protection that the SafetyNet folder imparts is specific to the volume upon which the SafetyNet folder resides. As such, CCC never includes the contents of the _CCC SafetyNet folder in a backup task. So, for example, if your hard drive fails and you restore your backup to a replacement disk, the _CCC SafetyNet folder is automatically excluded from that restore task. If you have several tasks backing up to separate folders on a backup volume, for example, the _CCC SafetyNet folders that are created in those subfolders would not be included in a secondary backup task that copies your backup disk to a third disk.

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

This feature is not intended for backing up macOS system files. Do not select a macOS system volume as the source or destination to a Remote Macintosh task.

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

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.

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 file ownership. 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.

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 (').

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.13 or later. Non-Macintosh systems are not supported with the Remote Macintosh feature.

Additional pointers for advanced users

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

Snapshot support on remote Macs

Snapshot support is not available for volumes attached to a remote Macintosh.

Related Documentation

• Restoring from a backup on a remote Macintosh
• A caveat for backing up to a remote Macintosh that has no user logged in

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.

Use CCC's Quick Update feature

The Quick Update feature can greatly reduce the amount of time it takes to compare items on the source and destination. Rather than evaluating all files and folders in the source data set, CCC will collect a list of folders that have been modified since the last backup task from the macOS FSEvents service. Especially for data sets with a lot of small files in folders that are infrequently modified, this feature can improve performance by many orders of magnitude. Click the Advanced Settings button at the bottom of the CCC window, then you'll find the Quick Update option in the Performance & Analysis tab.

Reduce the number of files considered for backup

If the aforementioned Quick Update feature is not applicable (e.g. because the source volume doesn't support it), and if you have a particularly high number of files on your source volume, you may be able to reorganize your data set and apply some exclusions to improve task performance. 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 configure the Task Filter to do so), 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 enumerating through those files for changes.

Related Documentation

• Excluding files and folders from a backup task
• Folder-to-Folder Backups

Hard drive performance and interface bandwidth

Your backups will be no faster than your slowest disk. 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 — USB 3.1 is faster than USB 3.0, USB 3.0 is faster than USB 2.0, etc.

Additionally, if your source volume is nearly full and is a rotational disk, we recommend that you replace it with a larger hard drive to avoid the performance implications of filesystem fragmentation.

CCC's file copier is tuned for modern, high performance storage

When we developed our new file copier in CCC v6, one of our design goals was to take full advantage of the performance that is available from modern SSD and NVMe storage devices. The CCC "Core Copy Engine" can process up to four folders at once, and copy up to eight files at a time. This multi-threaded approach yields blazing-fast transfers of very large amounts of data between fast devices – typically exceeding CCC v5's legacy file copier performance by 50% or more, and meeting or exceeding Finder copying performance.

These design decisions do present a performance disadvantage, however, for slower hardware, e.g. "slim" or "portable" 2.5" rotational HDDs. Slower rotational devices may not perform well when tasked with enumerating four folders at a time. While the initial backup to these devices will be slower than with CCC v5, subsequent updates to the backup that use the Quick Update feature noted above will perform substantively better than CCC v5 updates to the backup.

Filesystem performance and hardware type

It's important to choose the right filesystem for the hardware that you have and the data that you're backing up. If you have an older, rotational HDD, it's generally better to format that device using the "Mac OS Extended, Journaled" (HFS+) format if you're making a data-only backup. APFS is the new, modern standard, but its performance on rotational devices is inferior to HFS+. If you're making a backup of a macOS Catalina System volume, APFS is required. If you find the performance of your backups to be too slow, we recommend using an SSD for your backups.

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 backup completes 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, or to one of the other options offered in the popup menu adjacent to that setting.

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

If you're still having trouble identifying a performance problem, we're here to help.

Related Documentation

• Troubleshooting slow performance when copying files to or from a network volume

If you would like CCC to send your tasks' results via email, you must first configure a sending email account in CCC's Email Settings.

1. Click Preferences in the CCC toolbar.
2. Click the Email Settings button in the toolbar of the Preferences window.
3. Choose from one of the accounts imported from Mail in the Sent From Email popup menu, then verify the details and provide your account credentials in the form that is provided.
4. Click the OK button when you are finished entering your account details.

Note for advanced users: If your SMTP server requires SSL and uses a self-signed security certificate, check the Don't validate the certificate chain checkbox. Alternatively, you can add your server's security certificate to the System keychain in the Keychain Access application and explicitly trust that certificate.

[Optional] Modify the email subject and body template

The subject and body of the email that CCC sends upon task completion can be customized. For example, if you want to know which of your Mac's a particular email is coming from, you could customize the subject of the message:

    Jon's iMac: ##Task Name##: ##Exit Status##

When CCC sends an email notification, it will replace the template values (enclosed in double # characters) with the attributes of your task, e.g.:

    Jon's iMac: Daily Backup: Backup Finished Successfully

Most of the available template values are already present in the default template. You can rearrange the template values and modify the text around them, but do not modify the text inside of the double # characters. If you would like to add a template value:

1. Place the cursor where you would like to place the template value, e.g. in the subject or body text field.
2. Select a template value from the Template values popup menu.
3. Click the Insert button.

When you are finished making changes to your subject and body templates, click on the Save Changes button. This template will be used for all email notifications sent by CCC.

If you have suggestions for additional template values, please let us know!

Send a test email

Click on the Send Test Email... button at the bottom of the window. You will be prompted to provide an email address to send the test email to. When CCC indicates that the test email has been sent, check your email to confirm that you can receive it and that the template provides the information you wish to receive when your tasks complete.

Select a notification level

Close the Preferences window, then select the task to which you would like to add email notifications. Click the Advanced Settings button at the bottom of the window, then select the Postflight tab to reveal the email notification option. There are three notification levels:

• Don't send email: CCC will never send an email when this tasks finishes.
• Send after every run: CCC will send an email at the end of every task (i.e. successful tasks and those that report errors).
• Only send on errors: CCC will send an email only when errors occur for this task.

Select a notification level, then specify the email address(es) that you would like CCC to notify when the task completes. If you would like to have emails sent to multiple addresses, separate those addresses with a comma, or simply press the return key after typing in each address. The recipient text field may only show one address at a time. Use the arrow keys to see each address.

Once you have configured a notification level and recipients, choose Save from CCC's Task menu to save the changes.

Sending email with an SMTP service that requires an App Password

Because CCC sends emails from a background application, possibly when no user is logged in at all, CCC cannot practically support two-factor authentication. Many applications have this same logistical constraint, and most email providers will allow those applications to use the SMTP service, provided that you have created an application-specific password for that purpose. If you attempted to send an email with your Gmail or iCloud account (for example), and you get an error that "the username and password are invalid", or that "authentication failed", you can resolve the problem by creating an App Password.

Solution: Create an App Password for iCloud

Visit your Apple ID account page and create an application-specific password for CCC:

1. Sign in to your Apple ID account page.
2. In the Security section, click the Generate Password... link under the APP-SPECIFIC PASSWORDS heading and follow the steps provided.
3. Paste the application-specific password into the Email Settings panel of CCC's Preferences window.
4. Note: Be sure to use an @mac.com, @me.com, or @icloud.com email address for the user name.

Apple's reference: Using app-specific passwords

Solution: Create an App Password for Yahoo

Visit your Account Security page to generate an application-specific password for CCC:

1. Visit your Account Security page.
2. Click on the Generate app password link at the bottom of the page.
3. Click Select yourapp and choose Other App. Type in CCC as the custom name.
4. Click the Generate button.
5. Copy and paste the application-specific password into the Email Settings panel of CCC's Preferences window. Note: We recommend that you copy and paste the code. If you choose to transcribe it, take care not to insert spaces. The code is presented in four groups, but it does not actually contain spaces; it should be exactly 16 characters.

Solution: Create an App Password for Gmail

Visit your App Passwords page to generate an application-specific password for CCC:

1. Visit your App passwords page.
2. Click Select app and choose Other (custom name). Type in CCC.
3. Click the Generate button.
4. Paste the application-specific password into the Email Settings panel of CCC's Preferences window. Note: We recommend that you copy and paste the code. If you choose to transcribe it, take care not to insert spaces. The code is presented in four groups, but it does not actually contain spaces; it should be exactly 16 characters.
5. Note: Be sure to use an @gmail.com email address for the user name. G Suite accounts are not supported.

Google's reference: Sign in using App Passwords

"Your Gmail account will not permit CCC to send email notifications"

Google is very insistent that developers of third-party applications attain a Google Developer Account and subscribe to Google's proprietary APIs so they can use a special form of authentication with Gmail accounts (OAuth2). Developers that choose to use industry-standard authentication mechanisms instead are unjustly deemed as "less secure", and by default, Google will deny authentication requests from these applications. To add insult to injury, when an application attempts to authenticate to Gmail using the industry-standard authentication methods, Google sends you an email that suggests that the requesting application "doesn't meet modern security standards".

CCC absolutely uses modern security standards — TLS, in particular, to secure all traffic to the SMTP server. TLS has and continues to be the modern security standard for securing email communications. If you get a message that your Gmail account won't permit CCC to send email, we have two suggestions:

• Enable two-step verification on your Google account and then create an application password for CCC [this is our primary recommendation]

— Or —

• Change the settings in your Gmail account that Google disabled

Alternatively, you could just specify a non-Google email account in the Email Settings section of CCC's Preferences window.

Update your SMTP credentials after migrating to new Mac

When you provide your SMTP credentials to CCC, CCC stores them securely in a macOS Keychain file. That keychain file is secured in several ways; it is readable only by the macOS system administrator account, it can only be unlocked by CCC, and it can only be unlocked on the Mac upon which it was originally created. As a result, if you purchase a new Mac and migrate your data to the new Mac, CCC's keychain will not work on the new system and CCC will be unable to send email notifications. After migrating to a new system, open CCC's Email Settings, click the Edit... button, then re-enter your SMTP account credentials.

This article's content is not relevant when snapshot support is enabled on an APFS-formatted destination volume. See Toggling snapshot support and setting a Snapshot Retention Policy for more information on SafetyNet Snapshot retention.

CCC will move previous versions of modified files, as well as files deleted since previous backup tasks to a SafetyNet folder at the root of the destination. If left unmanaged, this SafetyNet folder would eventually consume all free space on your destination volume. To prevent that from happening, CCC prunes the contents of the SafetyNet folder at the beginning of each task if free space is less than 25GB. This limit is automatically adjusted if a 25GB limit is too low for a particular source and destination. You can customize these settings by clicking on the Advanced Settings button at the bottom of CCC's main window.

SafetyNet pruning occurs at the beginning of a backup task, so CCC will never delete an item that was archived in the current backup task. Additionally, pruning is always limited to the contents of the _CCC SafetyNet folder that is at the root of the destination. CCC's pruner won't delete the current versions of files on your destination, nor anything outside of the scope of the CCC backup task. Lastly, archive pruning works at a macro level. If any portion of an archive pushes past the limit that you have imposed, the entire archive (e.g. the time-stamped folder) will be pruned.

Note for "New disk image" destinations: CCC applies more aggressive SafetyNet pruning to disk image volumes. By default, CCC will prune any SafetyNet content older than 1 day.

Automatically prune archived content before copying files

Prune archives in the SafetyNet when free space is less than [xx] GB

If your destination volume has less free space than the limit that you have specified, CCC will prune the oldest archive. CCC will continue to prune the oldest archive until the requested amount of free space has been achieved. Note that if the archives cumulatively consume less space than the limit requested and the destination volume is full, CCC will prune all of the archives.

Auto Adjustment of the SafetyNet Free Space pruning limit

When the Auto Adjust option is enabled (and it's enabled by default), CCC will automatically increase the free space pruning limit if your destination runs out of free space during the backup task. For example, if your pruning limit is set to the default of 25GB, and you have 25GB of free space at the beginning of the backup task, no pruning will be done at the beginning of the task. If that task proceeds to copy more than 25GB of data, however, the destination will become full. CCC will then increase the pruning limit by the larger of either the amount of data copied in the current task, or by the amount of data that was required by the last file CCC attempted to copy. For example, if CCC copied 25GB of data, then the pruning limit would be increased by 25GB. If CCC wanted to copy a 40GB file, however, CCC would not fruitlessly copy 25GB of that file, rather it would immediately increase the pruning limit by 40GB, revisit pruning, and then resume copying.

Prune archives in the SafetyNet when they are older than [xx] days

CCC will prune archives that were created more than "xx" days ago.

Prune archives in the SafetyNet when they are larger than [xx] GB

Starting with the most recent archive, CCC will determine the amount of disk space that each archive consumes. When the cumulative total exceeds the limit that you have imposed, CCC will prune the remaining, older archives. If the newest archive is larger than the limit that you have specified, that archive will be pruned in entirety.

Never prune archives in the SafetyNet

CCC will not automatically prune the contents of the "_CCC SafetyNet" folder at the root of the destination. Archived files may eventually consume all of the free space on the destination, so you should periodically delete older archive folders to maintain enough free space for future backups. You may delete the contents of the SafetyNet folder without harm to the rest of your backup set.

"CCC is pruning my SafetyNet, but the disk is still pretty full at the end of the backup task"

The purpose of CCC's SafetyNet pruning is to make space for additional backups. CCC also avoids pruning items that were very recently archived — after all, it wouldn't make sense to archive an item on the destination, them immediately delete it. To accommodate both of these goals, CCC prunes archives within the SafetyNet before the backup task runs. Pruning the SafetyNet immediately before copying files gives a greater level of assurance that the requested amount of free space (for example) will be available for the current backup. Be sure to consider this detail when specifying your SafetyNet pruning settings. If you want to retain additional space on your backup volume beyond what is required for your CCC backups, specify more liberal limits (e.g. 100GB of free space rather than 25GB).

"Can I use the _CCC SafetyNet folder for long-term archiving of specific items?"

We don't recommend using the SafetyNet for long-term storage. CCC is configured to automatically prune the SafetyNet, by default, when free space on the destination is less than 25GB at the beginning of the backup task, and that limit may increase automatically. CCC doesn't consider whether items in the _CCC SafetyNet folder were placed there by CCC or another application, everything is considered safe to delete when the time is right. If you would like to maintain a permanent archive of items on your backup volume, outside of your CCC backup, we recommend that you create a separate volume on your backup disk for this purpose.

We also recommend that you maintain a backup of your archived data on another volume! If you don't have a backup of your long-term archived items, you're going to lose them forever if your backup disk fails.

"I manually moved the _CCC SafetyNet folder to the Trash, but now I get an error when trying to empty the Trash"

When CCC backs up your startup disk, it runs with the privileges required to access system files that are not normally accessible to your account. Naturally, some of these files will be updated on the source, and subsequently archived on the destination. When you place these items in the Trash (by placing the _CCC SafetyNet folder in the Trash), and subsequently try to empty the Trash, the Finder typically requests that you authenticate to remove these files. Sometimes the Finder is having a bad day, though, and it simply reports the enlightening "-8003" error when you try to empty the Trash (or something equally obtuse). This error isn't defined or documented anywhere, but through trial and error, we have figured out that it simply means "I can't cope with your request to empty the Trash".

The solution is to avoid using the Finder to delete a CCC SafetyNet folder. Choose Delete a SafetyNet Folder from CCC's Utilities menu instead and use that interface to manually remove SafetyNet folders.

Related Documentation

• Frequently asked questions about the CCC SafetyNet

In addition to backing up to volumes formatted with the macOS standard HFS+ or APFS format (collectively referred to as "macOS-formatted" from here forward), CCC can copy user data files to network volumes (e.g. AFP and SMB via macOS and Windows File Sharing) and to other non-macOS-formatted volumes such as FAT32 or ExFAT. Non-macOS-formatted volumes are presented in CCC's Source and Destination selectors in the same manner as macOS-formatted volumes, so there are no special steps required for backing up to or from these filesystems. However, these filesystems offer limited support for macOS-filesystem features, so special consideration must be given when backing up to these volumes. In general, you can reasonably expect to back up user data — files that belong to your user account — to and from non-macOS-formatted volumes. Specific considerations are noted below.

You can mount network volumes in the Finder, or via the Mount a network volume... option in CCC's Utilities menu. Please note that network volumes mounted by third-party software is generally not supportable.

CCC will only back up system files to or from locally-attached macOS-formatted filesystems

macOS can only be installed on a macOS-formatted volume. This requirement is also carried to a backup volume. When system files are copied to or from non-macOS filesystems, important metadata are unavoidably lost, resulting in files that cannot be restored to their original functionality. In short, you cannot restore a functional installation of macOS from a backup stored on a non-macOS volume. To prevent any misunderstandings about this result, CCC will exclude system files from a backup task if the destination is not a locally-attached, macOS-formatted volume. Likewise, CCC will not copy system files from a network volume, e.g. if you were to mount the startup disk of another Mac via File Sharing, the system files on that network volume cannot be copied in a meaningful way.

Note that the "locally-attached" caveat is an important distinction. Even if your destination volume is macOS-formatted, if it is attached to an Airport Base Station (for example), then you're accessing the volume via file sharing. If you open the Get Info panel for the volume, you will see that the volume format is "AppleShare" or "SMB", not HFS+ or APFS.

Related Documentation

• Preparing your destination disk for a backup or restore

Ownership and permissions concerns

Network filesystems pose some interesting challenges in regards to preserving ownership and permissions. When you connect to another computer that is hosting a shared volume, you usually authenticate by providing a username and password. The account whose credentials you provide is an account on that other computer, and it is this account's privileges that determine what access you have to files and folders on the shared volume. Additionally, any files that are copied to the shared volume will be owned by that user account, regardless of the ownership of those files on the source volume. This is not a behavior specific to CCC, it is simply the nature of network filesystems.

An example will be very helpful in understanding the implications of this behavior. Suppose Sally would like to back up some Movies from her Mac's home folder to another Mac shared by Bob and Joe. On Sally's Mac, there is a user account named "sally". On Bob and Joe's Mac, File Sharing has been enabled in the Sharing Preference Pane, and there are two user accounts, "joe" and "bob". Bob has attached an external hard drive named "Backup" to his Mac that he and Joe have been using for backup, and he has created a folder named "Sally's Movies" on this volume to which Sally will copy files. Sally does the following to connect to Bob and Joe's Mac:

1. In the Finder, open a new window, then click on "Bob and Joe's Mac" in the Shared section of the sidebar.
2. Click on the Connect as... button.
3. In the authentication dialog, provide Bob's username and password, then click on the Connect button.
4. Choose the "Backup" volume from the list of shared volumes.

The Backup volume now appears on Sally's Desktop, and in CCC's Destination selector in the Network Volumes section. Next, Sally chooses Choose a folder... from CCC's Source selector and locates the folder of movies that she would like to copy to Bob and Joe's Mac. She then chooses Choose a folder... from the Destination selector and locates the "Sally's Movies" folder on the Backup network volume. She clicks the Start button and the Movies are backed up.

Later that day, Joe is using his computer and he notices that he can see some of the movies in the "Sally's Movies" folder, but some of the subfolders have a universal "No access" badge and he cannot view those folders' contents. This occurred for two reasons:

1. Sally mounted the network volume using Bob's credentials, so the files and folders created when she copied her files to the Backup volume are now owned by Bob's user account.
2. Some of the folders on Sally's computer prevented access by "other" users.

As a result, the folders on the Backup volume are owned by Bob and some of them limit access to other users (Joe in this case). Joe asks Sally about this and she decides to try copying some of the movies to one of Joe's folders on the backup volume. When she chooses Choose a folder... from CCC's Destination menu, however, she sees the same universal "No Access" badge on Joe's folder. Sally can't copy files to this folder (nor can CCC) because the Backup volume was mounted using Bob's credentials, and Joe's backup folder on the backup volume happened to be inaccessible to Bob. Sally unmounts the backup volume and reconnects to it using Joe's credentials, and she is then able to copy files to Joe's private folder.

What can I do when there are permissions or ownership issues that prevent CCC from copying items to/from or updating items on a network volume?

First, it is important to keep in mind that no application can modify the ownership of a file or folder on a network share. Ownership changes must be applied on the computer or device that is hosting the network volume. Additionally, permissions changes can only be made to files and folders owned by the user whose credentials were used to mount the network volume. For this reason, it is generally easier to apply both ownership and permissions changes on the computer or device hosting the network volume.

If the computer hosting the network volume is a Mac, you can modify ownership and permissions in the Get Info panel for that folder (on the Mac hosting the network volume):

1. In the Finder, click on the folder whose permissions or ownership you would like to change.
2. Choose Get Info from the File menu.
3. In the Sharing & Permissions section at the bottom, click on the lock icon to make the permissions editable.
4. To change permissions, choose Read & Write from the popup menu next to the owner of the file or folder.
5. If the owner of the item is not the user account that you use to connect to this Macintosh, click on the + button
6. In the window that appears, select the user account that you use to connect to this Macintosh, then click the Select button.
7. Set the access privileges to Read & Write.
8. Click on the "additional actions" menu and choose to apply the change to enclosed items.
9. Try your backup task again.

If the computer or device that is hosting the network volume is not a Macintosh, consult that device's documentation to learn how to change permissions and ownership of files and folders.

Alternative #1: If you have mounted the network volume with Guest privileges, unmount and remount the network volume using the credentials of an account on the machine or device hosting the network volume.

Alternative #2: You can create a new folder on the shared volume and specify that folder as the destination in CCC by choosing Choose a folder... from the Destination selector.

Alternative #3: You can have CCC create a disk image on the network volume rather than copying files directly to a folder. When CCC creates a disk image on the destination, the disk image is formatted to match the source and attached locally, so CCC can preserve the permissions and ownership of the files that you are copying to it.

Limitations of non-macOS-formatted filesystems

When you choose a non-macOS-formatted volume as a destination, CCC's Cloning Coach will proactively warn you of any compatibility issues between the source and destination volumes. You can view the Copy Coach's warnings by clicking on the yellow caution button in the Task Plan box. If you have selected a source and destination volume, and the caution button is not present, then there are no configuration concerns.

Support for third-party filesystems

CCC offers limited support for third-party filesystems, such as those provided by FUSE for OS X. Due to the large number of filesystems that can be provided by FUSE, CCC provides generic support for these "userland" filesystems rather than specific support. CCC takes a best effort approach by determining the capabilities of the source and destination filesystems, warns of potential incompatibilities, then presents only unexpected error conditions that arise during a backup.

Backing up to FUSE volumes mounted without the allow_root flag is not currently supported (e.g. Google Drive, BitCasa). Please contact the vendor of your proprietary filesystem to ask that they offer the ability to mount the volume with the allow_root flag if you would like to use that volume as a source or destination to a CCC backup task.

Support for Google Drive is "best effort". We've seen odd behavior when selecting 'Google Drive for desktop' volumes as a whole as the source or destination for a task – CCC is unable to read the root folder during a backup task. CCC explicitly disallows that configuration. Selecting a subfolder on the Google Drive volume often works, and CCC will not disallow that configuration, however we frequently receive reports of inconsistent results when backing up to Google Drive, so we cannot offer support for this configuration.

There is one other notable concern with 'Google Drive for desktop'– Google Drive will download files when they are accessed if they do not currently reside on your Mac's hard drive. If you specify a Google Drive folder as the source to a backup task, you should anticipate that cloud-only files may be downloaded to your Mac during the backup task. That behavior lies outside of CCC's purview, it cannot be modified with a CCC task setting.

The Western Digital MyCloud Home NAS device is another special case. The "Home" model of this NAS device requires the use of WD-proprietary software to access the storage securely; direct access to the storage via SMB is only available with Guest privileges. Users report that performance of the storage while using WD's software is subpar in comparison to Guest access via SMB, and other users have reported to us that macOS is unable to create or mount disk images on the storage when mounted via Western Digital's software. When you mount WD MyCloud Home NAS storage using WD's software, the volume is vended by a 'kddfuse' filesystem. CCC won't allow these volumes as a source or destination device. To back up to a WD MyCloud Home NAS, mount the storage via SMB in the Finder instead. Be sure to choose the "Guest" user option when prompted to authenticate, because the MyCloud Home device doesn't support authenticated access via SMB.

Writable NTFS filesystems

We have seen several reports of problems copying large amounts of data (e.g. > 4GB) to writable NTFS filesystems. In most cases, the underlying software that vends the filesystem (e.g. Tuxera, Paragon, and others) crashes and the volume is rendered "mute". While it may be possible to complete a backup to these filesystems in chunks (e.g. 4GB at a time), we recommend using a more reliable, writable filesystem if you encounter these problems.

Related Documentation

• Learn more about formatting volumes on macOS

Backing up a Boot Camp installation of Windows

CCC can back up the user data on a Boot Camp volume, but it cannot make an installation of Windows bootable. If your goal is to back up your user data on the Boot Camp volume, CCC will meet your needs. If you're looking to migrate your Boot Camp volume to a new hard drive, you might consider an alternative solution such as WinClone, or one of the commercial virtualization solutions that offer a migration strategy from Boot Camp.

Backing up the contents of an NTFS volume

The NTFS filesystem supports "named streams", a feature that is comparable to extended attributes on macOS-formatted volumes and many other filesystems. Unlike extended attributes, however, there is no limit to the amount of data that can be stuffed into NTFS named streams (aside from standard file size limitations). Extended attributes on macOS have a 128KB size limit. As a result, any attempts to copy a named stream larger than 128KB to a non-NTFS filesystem will fail. CCC will copy the standard file data just fine, but will not copy named streams larger than 128KB. CCC's Copy Coach will warn of this kind of incompatibility, and any errors related to this limitation will be logged to the CCC log file, however these errors will not be raised to your attention.

This limitation applies when copying files between volumes on Windows as well, so application developers tend to use named streams only for data that can be regenerated (e.g. thumbnail icons, summary or statistical information), not for storage of irreplaceable user data.

NAS service failures can lead to unreliable backups

Access to the contents of a network volume is provided by an application that runs on another computer or Network Attached Storage (NAS) device. Every NAS device and operating system has its own vendor-specific version of the file sharing application, so we occasionally see problems with some NAS devices that don't occur on others. Problems can be minor, such as being unable to set file flags (e.g. hidden, locked) on an item, or more significant, like not being able to store or retrieve resource forks. When these problems are encountered during a backup task, CCC will copy as many files and as much data as possible, then offer a report on the items or attributes that could not be copied.

When you encounter an error caused by the file sharing service that hosts your network volume, there are a few workarounds that you can try to avoid the errors:

• Eject the network volume on your Mac, then restart the computer or NAS device that is hosting the network volume. Reconnect to the network volume and try the backup task again.
• Connect to the network volume using a different protocol. A different application is responsible for each protocol, so if the AFP service on your server has a bug, connecting to the SMB service may work more reliably (and vice versa). Choose Connect to server from the Finder's Go menu, then specify "smb://servername.local/volume" or "afp://servername.local/volume" to connect to the server using a different protocol. If you are unsure which protocol you are currently using, click on the mounted volume in the Finder, then choose Get Info from the Finder's File menu to find out.
• If the errors persist when connecting to the network volume via both AFP and SMB, and restarting the file server does not change the outcome, then we recommend that you back up to locally-attached storage instead.

Some NAS services cope poorly with files and folders with special characters

Some NAS file sharing services will automatically rename files to "DOS compatible" names, or simply issue errors when working with various file names. In particular, files or folders that start or end with a space character, or names that contain a colon (:) or slash (/) character are unacceptable. When the file sharing service encounters files or folders with these disallowed characters, it will either report an "invalid argument" error, or it will automatically rename these items, e.g. " filename.txt" would become "_1CZVG~B". This "mangling" of file and folder names inevitably leads to errors during a backup task. To avoid these errors, you should either rename the offending files on the source, or connect to the NAS device using a different protocol. Choose Connect to server from the Finder's Go menu, then specify "afp://servername.local/volume" to connect to the server using a different protocol.

Possible workaround: If you can modify the configuration of the SMB file sharing service on your NAS, then you may be able to prevent the service from "mangling" these file names. The applicable setting is documented here.

Another common issue that people encounter when copying files to a NAS volume is errors that are the result of a name restriction. For example, Synology NAS devices (and many others) disallow file names that start with .lock, CON, PRN, AUX, NUL, COM0 - COM9, LPT0 - LPT9, _vti_, desktop.ini, any filename starting with ~$. These NAS devices often produce bogus error codes in these cases, e.g. "File name too long". Some NAS devices have specific character restrictions as well, e.g. NAS devices that follow the Microsoft OneDrive naming conventions, which exclude " * : < > ? / \ |, and leading and trailing spaces in file or folder names also aren't allowed.

If you frequently use virtual machine container files (e.g. with Parallels, VMWare, VirtualBox, etc.), you may find that CCC's SafetyNet folder tends to get very large, very quickly, or that snapshots on the destination consume space very quickly. Every time you open your virtual machine, the monolithic virtual machine container file is modified, and CCC will require that it gets backed up during the next backup task. If the SafetyNet is on, CCC will move the older version of the VM container file into the SafetyNet folder (or it will be retained by a snapshot on the destination). If you run your backup tasks on a daily basis and use your virtual memory container file every day, these large VM container files will quickly consume all of the free space on your backup volume.

The best way to avoid bloat on your backup volume is to create a new, dedicated backup volume for the VM container. Here's how to set things up:

1. Open Disk Utility
2. Select your current APFS-formatted destination volume in the sidebar
3. Click the "+" button in the toolbar; name the new volume something like "Parallels Backup"
4. In the Finder, delete the Parallels VM folder from your primary backup volume
5. Open CCC
6. Create a new task and name it something like Everything except Parallels
7. Choose your startup disk from CCC's Source selector
8. Click the Task Filter button at the bottom of the window
9. In the file list in the Task Filter window, navigate to the location where your Parallels VM is saved (e.g. Users > yourname > Documents > Parallels) and uncheck the box next to the folder that contains your virtual machine container. You could exclude the container file itself, but choosing the parent folder gives you more flexibility in renaming the VM container, should you want to (e.g. Windows XP > Windows 7).
10. Choose your backup volume from the Destination selector
11. Configure the task to run Daily and Save the changes
12. Create a new task and name it something like Parallels Backup
13. Choose Choose a folder... from the Source selector and select your Parallels folder as the source (e.g. the same folder that you excluded previously). By selecting this folder directly, you're explicitly limiting this task's scope to this folder.
14. Click on the Destination selector and select the "Parallels Backup" volume as the destination
15. Click on the Destination selector and choose SafetyNet Off from the SafetyNet menu
16. Schedule this task, then save the changes
17. Click on the Destination selector and choose "Manage snapshots on 'Parallels Backup'"
18. Disable snapshot support on the "Parallels Backup" volume

Additionally, you can configure the first task to run that second task as a postflight action in Advanced Settings.

Scheduling Basis

CCC offers seven different bases for automating backup tasks, giving you exceptional control over how and when your backup tasks run.

Do not run this task on a schedule

Select this option when you prefer that the task only run when you click the Start button. Note that you do not have to select this option to prevent a scheduled task from running. If you would like to temporarily disable a task, right-click on the task in CCC's sidebar and choose the option to disable the task. Likewise, you can suspend all tasks via the CCC Dashboard.

Run once at the specified time

This option is convenient when you would like to run a task in the near future, but not automatically thereafter. When the task completes, it will be reset to "Do not run this task on a schedule".

Hourly, Daily, Weekly, Monthly

When you want your task to run at specific times or intervals, these options give you the most precision.

When files are modified

This setting causes the task to monitor filesystem activity on the source. When folders are modified on the source, CCC will periodically enumerate the changes in those specific folders to determine how much data has been modified on the source since the task's last successful run. When the changes exceed your specified threshold (which is defined in GB, but you can specify 0.01, for example, to specify a lower value than 1GB), the task will run, copying just the items that have changed. This setting also offers a time-based threshold to avoid running the task too frequently.

When a task is actively monitoring the source, the Automation box will present a graphic that indicates how much data has been modified as a percentage of your defined threshold. If the data modification threshold has been reached, but the time threshold has not yet been reached, CCC will indicate that the task will run when the time threshold is met. Data changes are updated approximately every 30 seconds.

When a task is currently monitoring source filesystem activity, task settings cannot be modified (including the thresholds that determine when the task will run). If you would like to make changes to the task settings, click the "pause" button in the Automation box to temporarily suspend monitoring. If you would like to remove the filesystem monitor altogether, click the "stop" button in the Automation box.

CCC will suspend source volume monitoring if:

• The task is running and you stop the task (if we don't suspend monitoring, it would simply start running again)
• A task encounters errors while updating the destination
• If the source or destination volume is unmounted

After reviewing any errors and taking any necessary corrective action, you can click the "play" button to resume monitoring. If monitoring was suspended because the source or destination was unmounted, CCC will automatically resume monitoring when the missing volume is remounted as long as no errors occurred during the last task event.

Overriding Quick Update behavior to perform a complete scan of the source: The main action button will be titled "Run Now" when a task is configured to run when files are modified on the source. You can click that button any time to immediately update the destination using the Quick Update behavior. If you would like the task to perform a complete scan of the source, right-click on the Run Now button and choose Standard Copy.

This option requires an APFS or HFS+ source volume: Our testing of this functionality has been focused on Apple-formatted filesystems, so it is currently limited to source volumes formatted as APFS or Mac OS Extended, Journaled. We welcome your feedback on this, and we will consider making this option available for other source volume formats in the future.

This option is not available for "transient" destinations: This features relies on the source and destination being reliably available for monitoring. While CCC will accommodate the mounting and unmounting of local volumes for this scheduling option, this option is not currently available for tasks involving network volumes, nor disk image destinations. We welcome your feedback on this, and we will consider making this option available for those types of volumes in the future.

When the source or destination is remounted

Use this option when you want your task to run when your source or destination volume is remounted. When a task is configured in this manner, volume mount notifications are used to trigger the task. A task will only run when both volumes are present and mounted. Note that CCC will not automatically mount the source, for example, if it is not mounted when the destination reappears. Also note that CCC imposes a deliberate 60-second moratorium on task activity when the system is turned on. This task automation option is not designed to run tasks when volumes are mounted on startup.

By default, CCC will immediately run a task configured in this manner when the source or destination reappears. If you prefer, CCC can prompt you to run the task when a volume reappears, and CCC can also present a reminder if the task hasn't run after a particular amount of time. These prompts are presented by the CCC Dashboard, which offers additional settings for how reminders are presented to you. Click on the Activity tab's Settings icon in CCC Dashboard to configure those settings.

Lastly, you can configure a "throttle" to prevent these tasks from running too frequently. If you detach and reattach your backup disk frequently throughout the day, for example, you can configure the task to run no more frequently than once per day. Note that this interval can be specified as a decimal value. For example, if you would like the task to run no more frequently than twice per day, you can configure the threshold as "0.5".

Runtime Conditions

Sometimes time-based scheduling is insufficient to describe exactly how you want your tasks to run. CCC offers runtime conditions which allow you to restrict the running of your tasks under certain conditions when the task is normally scheduled to run.

Defer if another task is writing to the same destination

If you have more than one scheduled task that writes to the same destination volume, you may want to configure the tasks to wait for one another such that only one task is writing to the volume at a time. When you configure a task with this setting and the scheduled run time elapses, CCC will place the task into a queue for deferred execution if another task is already writing to that same destination. Assuming another run time condition does not prevent it, CCC will run the deferred task as soon as the first task finishes writing to the shared destination volume.

Limit which days of the week this task can run

This option allows you to limit a task to running only during weekdays or only during weekend days. This option is not applicable to the "weekly" and "monthly" scheduling settings.

Limit when this task can run

This option allows you to limit a task to running during specific hours of the day. For example, if you don't want your hourly task to run in the afternoons, you could set a start limit of 6PM and an end limit of 12PM. This limit would allow the task to start any time after 6PM and any time up to 12PM, thus preventing the task from running between 12PM and 6PM. If the task is already running (e.g. if it started at 11:55AM), CCC will stop the task if it is still running when the end limit is reached.

Note: Set the task start time before you attempt to set time limits. CCC will not allow you to specify a time limit that does not contain the current start time of the task.

Handling system sleep events

By default, CCC will wake your computer when your tasks are scheduled to run. You can change this setting in the Runtime Conditions section of the Scheduler popover. There are four options:

Wake the system, but skip tasks when the system is off

CCC will configure a wake event to wake the system shortly before the task runs, so the task should run on schedule. If the system is turned off, this wake event will not turn on the system. When the system is restarted (i.e. after having been turned off for a while), any tasks missed while the system was off will run at the next scheduled run time. This setting wakes the display. If you do not want your display to wake, use the Run when the system next wakes setting instead.

Wake or power on the system

CCC will configure a wake or power on event to wake the system or turn it on shortly before the task runs, so the task should run on schedule. This setting wakes the display. If you do not want your display to wake, use the Run when the system next wakes setting instead.

Run when the system next wakes

Upon a wake notification, CCC will run the backup task if its scheduled run time has passed. The task will not run exactly when it is scheduled, though CCC can run tasks during macOS Dark Wake events (aka PowerNap, aka Maintenance Wake), which occur every couple hours. If you want your backup tasks to run in the middle of the night without turning on your display, this is the right option for you.

Run when the system next wakes or powers on

Like the setting above, except that tasks missed when the system was off will start immediately when the system is turned on.

Skip this task

CCC will run the task only at its scheduled run time if the system is awake at that time. Upon a wake event, CCC will not run a backup task if the scheduled run time has passed.

Configuring behavior for when the source or destination is missing at the scheduled run time

Don't send error notifications

By default, CCC will report an error if the source or destination volume is unavailable when the task is scheduled to run. By enabling this option, CCC will suppress these errors. Additionally, if you have configured your task to send an email when errors occur, this option will suppress that email.

This option is not applicable for the When the source or destination is reconnected scheduling setting, because a task configured in that manner will only attempt to run if both the source and destination are present.

Run this task as soon as the missing volume reappears

If a backup task is missed because the source or destination was missing at the scheduled run time, this option will cause CCC to run the backup task as soon as that missing volume reappears.

Related Documentation

• Frequently asked questions about scheduled tasks

If you would like CCC to send your tasks' results via email, you must first configure a sending email account in CCC's Email Settings.

1. Click Preferences in the CCC toolbar.
2. Click the Email Settings button in the toolbar of the Preferences window.
3. Choose from one of the accounts imported from Mail in the Sent From Email popup menu, then verify the details and provide your account credentials in the form that is provided.
4. Click the OK button when you are finished entering your account details.

Note for advanced users: If your SMTP server requires SSL and uses a self-signed security certificate, check the Don't validate the certificate chain checkbox. Alternatively, you can add your server's security certificate to the System keychain in the Keychain Access application and explicitly trust that certificate.

[Optional] Modify the email subject and body template

The subject and body of the email that CCC sends upon task completion can be customized. For example, if you want to know which of your Mac's a particular email is coming from, you could customize the subject of the message:

    Jon's iMac: ##Task Name##: ##Exit Status##

When CCC sends an email notification, it will replace the template values (enclosed in double # characters) with the attributes of your task, e.g.:

    Jon's iMac: Daily Backup: Backup Finished Successfully

Most of the available template values are already present in the default template. You can rearrange the template values and modify the text around them, but do not modify the text inside of the double # characters. If you would like to add a template value:

1. Place the cursor where you would like to place the template value, e.g. in the subject or body text field.
2. Select a template value from the Template values popup menu.
3. Click the Insert button.

When you are finished making changes to your subject and body templates, click on the Save Changes button. This template will be used for all email notifications sent by CCC.

If you have suggestions for additional template values, please let us know!

Send a test email

Click on the Send Test Email... button at the bottom of the window. You will be prompted to provide an email address to send the test email to. When CCC indicates that the test email has been sent, check your email to confirm that you can receive it and that the template provides the information you wish to receive when your tasks complete.

Select a notification level

Close the Preferences window, then select the task to which you would like to add email notifications. Click the Advanced Settings button at the bottom of the window, then select the Postflight tab to reveal the email notification option. There are three notification levels:

• Don't send email: CCC will never send an email when this tasks finishes.
• Send after every run: CCC will send an email at the end of every task (i.e. successful tasks and those that report errors).
• Only send on errors: CCC will send an email only when errors occur for this task.

Select a notification level, then specify the email address(es) that you would like CCC to notify when the task completes. If you would like to have emails sent to multiple addresses, separate those addresses with a comma, or simply press the return key after typing in each address. The recipient text field may only show one address at a time. Use the arrow keys to see each address.

Once you have configured a notification level and recipients, choose Save from CCC's Task menu to save the changes.

Sending email with an SMTP service that requires an App Password

Because CCC sends emails from a background application, possibly when no user is logged in at all, CCC cannot practically support two-factor authentication. Many applications have this same logistical constraint, and most email providers will allow those applications to use the SMTP service, provided that you have created an application-specific password for that purpose. If you attempted to send an email with your Gmail or iCloud account (for example), and you get an error that "the username and password are invalid", or that "authentication failed", you can resolve the problem by creating an App Password.

Solution: Create an App Password for iCloud

Visit your Apple ID account page and create an application-specific password for CCC:

1. Sign in to your Apple ID account page.
2. In the Security section, click the Generate Password... link under the APP-SPECIFIC PASSWORDS heading and follow the steps provided.
3. Paste the application-specific password into the Email Settings panel of CCC's Preferences window.
4. Note: Be sure to use an @mac.com, @me.com, or @icloud.com email address for the user name.

Apple's reference: Using app-specific passwords

Solution: Create an App Password for Yahoo

Visit your Account Security page to generate an application-specific password for CCC:

1. Visit your Account Security page.
2. Click on the Generate app password link at the bottom of the page.
3. Click Select yourapp and choose Other App. Type in CCC as the custom name.
4. Click the Generate button.
5. Copy and paste the application-specific password into the Email Settings panel of CCC's Preferences window. Note: We recommend that you copy and paste the code. If you choose to transcribe it, take care not to insert spaces. The code is presented in four groups, but it does not actually contain spaces; it should be exactly 16 characters.

Solution: Create an App Password for Gmail

Visit your App Passwords page to generate an application-specific password for CCC:

1. Visit your App passwords page.
2. Click Select app and choose Other (custom name). Type in CCC.
3. Click the Generate button.
4. Paste the application-specific password into the Email Settings panel of CCC's Preferences window. Note: We recommend that you copy and paste the code. If you choose to transcribe it, take care not to insert spaces. The code is presented in four groups, but it does not actually contain spaces; it should be exactly 16 characters.
5. Note: Be sure to use an @gmail.com email address for the user name. G Suite accounts are not supported.

Google's reference: Sign in using App Passwords

"Your Gmail account will not permit CCC to send email notifications"

Google is very insistent that developers of third-party applications attain a Google Developer Account and subscribe to Google's proprietary APIs so they can use a special form of authentication with Gmail accounts (OAuth2). Developers that choose to use industry-standard authentication mechanisms instead are unjustly deemed as "less secure", and by default, Google will deny authentication requests from these applications. To add insult to injury, when an application attempts to authenticate to Gmail using the industry-standard authentication methods, Google sends you an email that suggests that the requesting application "doesn't meet modern security standards".

CCC absolutely uses modern security standards — TLS, in particular, to secure all traffic to the SMTP server. TLS has and continues to be the modern security standard for securing email communications. If you get a message that your Gmail account won't permit CCC to send email, we have two suggestions:

• Enable two-step verification on your Google account and then create an application password for CCC [this is our primary recommendation]

— Or —

• Change the settings in your Gmail account that Google disabled

Alternatively, you could just specify a non-Google email account in the Email Settings section of CCC's Preferences window.

Update your SMTP credentials after migrating to new Mac

When you provide your SMTP credentials to CCC, CCC stores them securely in a macOS Keychain file. That keychain file is secured in several ways; it is readable only by the macOS system administrator account, it can only be unlocked by CCC, and it can only be unlocked on the Mac upon which it was originally created. As a result, if you purchase a new Mac and migrate your data to the new Mac, CCC's keychain will not work on the new system and CCC will be unable to send email notifications.

After migrating to a new system, open CCC's Email Settings, click the Edit... button, then re-enter your SMTP account credentials.

CCC maintains a list of certain files and folders that are automatically excluded from a backup task. The contents of this list were determined based on Apple recommendations and years of experience. The following is a list of the items that are excluded along with an explanation of why they are excluded.

Legend:
Items prefixed with a "/" indicate that they will only be ignored if located at the root of the volume.
Items postfixed with a "/*" indicate that only the contents of those folders are ignored, the folders themselves will be copied.
Items postfixed with a "*" indicate that the filename will be matched up to the asterisk.

Filesystem implementation details

• .HFS+ Private Directory Data*
• /.journal
• /.journal_info_block
• .afpDeleted*
• ._*
• .AppleDouble
• .AppleDB
• /lost+found
• Network Trash Folder
• .TemporaryItems

These items only show up if you're running an older OS than what was used to format the source volume, and on some third-party implementations of AFP and SMB network filesystems. These items should never, ever be manipulated by third-party programs.

Volume-specific preferences

• .metadata_never_index
• .metadata_never_index_unless_rootfs
• /.com.apple.timemachine.donotpresent
• .VolumeIcon.icns
• /System/Library/CoreServices/.disk_label*
• /TheVolumeSettingsFolder
• /private/var/db/dslocal/nodes/Default/secureaccesstoken.plist

These items record volume-specific preferences, e.g. for Spotlight, Time Machine, and a custom icon for the volume. Feedback on the exclusion of these items is welcome. Because they are volume-specific preferences, the exclusion of these items from a day-to-day backup seems most appropriate.

Apple-proprietary data stores

• .DocumentRevisions-V100*
• .Spotlight-V100
• Library/Metadata/CoreSpotlight
• /.fseventsd
• /.hotfiles.btree
• /private/var/db/systemstats
• /private/var/folders/*/*/C
• /private/var/folders/*/*/T
• /Users/*/Library/Caches
• /Users/*/Library/Containers/*/Data/Library/Caches

These items are Apple-proprietary data stores that get regenerated when absent. Attempting to copy these data stores without unmounting the source and destination is not only futile, it will likely corrupt them (and their respective apps will reject them and recreate them).

The DocumentRevisions data store is used by the Versions feature in macOS. The Versions database stored in this folder contains references to the inode of each file that is under version control. File inodes are volume-specific, so this dataset will have no relevance on a backup volume.

Volume-specific cache files

• /private/var/db/dyld/dyld_*
• /System/Library/Caches/com.apple.bootstamps/*
• /System/Library/Caches/com.apple.corestorage/*

Copying these caches to a new volume will render that volume unbootable. The caches must be regenerated on the new volume as the on-disk location of system files and applications will have changed. macOS automatically regenerates the contents of these folders when CCC is finished updating the backup volume.

NetBoot local data store

• /.com.apple.NetBootX

In the unlikely event that your Macintosh is booted from a Network device, macOS will store local modifications to the filesystem in this folder. These local modifications are not stored in a restorable format, therefore should not be backed up. In general, you should not attempt to back up a NetBooted Mac.

Dynamically-generated devices

• /Volumes/*
• /dev/*
• /automount
• /Network
• /.vol/*
• /net

These items represent special types of folders on macOS. These should not be backed up, they are dynamically created every time you start the machine.

Quota real-time data files

• /.quota.user
• /.quota.group

When these files are copied to a destination volume using an atomic file copying procedure, the macOS kernel will prevent the destination from being gracefully unmounted. The contents of these files is never accurate for the destination volume, so given the kernel's unruly behavior with copies of these files, CCC excludes them. According to the quotacheck man page, these files should be regenerated every time a quota-enabled volume is mounted (e.g. on startup). We have not found that to be consistently true. If you're using quotas, run sudo quotacheck / after restarting from your backup volume or a restored replacement disk to regenerate these files.

Large datastores that are (or should be) erased on startup

• /private/var/vm/*
• /private/tmp/*
• /cores
• /macOS Install Data

macOS stores virtual memory files and your hibernation image (i.e. the contents of RAM are written to disk prior to sleeping) and temporary items in these folders. Depending on how you use macOS and your hardware configuration, this could be more than 50GB of data, and all of it changes from one hour to the next. Having this data for a full-disk restore does you absolutely no good — it makes the backup and restore processes take longer and the files get deleted the next time you boot macOS.

Trash

• .Trash
• .Trashes

Moving an item to the trash is typically considered to be an indication that you are no longer interested in retaining that item. If you don't want CCC to exclude the contents of the Trash, you can modify each task's filter:

1. Choose Copy Some Files from the popup menu underneath the Source selector
2. Click the Inspector button adjacent to that same popup menu to reveal the Task Filter window
3. Uncheck the box next to Don't copy the Finder's Trash
4. Click the Done button

Time Machine backups

These folders store Time Machine backups. Time Machine uses proprietary filesystem devices that Apple explicitly discourages third-party developers from using. Additionally, Apple does not support using a duplicated Time Machine volume and recommends instead that you start a new Time Machine backup on the new disk.

• /Backups.backupdb
• /.MobileBackups
• /.MobileBackups.trash
• /private/var/db/com.apple.backupd.backupVerification

Corrupted iCloud Local Storage

iCloud leverages folders in your home directory for local, offline storage. When corruption occurs within these local data stores, macOS moves/renames the corrupted items into the folders indicated below. macOS doesn't report these corrupted items to you, nor does it attempt to remove them. CCC can't copy the corrupted items, because they're corrupted. To avoid the errors that would occur when trying to copy these corrupted items, CCC excludes the following items from every backup task:

• Library/Mobile Documents.* [Note: This exclusion is specific to Mobile Documents.{something} folders that have a corruption suffix, not to the non-corrupted "Mobile Documents" folder]
• .webtmp

Special files

Files included in this section are application-specific files that have demonstrated unique behavior. The kacta and kactd files, for example, are created by antivirus software and placed into a special type of sandbox that makes them unreadable by any application other than the antivirus software.

The "com.apple.loginwindow" item can be found in each user home folder. Excluding this item prevents the applications that were open during the backup task from opening when you boot from a restored backup. This seems appropriate considering that Apple intends the feature to be used to open the applications that were in use when you log out, restart or shutdown, not at an arbitrary point during the backup task.

• /private/tmp/kacta.txt
• /private/tmp/kactd.txt
• /private/var/audit/*.crash_recovery
• /private/var/audit/current
• /Library/Caches/CrashPlan
• /PGPWDE01
• /PGPWDE02
• /.bzvol
• /Library/Backblaze.bzpkg/bzdata/bzvol_system_volume/bzvol_id.xml
• /.cleverfiles
• /Library/Application Support/Comodo/AntiVirus/Quarantine
• /private/var/spool/qmaster
• $Recycle.Bin
• Library/Preferences/ByHost/com.apple.loginwindow*
• .dropbox.cache
• /private/var/db/atpstatdb*
• .@__thumb
• /.com.prosofteng.DrivePulse.ignore
• com.apple.photolibraryd/tmpoutboundsharing

CCC SafetyNet folders

When CCC's SafetyNet feature is enabled, CCC creates a _CCC SafetyNet folder at the root of the selected destination volume or folder. When CCC encounters an item on the destination that does not exist on the source, or an item that will be replaced with an updated item from the source, that item gets placed into the SafetyNet folder rather than being deleted immediately. The SafetyNet folder is literally a safety net for files on your destination. If you accidentally delete a file from the source and you don't realize it until after your backup task runs, you'll find the item in the SafetyNet folder. Likewise, if you accidentally specify the wrong volume as a destination to a CCC backup task, the mistake does not catastrophically delete every file from the selected destination; you simply recover the items from the _CCC SafetyNet folder.

The protection that the SafetyNet folder imparts is specific to the volume upon which the SafetyNet folder resides. As such, CCC never includes the contents of the _CCC SafetyNet folder in a backup task. So, for example, if your hard drive fails and you restore your backup to a replacement disk, the _CCC SafetyNet folder is automatically excluded from that restore task. If you have several tasks backing up to separate folders on a backup volume, for example, the _CCC SafetyNet folders that are created in those subfolders would not be included in a secondary backup task that copies your backup disk to a third disk.

A disk image is a single file that contains the entire contents of another hard drive (except for the free space). When you want to access the contents of that filesystem, you double-click on the disk image to mount the disk image as if it were an external drive attached to the machine. We recommend using disk images sparingly. If you're backing up to a network volume and your Mac and the NAS device are connected to the network via ethernet, then a disk image may be a good fit. In most cases, however, disk images are not a great choice for your backup strategy.

To back up to a new disk image:

1. Choose your source volume from the Source selector
2. Choose New disk image... from the Destination selector
3. Provide a name and choose a location to save your disk image
4. If you plan to back up to this disk image again in the future, set the image format to one of the read/write formats. If you want a read-only disk image for archival purposes, set the image format to one of the read-only formats.

To back up to an existing disk image, select Choose disk image... from the Destination selector and locate your disk image, or simply drag and drop the disk image file onto CCC's Destination selector box.

Read/write "sparseimage" disk images

Use of this older disk image format is not recommended, we only make it available as a potential workaround for some SMB NAS devices

A sparseimage disk image is a type of read/write disk image that grows as you copy files to it. In general, sparse disk images only consume as much space as the files they contain consume on disk, making this an ideal format for storing backups. Please note that sparseimage files are monolithic and potentially very large files. If the underlying filesystem has a 2TB file size limit and the sparseimage file reaches that limit, the sparseimage file cannot be grown. In most of these cases the sparseimage file becomes corrupted when the underlying filesystem limit is reached, so we don't recommend this disk image format for large data sets.

Read/write "sparsebundle" disk images

A sparse bundle disk image is similar to a sparseimage insofar as it grows as you add data to it, but it retains its data in many smaller files inside of a bundle rather than inside a single file. We recommend this disk image format for most scenarios.

Running out of space on a sparse disk image

CCC reported that the destination is full, but the underlying disk has plenty of free space. CCC initially sets the capacity of your disk image to the amount of free space on the underlying disk. If you have freed up some space on that disk since you created the disk image, you can manually expand the capacity of the destination disk image in Disk Utility. Choose Resize... from the Images menu in Disk Utility, select your destination disk image, then expand it as desired. We recommend that you do not expand the disk image such that it is larger than the capacity of the underlying disk.

The disk image file is larger than the amount of data it contains, why? Sparseimage and sparsebundle disk images grow as you add data to them. They do not, however, automatically shrink when files are deleted from them. As a result, the amount of disk space that the disk image file consumes will not necessarily reflect the amount of data that they consume. To reclaim disk space that is occupied by the free space on your sparse disk image, CCC will compact the disk image before attempting to mount it if the free space on the underlying volume is less than 25GB, or is less than 15% of the total disk capacity. In most cases, you do not need to compact the disk image yourself, but this functionality is documented here so you'll understand why you might see CCC spending time "Compacting the destination disk image" at the beginning of a backup task.

If you would like to compact a disk image manually, drop the disk image file onto this application†: Compact Sparse disk images. Be sure to unmount the disk image volume if it is already mounted. Also, note that the compacting process can take a while (e.g. an hour for a 100GB disk image on a locally-attached volume). Finally, be sure that your system is running on AC power. The system utility that compacts the disk image will refuse to run while the system (e.g. a laptop) is running on battery power.

† Big Sur (and later) users: Right-click on the application and choose "Open" to get past the GateKeeper restriction. Or if you prefer, you can use the command-line hdiutil utility to compact the disk image (e.g. hdiutil compact "/path/to/disk image.sparsebundle").

CCC applies more aggressive SafetyNet pruning to disk image volumes

When you configure a task to back up to a new disk image, CCC will configure the task's SafetyNet pruning to prune anything older than 1 day. You are welcome to change these settings, but we have found that more aggressive SafetyNet pruning will avoid excessive use of disk space on the underlying device, and will reduce the need to compact the disk image.

Please keep in mind that SafetyNet is not intended to offer access to older versions of your files, it is a safety mechanism that is designed to avoid the loss of data on an errantly-selected destination volume. SafetyNet is generally not applicable to disk image backups because the disk image is typically dedicated to the backup task. However, enabling SafetyNet with even a very aggressive pruning limit does offer a modicum of protection in cases where you've accidentally removed files from the source.

If you're looking for a solution that retains older versions of your files and your source volume is APFS-formatted, consider CCC's snapshot functionality instead. Snapshots are disabled on disk image destinations by default, but you can enable snapshot support either on the disk image volume or on the source volume.

Read-only disk images

Read-only disk images cannot be modified without invalidating the built-in checksum, therefore they are a good container for storing archived material. Compression rates vary on the content of your source, but you can typically expect to reduce the size of your disk image by about half when using compression. There is a subtle behavior that you should take note of when considering this option as a space-saving measure: CCC will first create a read/write disk image, copy the selected items to it, then convert the disk image to read-only compressed. In this case, you will actually need twice the space on your destination as the items to be copied consume on the source.

Encrypting disk images

If any of the data that you are backing up is sensitive, and if your backup device may be in an insecure location, encrypted disk images can improve the security of your backup. CCC offers 128 bit and 256 bit AES encryption to encrypt disk images. To create an encrypted disk image, select one of the encryption levels from the Encryption menu. After you click on the OK button, you will be prompted to specify a passphrase for the new disk image, and CCC will give you an opportunity to save the passphrase in your own keychain. CCC will also store the passphrase in a private keychain so the disk image can be mounted automatically during scheduled backup tasks.

Note: If you create a read-only, encrypted disk image, the intermediate disk image that CCC creates is NOT encrypted. This intermediate disk image file is deleted once the final, read-only, encrypted disk image has been created, but it is not shredded. Take this into consideration when choosing your destination media. If the destination may be placed in an insecure location, use Disk Utility to securely erase free space on the underlying destination volume after you have created your encrypted disk image archive.

Running a backup task whose destination is a disk image on the startup disk

If you specify a disk image that resides on your startup disk as the destination to a scheduled task, CCC will impose some more conservative requirements on this task. To proceed with this configuration, one of the following requirements must be met:

• The amount of free space on the startup disk is at least 1GB larger than the amount of consumed space on the source volume.
• The disk image won't grow, e.g. it is a .dmg file, not a sparseimage or sparsebundle disk image.

These requirements avoid a scenario in which the startup disk runs out of free space, causing instability on macOS. If you cannot accommodate the free space requirement, we recommend that you create a .dmg disk image in Disk Utility (choose File > New... > Blank Disk image, set the image format to read/write disk image). Disk Utility will pre-allocate exactly as much space as you request, and CCC will gladly use this disk image without fear of filling up the startup disk.

Snapshots and Disk Images

When creating a new disk image, CCC will format the disk image to match the source volume. For better performance on APFS-formatted disk images, CCC will disable snapshot support on the destination disk image volume if:

• The backup task was originally configured to create a new disk image
• Snapshots are currently enabled for the destination disk image
• The snapshot retention policy limit for SafetyNet snapshots is set to the default value of 7 days

When CCC disables snapshots on that destination disk image volume, it explicitly sets the SafetyNet limit in the snapshot retention policy to 0. If you subsequently re-enable snapshot support on that volume without changing the SafetyNet limit back to the default, then snapshots should remain enabled (because the three logical conditions are no longer matched).

If you would like to enable snapshot support on your disk image and keep it enabled, be sure to either leave the SafetyNet limit set to 0, or change it to anything other than 7. If you ever change the SafetyNet retention value for that disk image back to 7 (or other reset the values to defaults), CCC will again disable snapshots on the disk image when the task next runs.

A message for new Mac users coming from the Windows world

Backups on a Windows system are very different from those on a Macintosh. If you're coming from a Windows background, the term "imaging" and the concept of making a disk image backup is probably familiar to you. Restoring from disk image backups is made simpler on Windows because the startup environment is built around them. That's not the case for a Macintosh. When you create a disk image backup of your Mac's startup disk, the logistics of restoring that backup are actually fairly complicated. Due to these complications, we don't recommend using a disk image as your primary backup on a Mac. Disk images are useful for storing a backup of your user data on a network volume, but for your Mac's startup disk, we recommend that you back up directly to a disk that is attached to your Mac; not to a disk image.

Related Documentation

• Restoring from a disk image

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.

Use CCC's Quick Update feature

The Quick Update feature can greatly reduce the amount of time it takes to compare items on the source and destination. Rather than evaluating all files and folders in the source data set, CCC will collect a list of folders that have been modified since the last backup task from the macOS FSEvents service. Especially for data sets with a lot of small files in folders that are infrequently modified, this feature can improve performance by many orders of magnitude. Click the Advanced Settings button at the bottom of the CCC window, then you'll find the Quick Update option in the Performance & Analysis tab.

Reduce the number of files considered for backup

If the aforementioned Quick Update feature is not applicable (e.g. because the source volume doesn't support it), and if you have a particularly high number of files on your source volume, you may be able to reorganize your data set and apply some exclusions to improve task performance. 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 configure the Task Filter to do so), 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 enumerating through those files for changes.

Related Documentation

• Excluding files and folders from a backup task
• Folder-to-Folder Backups

Trim unnecessary content from the backup task

macOS is constantly touching log and cache files, and those files can add up to a lot of changes for every backup task. Take a moment to review your task audits to see if there is content that doesn't have to be backed up. A few minutes reviewing the audit can add up to lots of time shaved off your regular backups.

1. Click Task History in the toolbar to open CCC's Task History window
2. Select one of your regularly-recurring task events
3. Click on the Audit tab in the center of the window
4. Sort the list by Size, then browse through the changes
5. If you see something in the audit that you don't feel needs to be backed up, especially cache folders with a particularly high file count or a large amount of data, right-click on the item and choose the option to exclude it from the backup task.

Related Documentation

• Audit: Viewing details about the modifications made by the backup task

Avoid simultaneous writes to the same destination

When two tasks are writing to the same destination at the same time, the two tasks will typically take more than twice as long to complete when running at the same time vs. when they are run sequentially. This is particularly true when writing to network volumes, the resulting CPU load on the NAS server can be more than it can handle. CCC offers two features to avoid running automated tasks simultaneously to the same destination:

• Click on the Automation selector for each task and check the box next to Defer if another task is writing to the same destination
• Rather than scheduling the individual tasks, place the tasks into a task group, then configure the group to run on a schedule. The group will then run the tasks sequentially.

Hard drive performance and interface bandwidth

Your backups will be no faster than your slowest disk. 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 — USB 3.1 is faster than USB 3.0, USB 3.0 is faster than USB 2.0, etc.

Additionally, if your source volume is nearly full and is a rotational disk, we recommend that you replace it with a larger hard drive to avoid the performance implications of filesystem fragmentation.

CCC's file copier is tuned for modern, high performance storage

When we developed our new file copier in CCC v6, one of our design goals was to take full advantage of the performance that is available from modern SSD and NVMe storage devices. The CCC "Core Copy Engine" will process up to four folders at once, and copy up to eight files at a time by default when both the source and destination devices can be positively identified as solid state devices. This multi-threaded approach yields blazing-fast transfers of very large amounts of data between fast devices – typically exceeding CCC v5's legacy file copier performance by 50% or more, and meeting or exceeding Finder copying performance.

This multi-threaded approach can yield a performance disadvantage, however, for slower hardware, e.g. "slim" or "portable" 2.5" rotational HDDs. By default, CCC 6 will process up to two folders at a time, and two files at a time when working with storage that is not identifiable as solid state. Depending on the specific performance characteristics of your storage and the files that have to be copied, you may find better performance with more file copier concurrency, or you may find better performance with yet less file copier concurrency. You can change the file copier concurrency in the Performance & Analysis tab of CCC's Advanced Settings:

In some cases, the CCC v6 file copier offers no performance advantage over the CCC v5 file copier. You can drag the File copier concurrency slider all the way to the left to "Use the legacy file copier" to have a specific task use the previous file copier instead. Note that this setting precludes several of the other features available in CCC v6, e.g. postflight file verification, task auditing, and the Quick Update feature. We recommend that you exhaust the other performance tuning recommendations noted in this article before resorting to using the legacy file copier.

Related Documentation

• Choosing a backup drive: Devices that we recommend

Filesystem performance and hardware type

It's important to choose the right filesystem for the hardware that you have and the data that you're backing up. If you have an older, rotational HDD, it's generally better to format that device using the "Mac OS Extended, Journaled" (HFS+) format if you're making a data-only backup. APFS is the new, modern standard, but its performance on rotational devices is inferior to HFS+. If you're making a backup of a macOS Catalina System volume, APFS is required. If you find the performance of your backups to be too slow, we recommend using an SSD for your backups.

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 backup completes 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, or to one of the other options offered in the popup menu adjacent to that setting.

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

If you're still having trouble identifying a performance problem, we're here to help.

Related Documentation

• Troubleshooting slow performance when copying files to or from a network volume…

Using the Dynamic Performance Chart to understand factors that affect performance

When a task is running, CCC presents a live chart of file evaluation rate (i.e. the number of files compared per second) and data write rate. Hover your mouse over the chart to see the rates at various points on the chart:

File evaluation rate and write rate are often complementary. This dynamic performance chart was designed to show how these two factors relate to each other, and also to show how the characteristics of your source data set interact with the performance characteristics of your source and destination devices. For example, you will find that when CCC is copying very large files, file evaluation rate will be low, but write rate will get very high – close to the maximum bandwidth potential of the destination (if that's slower than the source device's read rate). In contrast, when CCC is processing lots of smaller files, the file evaluation rate will get higher and the write rate will be considerably less than the maximum write rate that is achievable on that device. This is normal – it takes longer to copy a million 1KB files than it would take to copy a single 1GB file, even though you're copying the same amount of data.

The dynamic performance chart will bring NAS protocol performance into sharp focus. While we can typically process thousands of files per second on a locally-attached filesystem, NAS filesystems (e.g. AFP and SMB) can typically process tens or hundreds of files per second. This performance is wholly dependent on the NAS device, its storage, and is also strongly influenced by the overhead of the SMB and AFP protocols. The key to improving performance on a task that involves a NAS device is to reduce the number of filesystem transactions that must occur, and the only way to do that is to reduce the number of files and folders that are compared during the backup task. CCC's Quick Update feature can be instrumental in achieving that goal.

Reducing the impact of a backup task on your Mac's performance and usability

Sometimes backup tasks can have a noticeable impact on system performance. By default, the CPU priority of CCC's file copier will be comparable to that of a foreground application, yielding the fastest possible file copying performance. If you would like to reduce the impact that a particular task has on the system, you can reduce the File copier CPU priority in the Performance & Analysis tab of CCC's Advanced Settings.

Pausing a task

If you would like to immediately cease a task's impact on the system without stopping the task altogether, you can pause the task. Click the Pause button adjacent to the Stop button in CCC's main window to pause the task. The CCC Dashboard also offers a Pause button for quicker access to this functionality. Paused tasks will resume automatically after five minutes, or you can click the Continue button to resume the task. The five minute timeout can be adjusted in the Advanced section of CCC's Preferences window.

In addition to backing up to volumes formatted with the macOS standard HFS+ or APFS format (collectively referred to as "macOS-formatted" from here forward), CCC can copy user data files to network volumes (e.g. AFP and SMB via macOS and Windows File Sharing) and to other non-macOS-formatted volumes such as FAT32 or ExFAT. Non-macOS-formatted volumes are presented in CCC's Source and Destination selectors in the same manner as macOS-formatted volumes, so there are no special steps required for backing up to or from these filesystems. However, these filesystems offer limited support for macOS-filesystem features, so special consideration must be given when backing up to these volumes. In general, you can reasonably expect to back up user data — files that belong to your user account — to and from non-macOS-formatted volumes. Specific considerations are noted below.

You can mount network volumes in the Finder, or via the Mount a network volume... option in CCC's Utilities menu. Please note that network volumes mounted by third-party software is generally not supportable.

CCC will only back up system files to or from locally-attached macOS-formatted filesystems

macOS can only be installed on a macOS-formatted volume. This requirement is also carried to a backup volume. When system files are copied to or from non-macOS filesystems, important metadata are unavoidably lost, resulting in files that cannot be restored to their original functionality. In short, you cannot restore a functional installation of macOS from a backup stored on a non-macOS volume. To prevent any misunderstandings about this result, CCC will exclude system files from a backup task if the destination is not a locally-attached, macOS-formatted volume. Likewise, CCC will not copy system files from a network volume, e.g. if you were to mount the startup disk of another Mac via File Sharing, the system files on that network volume cannot be copied in a meaningful way.

Note that the "locally-attached" caveat is an important distinction. Even if your destination volume is macOS-formatted, if it is attached to an Airport Base Station (for example), then you're accessing the volume via file sharing. If you open the Get Info panel for the volume, you will see that the volume format is "AppleShare" or "SMB", not HFS+ or APFS.

Related Documentation

• Preparing your destination disk for a backup or restore

Ownership and permissions concerns

Network filesystems pose some interesting challenges in regards to preserving ownership and permissions. When you connect to another computer that is hosting a shared volume, you usually authenticate by providing a username and password. The account whose credentials you provide is an account on that other computer, and it is this account's privileges that determine what access you have to files and folders on the shared volume. Additionally, any files that are copied to the shared volume will be owned by that user account, regardless of the ownership of those files on the source volume. This is not a behavior specific to CCC, it is simply the nature of network filesystems.

An example will be very helpful in understanding the implications of this behavior. Suppose Sally would like to back up some Movies from her Mac's home folder to another Mac shared by Bob and Joe. On Sally's Mac, there is a user account named "sally". On Bob and Joe's Mac, File Sharing has been enabled in the Sharing Preference Pane, and there are two user accounts, "joe" and "bob". Bob has attached an external hard drive named "Backup" to his Mac that he and Joe have been using for backup, and he has created a folder named "Sally's Movies" on this volume to which Sally will copy files. Sally does the following to connect to Bob and Joe's Mac:

1. In the Finder, open a new window, then click on "Bob and Joe's Mac" in the Shared section of the sidebar.
2. Click on the Connect as... button.
3. In the authentication dialog, provide Bob's username and password, then click on the Connect button.
4. Choose the "Backup" volume from the list of shared volumes.

The Backup volume now appears on Sally's Desktop, and in CCC's Destination selector in the Network Volumes section. Next, Sally chooses Choose a folder... from CCC's Source selector and locates the folder of movies that she would like to copy to Bob and Joe's Mac. She then chooses Choose a folder... from the Destination selector and locates the "Sally's Movies" folder on the Backup network volume. She clicks the Start button and the Movies are backed up.

Later that day, Joe is using his computer and he notices that he can see some of the movies in the "Sally's Movies" folder, but some of the subfolders have a universal "No access" badge and he cannot view those folders' contents. This occurred for two reasons:

1. Sally mounted the network volume using Bob's credentials, so the files and folders created when she copied her files to the Backup volume are now owned by Bob's user account.
2. Some of the folders on Sally's computer prevented access by "other" users.

As a result, the folders on the Backup volume are owned by Bob and some of them limit access to other users (Joe in this case). Joe asks Sally about this and she decides to try copying some of the movies to one of Joe's folders on the backup volume. When she chooses Choose a folder... from CCC's Destination menu, however, she sees the same universal "No Access" badge on Joe's folder. Sally can't copy files to this folder (nor can CCC) because the Backup volume was mounted using Bob's credentials, and Joe's backup folder on the backup volume happened to be inaccessible to Bob. Sally unmounts the backup volume and reconnects to it using Joe's credentials, and she is then able to copy files to Joe's private folder.

What can I do when there are permissions or ownership issues that prevent CCC from copying items to/from or updating items on a network volume?

First, it is important to keep in mind that no application can modify the ownership of a file or folder on a network share. Ownership changes must be applied on the computer or device that is hosting the network volume. Additionally, permissions changes can only be made to files and folders owned by the user whose credentials were used to mount the network volume. For this reason, it is generally easier to apply both ownership and permissions changes on the computer or device hosting the network volume.

If the computer hosting the network volume is a Mac, you can modify ownership and permissions in the Get Info panel for that folder (on the Mac hosting the network volume):

1. In the Finder, click on the folder whose permissions or ownership you would like to change.
2. Choose Get Info from the File menu.
3. In the Sharing & Permissions section at the bottom, click on the lock icon to make the permissions editable.
4. To change permissions, choose Read & Write from the popup menu next to the owner of the file or folder.
5. If the owner of the item is not the user account that you use to connect to this Macintosh, click on the + button
6. In the window that appears, select the user account that you use to connect to this Macintosh, then click the Select button.
7. Set the access privileges to Read & Write.
8. Click on the "additional actions" menu and choose to apply the change to enclosed items.
9. Try your backup task again.

If the computer or device that is hosting the network volume is not a Macintosh, consult that device's documentation to learn how to change permissions and ownership of files and folders.

Alternative #1: If you have mounted the network volume with Guest privileges, unmount and remount the network volume using the credentials of an account on the machine or device hosting the network volume.

Alternative #2: You can create a new folder on the shared volume and specify that folder as the destination in CCC by choosing Choose a folder... from the Destination selector.

Alternative #3: You can have CCC create a disk image on the network volume rather than copying files directly to a folder. When CCC creates a disk image on the destination, the disk image is formatted to match the source and attached locally, so CCC can preserve the permissions and ownership of the files that you are copying to it.

Why can't I change the username when CCC prompts for NAS volume credentials?

When you select a NAS volume as the source or destination to a CCC task, CCC will prompt for the credentials that were used to mount that volume. CCC already knows the user name for that volume, that value is published in the "filesystem URL" attribute of the mounted NAS volume (you can type mount into the Terminal application to see that value). CCC asks for the password so that CCC can remount the NAS volume automatically later. In order to avoid ownership or permissions issues, CCC will remount the NAS volume using the exact same user account that was used to mount the NAS volume in the Finder – this is why the username field cannot be modified.

If you would like to use a different user account to mount the NAS volume, then you should eject the NAS volume in the Finder and remount it using the preferred user account. Once the volume is remounted, reselect the NAS volume (or a folder on that NAS volume) as the source or destination to your task. If CCC does not have the credentials for the user account that was used to mount the NAS volume, CCC will again prompt for those credentials.

Limitations of non-macOS-formatted filesystems

When you choose a non-macOS-formatted volume as a destination, CCC's Cloning Coach will proactively warn you of any compatibility issues between the source and destination volumes. You can view the Copy Coach's warnings by clicking on the yellow caution button in the Task Plan box. If you have selected a source and destination volume, and the caution button is not present, then there are no configuration concerns.

Support for third-party filesystems

CCC offers limited support for third-party filesystems, such as those provided by FUSE for OS X. Due to the large number of filesystems that can be provided by FUSE, CCC provides generic support for these "userland" filesystems rather than specific support. CCC takes a best effort approach by determining the capabilities of the source and destination filesystems, warns of potential incompatibilities, then presents only unexpected error conditions that arise during a backup.

Backing up to FUSE volumes mounted without the allow_root flag is not currently supported (e.g. Google Drive, BitCasa). Please contact the vendor of your proprietary filesystem to ask that they offer the ability to mount the volume with the allow_root flag if you would like to use that volume as a source or destination to a CCC backup task.

Support for Google Drive is "best effort". We've seen odd behavior when selecting 'Google Drive for desktop' volumes as a whole as the source or destination for a task – CCC is unable to read the root folder during a backup task. CCC explicitly disallows that configuration. Selecting a subfolder on the Google Drive volume often works, and CCC will not disallow that configuration, however we frequently receive reports of inconsistent results when backing up to Google Drive, so we cannot offer support for this configuration.

There is one other notable concern with 'Google Drive for desktop'– Google Drive will download files when they are accessed if they do not currently reside on your Mac's hard drive. If you specify a Google Drive folder as the source to a backup task, you should anticipate that cloud-only files may be downloaded to your Mac during the backup task. That behavior lies outside of CCC's purview, it cannot be modified with a CCC task setting.

The Western Digital MyCloud Home NAS device is another special case. The "Home" model of this NAS device requires the use of WD-proprietary software to access the storage securely; direct access to the storage via SMB is only available with Guest privileges. Users report that performance of the storage while using WD's software is subpar in comparison to Guest access via SMB, and other users have reported to us that macOS is unable to create or mount disk images on the storage when mounted via Western Digital's software. When you mount WD MyCloud Home NAS storage using WD's software, the volume is vended by a 'kddfuse' filesystem. CCC won't allow these volumes as a source or destination device. To back up to a WD MyCloud Home NAS, mount the storage via SMB in the Finder instead. Be sure to choose the "Guest" user option when prompted to authenticate, because the MyCloud Home device doesn't support authenticated access via SMB.

Writable NTFS filesystems

We have seen several reports of problems copying large amounts of data (e.g. > 4GB) to writable NTFS filesystems. In most cases, the underlying software that vends the filesystem (e.g. Tuxera, Paragon, and others) crashes and the volume is rendered "mute". While it may be possible to complete a backup to these filesystems in chunks (e.g. 4GB at a time), we recommend using a more reliable, writable filesystem if you encounter these problems.

Related Documentation

• Learn more about formatting volumes on macOS

Backing up a Boot Camp installation of Windows

CCC can back up the user data on a Boot Camp volume, but it cannot make an installation of Windows bootable. If your goal is to back up your user data on the Boot Camp volume, CCC will meet your needs. If you're looking to migrate your Boot Camp volume to a new hard drive, you might consider an alternative solution such as WinClone, or one of the commercial virtualization solutions that offer a migration strategy from Boot Camp.

Backing up the contents of an NTFS volume

The NTFS filesystem supports "named streams", a feature that is comparable to extended attributes on macOS-formatted volumes and many other filesystems. Unlike extended attributes, however, there is no limit to the amount of data that can be stuffed into NTFS named streams (aside from standard file size limitations). Extended attributes on macOS have a 128KB size limit. As a result, any attempts to copy a named stream larger than 128KB to a non-NTFS filesystem will fail. CCC will copy the standard file data just fine, but will not copy named streams larger than 128KB. CCC's Copy Coach will warn of this kind of incompatibility, and any errors related to this limitation will be logged to the CCC log file, however these errors will not be raised to your attention.

This limitation applies when copying files between volumes on Windows as well, so application developers tend to use named streams only for data that can be regenerated (e.g. thumbnail icons, summary or statistical information), not for storage of irreplaceable user data.

NAS service failures can lead to unreliable backups

Access to the contents of a network volume is provided by an application that runs on another computer or Network Attached Storage (NAS) device. Every NAS device and operating system has its own vendor-specific version of the file sharing application, so we occasionally see problems with some NAS devices that don't occur on others. Problems can be minor, such as being unable to set file flags (e.g. hidden, locked) on an item, or more significant, like not being able to store or retrieve resource forks. When these problems are encountered during a backup task, CCC will copy as many files and as much data as possible, then offer a report on the items or attributes that could not be copied.

When you encounter an error caused by the file sharing service that hosts your network volume, there are a few workarounds that you can try to avoid the errors:

• Eject the network volume on your Mac, then restart the computer or NAS device that is hosting the network volume. Reconnect to the network volume and try the backup task again.
• Connect to the network volume using a different protocol. A different application is responsible for each protocol, so if the AFP service on your server has a bug, connecting to the SMB service may work more reliably (and vice versa). Choose Connect to server from the Finder's Go menu, then specify "smb://servername.local/volume" or "afp://servername.local/volume" to connect to the server using a different protocol. If you are unsure which protocol you are currently using, click on the mounted volume in the Finder, then choose Get Info from the Finder's File menu to find out.
• If the errors persist when connecting to the network volume via both AFP and SMB, and restarting the file server does not change the outcome, then we recommend that you back up to locally-attached storage instead.

Some NAS services cope poorly with files and folders with special characters

Some NAS file sharing services will automatically rename files to "DOS compatible" names, or simply issue errors when working with various file names. In particular, files or folders that start or end with a space character, or names that contain a colon (:) or slash (/) character are unacceptable. When the file sharing service encounters files or folders with these disallowed characters, it will either report an "invalid argument" error, or it will automatically rename these items, e.g. " filename.txt" would become "_1CZVG~B". This "mangling" of file and folder names inevitably leads to errors during a backup task. To avoid these errors, you should either rename the offending files on the source, or connect to the NAS device using a different protocol. Choose Connect to server from the Finder's Go menu, then specify "afp://servername.local/volume" to connect to the server using a different protocol.

Possible workaround: If you can modify the configuration of the SMB file sharing service on your NAS, then you may be able to prevent the service from "mangling" these file names. The applicable setting is documented here.

Another common issue that people encounter when copying files to a NAS volume is errors that are the result of a name restriction. For example, Synology NAS devices (and many others) disallow file names that start with .lock, CON, PRN, AUX, NUL, COM0 - COM9, LPT0 - LPT9, _vti_, desktop.ini, any filename starting with ~$. These NAS devices often produce bogus error codes in these cases, e.g. "File name too long". Some NAS devices have specific character restrictions as well, e.g. NAS devices that follow the Microsoft OneDrive naming conventions, which exclude " * : < > ? / \ |, and leading and trailing spaces in file or folder names also aren't allowed.

To access the advanced settings, click the Advanced Settings button at the bottom of the window.

The "gear" icon to the left of the Advanced Settings button will be red if any advanced settings have been customized from the default settings.

Preflight

See these two sections of documentation for detailed information about the settings available in the Preflight tab:

• Performing actions Before and After the backup task
• Automated maintenance of the CCC SafetyNet folder

File Copying Settings

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 back up 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. This option is also disabled if the originally-selected destination device is not attached.

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 Projects folder will not be moved to the _CCC SafetyNet folder because it is unique to the root level of the destination. The Firefly 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 Documents folder will be moved to the _CCC SafetyNet folder (or deleted if you have disabled the SafetyNet).

The "root" of the destination refers to the first or top-most folder relative to your selected destination. If you selected a volume named CCC Backup as the destination, then the root level refers to the root of the volume — what you see when you open that volume in the Finder (the middle pane in the screenshot above). If you selected a folder as the destination for your task, then the "items at the root of the destination" refers to the items that you find in that specific folder that you selected as the destination, not the root of the whole volume. When you select a folder as the destination, anything outside of that folder is completely outside of the scope of the backup task, and will be left alone by that particular backup task.

Run a deletion pass first

This setting is only applicable when using a Remote Macintosh source or destination. In all other cases, CCC will automatically perform a deletion pass when necessary

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.

Postflight

See these sections of documentation for detailed information about the settings available in the Postflight tab:

• Postflight verification: Verify files that were copied during the current task event
• Performing actions Before and After the backup task

Performance & Analysis

Maintain a record of transactions

This option enables the collection of a list of files and folders that were modified by each task event. See these articles for more information about CCC's collection and use of transactions:

• Audits: Viewing details about the modifications made by the backup task
• Transaction privacy and disabling transaction collection

"Maintain a record of transactions" is not available for "Remote Macintosh" tasks

The collection of transactions relies on functionality that is only available in CCC's new file copier. Remote Macintosh tasks use the legacy file copier, so cannot store records of the files that were copied.

Use Quick Update when it's possible to collect a list of modified folders from macOS

macOS operates a service that tracks filesystem activity on locally-attached volumes. This "FSEvents" service can be queried to get a list of folders that have been modified since a particular time. When this feature is enabled, the CCC task will limit its enumeration of the source to only the folders that were modified since the last time this particular task ran successfully. This feature can greatly decrease the overall run time for each backup task event, especially in cases where your source has a very high file count, and a large number of folders that are not modified frequently.

This feature assumes that the destination is not modified outside of the task's purview. This is not an insignificant assumption, and that's why this feature is disabled by default. You must assess your usage of the destination when deciding whether to use this feature. If you make modifications to the destination outside of CCC, or by another CCC backup task, then those modifications may not be accommodated for (or corrected, for example, if you deleted something from the destination) when this feature is enabled.

If you ever want to verify that the destination is whole, you can right-click on the Quick Update button and choose the Standard Copy option to have CCC do a one-time enumeration of the entire source and destination.

Quick Update is overridden when some task settings are modified, and when errors are encountered

If you change the source or destination to your backup task, or if you make any modifications to the task Filter, CCC will perform a regular backup when the task next runs. Additionally, if errors were encountered during a backup task event, CCC will use the start time of the last successful event as the basis for collecting a list of modified folders. After the task completes successfully, Quick Update will be used for subsequent task events.

Quick Update and the "Disable strict volume identification" setting

If you are using a "rotating" pair of backup devices for a single task, i.e. using the "Disable strict volume identification" setting, note that Quick Update will be ignored every time the destination volume's unique identifier has changed since the previous task event. If you would like to use Quick Update with a pair of rotating backup volumes, we recommend that you configure separate tasks for each destination.

Quick Update requires a locally-attached, APFS or HFS+ formatted source, and is not available for "Remote Macintosh" tasks

The Quick Update feature relies on functionality that is only available in CCC's new file copier. Remote Macintosh tasks use the legacy file copier, so cannot take advantage of the Quick Update feature. Additionally, the Quick Update feature draws information from the macOS FSEvents service. CCC will only make FSEvents queries to an APFS or HFS+ formatted source volume.

Quick Update can be periodically audited with the "Find and replace corrupted files" setting or a "Standard Copy"

The Quick Update feature and the "Find and replace corrupted files" settings were designed to complement each other. Quick Update provides a way to quickly determine the files that were modified since a previous task – trusting the changes reported by a macOS service, while "Find and replace corrupted files" offers a more thorough, "trust but verify" analysis of changes to both the source and destination. If you use the Quick Update feature, we recommend that you complement this feature with a weekly or monthly audit by the "Find and replace corrupted files" setting (the time-based application of that feature is available in the popup menu to its right), or by periodically clicking the Standard Copy button.

Find and replace corrupted files, "Backup Health Check"

See this Kbase article for additional details on the "Find and replace corrupted files" option:

• Backup Health Check: Verify before copying, automatically replace corrupted destination files

File copier CPU priority

By default, CCC runs its file copier at the default CPU priority for maximum performance. If you find that your backups have a noticeable impact on system performance, you can either schedule your tasks to run at a more convenient time, or you can reduce the CPU priority of the file copier. This will generally make the task take longer, but the task should have a less noticeable impact on system performance.

File copier queues

When your task runs, CCC decides how much concurrency is appropriate for your selected source and destination devices. If both the source and destination can be identified as Solid State devices, CCC will simultaneously process up to four folders at once, and copy up to eight files at a time. In other cases, CCC will simultaneously process two folders and two files at a time. If you have solid state media in an enclosure that hides the hardware details (or in a NAS device), you may find that you get better performance from your task by increasing the number of file copier queues. See this section of CCC's documentation for additional insight into the File copier queues setting:

• CCC's file copier is tuned for modern, high performance storage