Rather than requiring you to enter admin credentials every time you want to run a task or make changes to a task, CCC 4 now only requires you to authenticate once when CCC is initially installed. While this new configuration is easier to use and has been requested by countless users, there are situations where this configuration is not appropriate. If you leave your system unattended with an admin user logged in, someone with physical access to your system can modify or run your CCC backup tasks. If you cannot rely upon the physical security of your Mac to prevent someone from using your Mac, you can use the information below to apply a stricter security policy to CCC.

Require administrator authorization to make changes to tasks and to run or stop tasks

CCC identifies a subset of activity that causes changes to CCC tasks and preferences or that require access to privileged data (e.g. CCC's private keychain). Performing these tasks requires that the user is authorized for the "com.bombich.ccc.helper" privilege. The default rules for this privilege require that the requesting user is either an admin user, or can provide administrator credentials. Once the authorization is obtained, the user is allowed to perform the privileged tasks without additional authorization until the login session ends.

You can modify these rules in several ways. Most commonly, you may want to require the logged-in user to explicitly provide admin credentials to gain this authorization (vs. having the privileged granted simply because the user is an administrator). Additionally, you may want this authorization to expire after a specific amount of time, e.g. 5 minutes (vs. "when the user logs out"). To apply these stricter rules, paste the following into the Terminal application:

security authorizationdb read com.bombich.ccc.helper > /tmp/ccc.plist
defaults delete /tmp/ccc "authenticate-user"
defaults write /tmp/ccc "authenticate-admin" -bool YES
defaults write /tmp/ccc timeout -int 300
defaults write /tmp/ccc shared -bool NO
plutil -convert xml1 /tmp/ccc.plist
security authorizationdb write com.bombich.ccc.helper < /tmp/ccc.plist
security authorize -ud com.bombich.ccc.helper

Immediately revoking authorization to modify CCC tasks

If you have decided to apply a liberal timeout value to the "com.bombich.ccc.helper" privilege, you may occasionally want to revoke that authorization immediately. To immediately revoke that authorization, paste the following line into the Terminal application:

security authorize -ud com.bombich.ccc.helper

Resetting CCC's authorization rules back to default values

To reset CCC's authorization rules back to the default values, paste the following into the Terminal application:

security authorizationdb remove com.bombich.ccc.helper
security authorize -ud com.bombich.ccc.helper

The next time you attempt to modify or run a CCC backup task, CCC will re--apply its default rule set in macOS's Authorization database.

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

You can avoid archiving the older versions of these virtual machine container files by creating a separate backup task for the parent folder of the virtual machine container files. Here's how to set things up:

1. Create a new task and name it something like Everything except Parallels
2. Choose your startup disk from CCC's Source selector
3. Choose Selected files... from the Clone popup menu (underneath the Source selector)
4. In the list of items to be copied, 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).
5. Choose your backup volume from the Destination selector
6. SafetyNet should be ON
7. Configure the task to run Daily and Save the changes
8. Create a new task and name it something like Parallels Backup
9. 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.
10. Choose Choose a folder from the Destination selector and select the Parallels folder on your backup volume as the destination
11. Turn SafetyNet OFF for this task
12. Schedule this task, then save the changes

Additionally, if you enable Advanced settings for the first task, you can configure it to run that second task as a postflight action.

If you're using an application firewall such as Little Snitch, you will see several outgoing network connections coming from CCC. We explain below what connections you should expect to see, and also explain why some connections that look unexpected are simply misreported by Little Snitch.

Ordinary activity

CCC will make external network connections for the following activity:

• † When you launch CCC and it is a scheduled time to check for a software update (bombich.com and mc.bombich.com)
• † When anonymous application usage statistics are submitted to Paddle (via the "CCC Stats Service" to www.paddleapi.com)
• When you submit a ticket to our help desk (mew.bombich.com and carboncopycloner.zendesk.com)
• When you view the documentation (which takes you to our website, bombich.com)
• When you visit our store (which also takes you to our website, bombich.com and our sales vendor, sites.fastspring.com)
• If you have set up email notifications for completed tasks
• If your backup task specifies a network volume or remote Macintosh as the source or destination

† These activities are enabled only upon your assent when you first launch CCC, and can be suppressed any time later via the Software Update section of CCC's Preferences window.

When you view the documentation via CCC, you connect to bombich.com just as you would in your web browser. Like most websites, bombich.com connects to other domains for certain purposes. We use Content Delivery Networks (CDNs) to serve our static content, such as file downloads, images, styling, fonts, and so on. The CDNs we use are bootstrapCDN (which is hosted by maxCDN) for styling, jquery and fastly for scripts, Google for fonts, Rackspace (rackcdn, hosted by akamai) for files and images. CDNs not only provide powerful servers, they also have servers around the world and pick the one nearest to the user so that content can be delivered faster.

FastSpring is our e-commerce partner that handles everything to do with pricing and purchasing. If you go to our store, you are directed to their website. They use Cloudfront, Amazon's CDN service, to host some of their static content.

Why does Little Snitch indicate that CCC is connecting to google.com and other unrelated-seeming domains?

When CCC connects to any server, Little Snitch (or any monitor) sees the IP address only. It then makes a guess as to the domain name associated with that connection, which makes it much easier for the user to recognize. Because CDNs are used to serve files for hundreds of different websites and companies, everything is very interconnected, and sometimes an IP address has dozens of different domain names associated with it. You can actually see Little Snitch's other possible guesses by clicking the domain name in bold in the Little Snitch window:

It could pull any host name from the list, and we don't know what algorithm Little Snitch uses to decide which one to choose.

The result: google.ca, google.com, googleapis.com, and ytimg.com are all domains associated with Google's servers. We aren't actually connecting to all these domains, but when we connect to Google Web Fonts, for example, we're accessing some of the same servers.

You can view a list of the CDNs that we use here (and also look at any other websites you are curious about). This forum post at the ObDev website describes a similar report of the same problem (unrelated to CCC): Little Snitch showing wrong host name for IP.

According to ObDev developers, it is crucial for Little Snitch to avoid unnoticed ruleset changes. Little Snitch therefore has numerous mechanisms to detect whether it is using the exact same ruleset file, as in, on the same volume and at the same physical address on that disk. This sort of mechanism makes it impossible for Little Snitch to use the ruleset on the booted backup volume without physical intervention from a user at the system (thus the dialog asking if it's OK to use the current version of rules or to use a default ruleset).

In cases where you have physical access to your computer while booting from the backup, the solution is straightforward — simply click the button to use the current rule set and everything behaves as normal.

In cases where you do not have physical access to the system, e.g. you have a server in a colocation facility, there is a logistical challenge. While Little Snitch is reporting that the ruleset doesn't match, it's also preventing network connectivity to and from the server. If you rely on VNC screen sharing to access the system, you will be unable to access the system to accept the current version of the Little Snitch ruleset.

According to ObDev developers, you can avoid this logistical lockout by removing the following two items from your backup volume before rebooting from it:

/Library/Extensions/LittleSnitch.kext
/Library/Little Snitch

Once rebooted, reinstall Little Snitch to regain the application firewall and all is well.

While that method works fine for cases in which you plan to reboot from the backup volume, you're potentially in a lurch if you have an unplanned incident, e.g. the server's hard drive fails. To avoid encountering this problem altogether, you can exclude those files from your backup task:

CCC does not delete files from the destination that are excluded from the backup task, so be sure to remove those items from your destination if you have already established your backup.

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

Default Filter Behavior

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

Include everything by default: Define what is excluded

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

Exclude everything by default: Define what is included

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

Calculating disk usage and Protected Size

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

Source and destination options

By default, CCC won't copy the contents of the Finder Trash because, well, it's Trash. If you want CCC to back up your Trash, uncheck the Don't copy Finder's Trash box to remove the exclusion.

Excluded files are not deleted from the destination

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

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

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

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

Custom Filters

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

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

Anchored path filter

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

Subpath filter

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

Wildcard characters

Wildcard characters can be added to an expression to match a wider range of files and folders. * will match one or more characters in any single file or folder name, e.g. *.mov will match all movie files. /**/ will match one or more path components, e.g. /Users/**/*.jpg will match any JPEG photos in any user home folders, but won't match JPEG photos elsewhere, e.g. those in /Library/Desktop Pictures. ? can be used to match any single character, e.g. *.mp? will match both .mp3 and .mp4 files. Use the ? wildcard sparingly, it will greatly increase the amount of time required to evaluate the task filter.

Expert settings

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

Exporting and Importing filters

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

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

Items automatically excluded

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

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

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

Related documentation

• Folder-to-Folder Backups
• Restoring an item from a hidden folder
• Some files and folders are automatically excluded from a backup task

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

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

Use strict volume identification

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

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

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

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

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

Protect root-level items

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

And you have these items on the destination volume:

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

Find and replace corrupted files

CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. CCC then uses these MD5 checksums to determine if a file should be copied. This option will increase your backup time, but it will expose any corrupted files within your backup set on the source and destination. This is a reliable method of verifying that the files that have been copied to your destination volume actually match the contents of the files on the source volume.

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

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

Note: CCC will never replace a valid file on your destination with an unreadable, corrupt file from the source. If CCC cannot read a file on your source volume, any existing backup of that file will remain intact on your backup volume and CCC will report an error, advising you to replace the source file with the intact backup version.

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

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

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

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

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

Troubleshooting Options

Run a deletion pass first

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

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

Don't update newer files on the destination

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

Don't preserve permissions

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

Don't preserve extended attributes

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

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

Related Documentation

• CCC reported that the destination is full. What can I do to avoid this?
• Troubleshooting slow performance when copying files to or from a network volume

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 can restrict the task to running between 6PM and 12PM. This limit will prevent the task from starting during those times. If the task is already running, CCC will stop the task if it is still running when the end limit is reached.

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

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.

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 this task 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.

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.

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're using an application firewall such as Little Snitch, you will see several outgoing network connections coming from CCC. We explain below what connections you should expect to see, and also explain why some connections that look unexpected are simply misreported by Little Snitch.

Ordinary activity

CCC will make external network connections for the following activity:

• † When you launch CCC and it is a scheduled time to check for a software update (bombich.com and mc.bombich.com)
• † When anonymous application usage statistics are submitted to Paddle (via the "CCC Stats Service" to www.paddleapi.com)
• When you submit a ticket to our help desk (mew.bombich.com and carboncopycloner.zendesk.com)
• When you view the documentation (which takes you to our website, bombich.com)
• When you visit our store (which also takes you to our website, bombich.com and our sales vendor, sites.fastspring.com)
• If you have set up email notifications for completed tasks
• If your backup task specifies a network volume or remote Macintosh as the source or destination

† These activities are enabled only upon your assent when you first launch CCC, and can be suppressed any time later via the Software Update section of CCC's Preferences window.

When you view the documentation via CCC, you connect to bombich.com just as you would in your web browser. Like most websites, bombich.com connects to other domains for certain purposes. We use Content Delivery Networks (CDNs) to serve our static content, such as file downloads, images, styling, fonts, and so on. The CDNs we use are bootstrapCDN (which is hosted by maxCDN) for styling, jquery and fastly for scripts, Google for fonts, Rackspace (rackcdn, hosted by akamai) for files and images. CDNs not only provide powerful servers, they also have servers around the world and pick the one nearest to the user so that content can be delivered faster.

FastSpring is our e-commerce partner that handles everything to do with pricing and purchasing. If you go to our store, you are directed to their website. They use Cloudfront, Amazon's CDN service, to host some of their static content.

Why does Little Snitch indicate that CCC is connecting to google.com and other unrelated-seeming domains?

When CCC connects to any server, Little Snitch (or any monitor) sees the IP address only. It then makes a guess as to the domain name associated with that connection, which makes it much easier for the user to recognize. Because CDNs are used to serve files for hundreds of different websites and companies, everything is very interconnected, and sometimes an IP address has dozens of different domain names associated with it. You can actually see Little Snitch's other possible guesses by clicking the domain name in bold in the Little Snitch window:

It could pull any host name from the list, and we don't know what algorithm Little Snitch uses to decide which one to choose.

The result: google.ca, google.com, googleapis.com, and ytimg.com are all domains associated with Google's servers. We aren't actually connecting to all these domains, but when we connect to Google Web Fonts, for example, we're accessing some of the same servers.

You can view a list of the CDNs that we use here (and also look at any other websites you are curious about). This forum post at the ObDev website describes a similar report of the same problem (unrelated to CCC): Little Snitch showing wrong host name for IP.

Rather than requiring you to enter admin credentials every time you want to run a task or make changes to a task, CCC only requires you to authenticate once when CCC is initially installed. While this configuration is easier to use, there are situations where this configuration is not appropriate. If you leave your system unattended with an admin user logged in, someone with physical access to your system can modify or run your CCC backup tasks. If you cannot rely upon the physical security of your Mac to prevent someone from using your Mac, you can use the information below to apply a stricter security policy to CCC.

Require administrator authorization to make changes to tasks and to run or stop tasks

CCC identifies a subset of activity that causes changes to CCC tasks and preferences or that require access to privileged data (e.g. CCC's private keychain). Performing these tasks requires that the user is authorized for the "com.bombich.ccc.helper" privilege. The default rules for this privilege require that the requesting user is either an admin user, or can provide administrator credentials. Once the authorization is obtained, the user is allowed to perform the privileged tasks without additional authorization until the login session ends.

You can modify these rules in several ways. Most commonly, you may want to require the logged-in user to explicitly provide admin credentials to gain this authorization (vs. having the privileged granted simply because the user is an administrator). Additionally, you may want this authorization to expire after a specific amount of time, e.g. 5 minutes (vs. "when the user logs out"). To apply these stricter rules, paste the following into the Terminal application:

security authorizationdb read com.bombich.ccc.helper > /tmp/ccc.plist
defaults delete /tmp/ccc "authenticate-user"
defaults write /tmp/ccc "authenticate-admin" -bool YES
defaults write /tmp/ccc timeout -int 300
defaults write /tmp/ccc shared -bool NO
plutil -convert xml1 /tmp/ccc.plist
security authorizationdb write com.bombich.ccc.helper < /tmp/ccc.plist
security authorize -ud com.bombich.ccc.helper

Immediately revoking authorization to modify CCC tasks

If you have decided to apply a liberal timeout value to the "com.bombich.ccc.helper" privilege, you may occasionally want to revoke that authorization immediately. To immediately revoke that authorization, paste the following line into the Terminal application:

security authorize -ud com.bombich.ccc.helper

Resetting CCC's authorization rules back to default values

To reset CCC's authorization rules back to the default values, paste the following into the Terminal application:

security authorizationdb remove com.bombich.ccc.helper
security authorize -ud com.bombich.ccc.helper

The next time you attempt to modify or run a CCC backup task, CCC will re--apply its default rule set in macOS's Authorization database.

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

You can avoid archiving the older versions of these virtual machine container files by creating a separate backup task for the parent folder of the virtual machine container files. Here's how to set things up:

1. Create a new task and name it something like Everything except Parallels
2. Choose your startup disk from CCC's Source selector
3. Choose Some files... from the Clone popup menu (underneath the Source selector)
4. 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).
5. Choose your backup volume from the Destination selector
6. SafetyNet should be ON
7. Configure the task to run Daily and Save the changes
8. Create a new task and name it something like Parallels Backup
9. 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.
10. Choose Choose a folder... from the Destination selector and select the Parallels folder on your backup volume as the destination
11. Turn SafetyNet OFF for this task
12. Schedule this task, then save the changes

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

According to ObDev developers, it is crucial for Little Snitch to avoid unnoticed ruleset changes. Little Snitch therefore has numerous mechanisms to detect whether it is using the exact same ruleset file, as in, on the same volume and at the same physical address on that disk. This sort of mechanism makes it impossible for Little Snitch to use the ruleset on the booted backup volume without physical intervention from a user at the system (thus the dialog asking if it's OK to use the current version of rules or to use a default ruleset).

In cases where you have physical access to your computer while booting from the backup, the solution is straightforward — simply click the button to use the current rule set and everything behaves as normal.

In cases where you do not have physical access to the system, e.g. you have a server in a colocation facility, there is a logistical challenge. While Little Snitch is reporting that the ruleset doesn't match, it's also preventing network connectivity to and from the server. If you rely on VNC screen sharing to access the system, you will be unable to access the system to accept the current version of the Little Snitch ruleset.

According to ObDev developers, you can avoid this logistical lockout by removing the following two items from your backup volume before rebooting from it:

/Library/Extensions/LittleSnitch.kext
/Library/Little Snitch

Once rebooted, reinstall Little Snitch to regain the application firewall and all is well.

While that method works fine for cases in which you plan to reboot from the backup volume, you're potentially in a lurch if you have an unplanned incident, e.g. the server's hard drive fails. To avoid encountering this problem altogether, you can exclude those files from your backup task.

CCC does not delete files from the destination that are excluded from the backup task, so be sure to remove those items from your destination if you have already established your backup.

CCC determines whether your destination volume will be bootable and indicates any configuration concerns in the "Cloning Coach" window. If you see a yellow warning icon in the Task Plan header, you can click on that icon to see these concerns. CCC will also present these concerns to you the first time that you configure a backup task to any particular destination volume.

If CCC doesn't raise any configuration concerns, and the destination volume has an OS on it when the backup task is completed, and barring any hardware problems that might interfere, your backup volume should be bootable.

Configuration concerns that affect the bootability of the destination volume

CCC looks for the following configurations to determine if a destination volume will not be bootable:

• The destination volume cannot be a disk image — you cannot boot your Macintosh from a disk image.
• The files and folders required by macOS must be present on the source volume. These include: /Library, /System, /bin, /etc, /mach_kernel, /private, /sbin, /tmp, /usr, and /var.
• The files and folders that are required by macOS must not be excluded from the backup (applicable only if you have chosen to back up "Selected files").
• The hard drive on which the destination volume resides must be partitioned using the GUID Partition Table partitioning scheme.
• CCC will issue a warning if the operating system that you're backing up (or restoring) is older than the OS that your model of Mac shipped with.
• CCC will issue a warning if the destination volume is larger than 2TB and the device is connected to your Mac via USB.

CCC does not maintain an exhaustive list of hardware:shipping OS pairs. CCC also cannot determine whether the destination will be bootable when the source or destination are remote Macintosh volumes.

Related documentation:

• What makes a volume bootable?
• Don't install older versions of macOS

Configuration concerns that affect the preservation of filesystem metadata

CCC will note a concern if there is a compatibility mismatch between the source and destination filesystems. For example, if you are backing up files from an HFS+ volume to a network filesystem, some of the filesystem metadata cannot be preserved. In many cases this is acceptable and you can ignore the message. Each of the possible concerns that CCC might raise are listed below. The "risk" associated with not preserving each type of metadata is explained plainly, so you can decide whether the destination volume will suit your needs.

The destination doesn't support Access Control Lists

Access Control Lists specify a granular list of the privileges that users and groups have for a particular file or folder (e.g., read, write, get information, delete, etc.). These advanced privilege settings generally apply only to user accounts that have been created on your Macintosh — for example, to prevent other users from deleting items from your home directory. If you are backing up your own files to a locally-attached hard drive, or to a network file share on a trusted computer, the Access Control List filesystem metadata is relatively unimportant. If you are backing up to or from a network filesystem in a business or education setting, however, check with your tech support staff for additional advice on whether this metadata must be preserved.

The destination doesn't support hard links

A hard link makes a single file appear to be located in multiple places on your hard drive. If a single file had 20 hard links scattered across the disk, each hard link file would consume no additional space on the hard drive, and editing the content of any one of those files would immediately affect the content of every other hard link to that file.

When you back up the contents of a volume that contains hard links, ideally you want to preserve the hard links. If the destination filesystem doesn't support hard links, each hard linked file will be disassociated from the original file and will become a copy on the destination. This won't result in any loss of data, but your backup set will consume more space on the destination than on the source. Hard links are leveraged quite a bit on macOS by the operating system, though they are generally less common among user data.

The destination doesn't support ownership

File ownership indicates which user account on your Mac has control of a file. The owner of a file can limit access to that file from other users on the same computer. If the destination doesn't support ownership, then the owner of each file copied to the destination will be set to the user that mounted the destination. If the destination volume is accessed elsewhere (e.g. mounted on another Mac or even by a different user on the same Mac), then any restrictions that you have placed on those files may not be honored. If you are backing up files and folders that are not all owned by the same user (e.g. you), you should consider backing up to a local, HFS+ formatted volume or to a disk image instead.

Some filesystems have file size limitations

Some filesystems have restrictions on how large a file can be. FAT32, for example, limits files to 4GB or less. CCC will proactively warn you of this limitation if you choose to back up a volume whose filesystem supports files larger than 4GB to a filesystem that does not support files larger than 4GB. CCC will then automatically exclude files larger than 4GB from the backup task. Files that were excluded will be reported at the end of the backup task.

If you require that files larger than 4GB are backed up, you must reformat the destination volume with a format that supports larger files.

Related documentation:

• Preparing your backup disk for a backup of macOS

The destination already has an installation of macOS. Merging a different version of macOS into this destination may cause problems with that installation of macOS

This message appears if you choose the "Don't delete anything" SafetyNet setting. While that setting will protect any data that you have on the destination volume that is unique to that volume, it does a disservice to the installation of macOS on your destination. This message will also appear if you use the "Don't update newer files on the destination" advanced troubleshooting setting.

Suppose, for example, that you have a complete backup of Mac OS 10.9.3 on your backup volume. When you apply the 10.9.4 update to your source volume, many system files are updated, some new files are added, and some files may be deleted. If you use CCC to update your backup volume, but you don't allow CCC to delete the items on the destination that the OS update had deleted from the source, then there will be a bunch of "cruft" left over on the backup volume. If you should ever need to boot your Mac from your backup volume, these cruft files could cause the OS to behave unexpectedly, and they may prevent it from booting altogether.

CCC can help you perform a clean upgrade or downgrade of macOS on the destination volume by moving items that should be deleted to the SafetyNet folder. Any files and folders that you keep only on the destination would also be moved to the SafetyNet folder. See the Protecting data that is already on your destination volume section of the documentation for more details on these settings.

CCC warns that Macs cannot boot from USB devices larger than 2TB

In the past we received several reports of bootability problems related to USB devices larger than 2TB. At that time, we performed a simple litmus test: create an "x"TB partition at the beginning of the disk (varying x from 0.5 to 2.5TB) and a second partition consuming the remainder of the disk, then install macOS onto both partitions. The results of those tests suggested that some Macs couldn't "see" the partition that lied past the 2TB mark on the disk. This limitation was specific to USB devices — none of these problems occurred if you were to place the same disk into a Thunderbolt or Firewire enclosure.

At the time of those initial reports and testing, the results were consistent. We concluded that there was likely a 32-bit addressing limitation imposed by the USB drivers that are embedded in the Macs' firmware ("likely"— unfortunately none of this information is documented by Apple). More recently, however, we've been unable to consistently reproduce the same results. Apple may have addressed the problem with a firmware update. It's also possible that our initial conclusion was wrong, e.g. that the problem was due to a partition alignment error; an error specific to macOS El Capitan and apparently only USB devices (you'd see "disk2s2: alignment error" messages in the system log when the affected volume is mounted).

In any case, CCC's warning was issued out of an abundance of caution. Our current recommendation is to partition the destination device using the same procedure as defined for all other destination devices, and do the partitioning while booted from any other OS than El Capitan. In other words, don't create a 2TB partition at the beginning of the disk. Once you have completed your first backup, though, we encourage you to verify that your Mac will boot from the backup volume. If your Mac is unable to boot from the backup volume, please reach out to us so we can investigate your specific configuration further.

Help! My clone won't boot!

See this section of CCC's documentation for troubleshooting advice if you're having trouble getting your backup volume to start your Mac.

CCC determines whether your destination volume will be bootable and indicates any configuration concerns in the "Cloning Coach" window. If you see a yellow warning icon in the Task Plan header, you can click on that icon to see these concerns. CCC will also present these concerns to you the first time that you configure a backup task to any particular destination volume.

If CCC doesn't raise any configuration concerns, and the destination volume has an OS on it when the backup task is completed, and barring any hardware problems that might interfere, your backup volume should be bootable.

Configuration concerns that affect the bootability of the destination volume

CCC looks for the following configurations to determine if a destination volume will not be bootable:

• The destination volume cannot be a disk image — you cannot boot your Macintosh from a disk image.
• The files and folders required by macOS must be present on the source volume. These include: /Library, /System, /bin, /etc, /mach_kernel, /private, /sbin, /tmp, /usr, and /var.
• The files and folders that are required by macOS must not be excluded from the backup (applicable only if you have chosen to back up "Selected files").
• The hard drive on which the destination volume resides must be partitioned using the GUID Partition Table partitioning scheme.
• CCC will issue a warning if the operating system that you're backing up (or restoring) is older than the OS that your model of Mac shipped with.
• CCC will issue a warning if the destination volume is larger than 2TB and the device is connected to your Mac via USB.

CCC does not maintain an exhaustive list of hardware:shipping OS pairs. CCC also cannot determine whether the destination will be bootable when the source or destination are remote Macintosh volumes.

Related documentation:

• What makes a volume bootable?
• Don't install older versions of macOS

Configuration concerns that affect the preservation of filesystem metadata

CCC will note a concern if there is a compatibility mismatch between the source and destination filesystems. For example, if you are backing up files from an HFS+ volume to a network filesystem, some of the filesystem metadata cannot be preserved. In many cases this is acceptable and you can ignore the message. Each of the possible concerns that CCC might raise are listed below. The "risk" associated with not preserving each type of metadata is explained plainly, so you can decide whether the destination volume will suit your needs.

The destination doesn't support Access Control Lists

Access Control Lists specify a granular list of the privileges that users and groups have for a particular file or folder (e.g., read, write, get information, delete, etc.). These advanced privilege settings generally apply only to user accounts that have been created on your Macintosh — for example, to prevent other users from deleting items from your home directory. If you are backing up your own files to a locally-attached hard drive, or to a network file share on a trusted computer, the Access Control List filesystem metadata is relatively unimportant. If you are backing up to or from a network filesystem in a business or education setting, however, check with your tech support staff for additional advice on whether this metadata must be preserved.

The destination doesn't support hard links

A hard link makes a single file appear to be located in multiple places on your hard drive. If a single file had 20 hard links scattered across the disk, each hard link file would consume no additional space on the hard drive, and editing the content of any one of those files would immediately affect the content of every other hard link to that file.

When you back up the contents of a volume that contains hard links, ideally you want to preserve the hard links. If the destination filesystem doesn't support hard links, each hard linked file will be disassociated from the original file and will become a copy on the destination. This won't result in any loss of data, but your backup set will consume more space on the destination than on the source. Hard links are leveraged quite a bit on macOS by the operating system, though they are generally less common among user data.

The destination doesn't support ownership

File ownership indicates which user account on your Mac has control of a file. The owner of a file can limit access to that file from other users on the same computer. If the destination doesn't support ownership, then the owner of each file copied to the destination will be set to the user that mounted the destination. If the destination volume is accessed elsewhere (e.g. mounted on another Mac or even by a different user on the same Mac), then any restrictions that you have placed on those files may not be honored. If you are backing up files and folders that are not all owned by the same user (e.g. you), you should consider backing up to a local, HFS+ formatted volume or to a disk image instead.

Some filesystems have file size limitations

Some filesystems have restrictions on how large a file can be. FAT32, for example, limits files to 4GB or less. CCC will proactively warn you of this limitation if you choose to back up a volume whose filesystem supports files larger than 4GB to a filesystem that does not support files larger than 4GB. CCC will then automatically exclude files larger than 4GB from the backup task. Files that were excluded will be reported at the end of the backup task.

If you require that files larger than 4GB are backed up, you must reformat the destination volume with a format that supports larger files.

Related documentation:

• Preparing your backup disk for a backup of macOS

The destination already has an installation of macOS. Merging a different version of macOS into this destination may cause problems with that installation of macOS

This message appears if you choose the "Don't delete anything" SafetyNet setting. While that setting will protect any data that you have on the destination volume that is unique to that volume, it does a disservice to the installation of macOS on your destination. This message will also appear if you use the "Don't update newer files on the destination" advanced troubleshooting setting.

Suppose, for example, that you have a complete backup of Mac OS 10.9.3 on your backup volume. When you apply the 10.9.4 update to your source volume, many system files are updated, some new files are added, and some files may be deleted. If you use CCC to update your backup volume, but you don't allow CCC to delete the items on the destination that the OS update had deleted from the source, then there will be a bunch of "cruft" left over on the backup volume. If you should ever need to boot your Mac from your backup volume, these cruft files could cause the OS to behave unexpectedly, and they may prevent it from booting altogether.

CCC can help you perform a clean upgrade or downgrade of macOS on the destination volume by moving items that should be deleted to the SafetyNet folder. Any files and folders that you keep only on the destination would also be moved to the SafetyNet folder. See the Protecting data that is already on your destination volume section of the documentation for more details on these settings.

CCC warns that Macs cannot boot from USB devices larger than 2TB

In the past we received several reports of bootability problems related to USB devices larger than 2TB. At that time, we performed a simple litmus test: create an "x"TB partition at the beginning of the disk (varying x from 0.5 to 2.5TB) and a second partition consuming the remainder of the disk, then install macOS onto both partitions. The results of those tests suggested that some Macs couldn't "see" the partition that lied past the 2TB mark on the disk. This limitation was specific to USB devices — none of these problems occurred if you were to place the same disk into a Thunderbolt or Firewire enclosure.

At the time of those initial reports and testing, the results were consistent. We concluded that there was likely a 32-bit addressing limitation imposed by the USB drivers that are embedded in the Macs' firmware ("likely"— unfortunately none of this information is documented by Apple). More recently, however, we've been unable to consistently reproduce the same results. Apple may have addressed the problem with a firmware update. It's also possible that our initial conclusion was wrong, e.g. that the problem was due to a partition alignment error; an error specific to macOS El Capitan and apparently only USB devices (you'd see "disk2s2: alignment error" messages in the system log when the affected volume is mounted).

In any case, CCC's warning was issued out of an abundance of caution. Our current recommendation is to partition the destination device using the same procedure as defined for all other destination devices, and do the partitioning while booted from any other OS than El Capitan. In other words, don't create a 2TB partition at the beginning of the disk. Once you have completed your first backup, though, we encourage you to verify that your Mac will boot from the backup volume. If your Mac is unable to boot from the backup volume, please reach out to us so we can investigate your specific configuration further.

Help! My clone won't boot!

See this section of CCC's documentation for troubleshooting advice if you're having trouble getting your backup volume to start your Mac.

Adding a task

Tasks can be added in several different ways. To create a new task with default settings, click the + icon in the Tasks table header, or choose New Task from CCC's File menu, or click the New Task button in CCC's toolbar. You can also duplicate an existing task: select the task in the task list, then choose Duplicate from CCC's File menu, or right-click on the task and choose the option to duplicate it.

If you exported tasks from CCC previously (on your current Mac or on another Mac), double-click the task configuration file to import the task(s) into CCC.

Removing a task

To remove a task, click the - button in the Tasks table header, or select the task and choose Delete Task... from CCC's File menu, or right-click on the task and choose the option to delete the task. Deleting a task only removes the task configuration from CCC's database, it has no effect on any data that the task backed up to a destination volume.

Task Sorting

Tasks are sorted alphabetically in ascending order by default. To change the sort order or criteria, click the triangle icon in the header of the Tasks table. Tasks can be sorted by name, last run time, next run time, last run status, or manually in the order that you define. When defining a manual sort order, simply drag and drop tasks to adjust their order.

Task Groups

Click the Add Task Group (folder with a "+") icon in the Tasks table header to create a new task group. Add tasks to the group by dragging a task into the group. If you would like to add a task to multiple groups, hold down the Option key while dragging the task from one group to another. 

In their most basic form, task groups serve to organize your tasks. Each task in the group can be scheduled and configured independently of the other tasks. Task groups can also be used to run the tasks as a collection. You can run all of the tasks within a group by selecting the Task Group and clicking the Clone button at the bottom of the window. CCC will run the tasks sequentially in the order defined in the Upcoming Group and Task Events table.

Task list sort order vs. task group run order

Tasks listed within a group in the Tasks table will be sorted based on the Tasks table sort criteria. If you have chosen to sort the Tasks table manually, then you can order the tasks within the group in the Tasks table however you want. Don't confuse this with the run order for the tasks within the group. The task run order is defined in the Upcoming Group and Task Events table.

Scheduling task groups

Task groups can be scheduled in the same manner as individual tasks; simply click on the Scheduler selector, choose a scheduling basis, then define when the group should run. Tasks will be run sequentially within the group. If a task has its own schedule configuration, that task will also run independently of the task group. If the task is already running when the task group wants to start it, the task group will move on to the next task in the group. If a task is already running via the task group when its own scheduled run time arrives, the task will continue to run, and will not be run an additional time. Individual task runtime conditions will be taken into account when running the task via the task group. For example, if a task is configured to not run on weekends, that task won't run via the group if the task group runs on the weekend. The only exception to this is when you choose to run a task group manually. In that case, runtime conditions are overridden.

Exporting tasks and groups

Tasks can be exported individually by right-clicking the task in the Tasks table, then choose the option to export the task. You may also export all of the tasks within a task group by right-clicking the task group and choosing the option to export the group, or by choosing Export Task Group... from CCC's File menu. If you would like to export all of your tasks, choose Export All Tasks... from CCC's File menu.

Carbon Copy Cloner 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

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

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 cloned volume.

Volume-specific cache files

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

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 erased on startup

• /private/var/folders/zz/*
• /private/var/vm/*
• /private/tmp/*
• /cores

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 cloned Time Machine volume and recommends instead that you start a new Time Machine backup on the new disk.

• /Backups.backupdb
• /.MobileBackups
• /.MobileBackups.trash
• /.MobileBackups.trash

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.*
• .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 last two items can be found in each user home folder. Excluding these items prevents the applications that were open during the backup task from opening when you boot from the backup volume. 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
• /Library/Caches/CrashPlan
• /PGPWDE01
• /PGPWDE02
• /.bzvol
• /Library/Application Support/Comodo/AntiVirus/Quarantine
• /private/var/spool/qmaster
• $Recycle.Bin
• Saved Application State
• Library/Preferences/ByHost/com.apple.loginwindow*

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. This exclusion is applicable to any folder with the "_CCC" prefix. 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's Advanced Settings are helpful in specific situations, but are not generally required for routine use. Some of these settings involve more risk, so please use them with caution, and don't hesitate to ask questions via the Ask a question about CCC... menu item in CCC's Help menu if the explanations below are insufficient for your particular scenario.

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

Use strict volume identification

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

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

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

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

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

Protect root-level items

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

And you have these items on the destination volume:

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

Find and replace corrupted files

CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. CCC then uses these MD5 checksums to determine if a file should be copied. This option will increase your backup time, but it will expose any corrupted files within your backup set on the source and destination. This is a reliable method of verifying that the files that have been copied to your destination volume actually match the contents of the files on the source volume.

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

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

Note: CCC will never replace a valid file on your destination with an unreadable, corrupt file from the source. If CCC cannot read a file on your source volume, any existing backup of that file will remain intact on your backup volume and CCC will report an error, advising you to replace the source file with the intact backup version.

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

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

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

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

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

Troubleshooting Options

Run a deletion pass first

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

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

Don't update newer files on the destination

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

Don't preserve permissions

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

Don't preserve extended attributes

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

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

Related Documentation

• CCC reported that the destination is full. What can I do to avoid this?
• Troubleshooting slow performance when copying files to or from a network volume

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

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

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

Enabling Remote Login on the remote Macintosh

To enable Remote Login on your remote Macintosh:

1. Log in to that machine as an admin user.
2. Open the System Preferences application.
3. Open the Sharing Preference Pane.
4. Check the box next to Remote Login.
5. Be sure to allow access to All users, or explicitly add the Administrators group to the list of restricted users and groups.
6. Make a note of your remote Mac's hostname. In the settings area on the right, you will see a message to the effect of "To log in to this computer remotely, type 'ssh username@yourhost.yourdomain.com' at a shell command prompt." The text after the "@" symbol is the hostname of your remote Mac.

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 key pair onto the remote Mac. You must provide the username and password of an admin user on the remote Mac to permit this, but for future authentication requests, CCC will use the PKA key pair.

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.

Bandwidth management options

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

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

De-authenticating a remote Macintosh

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

Remote Macintosh prerequisites

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

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

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

Additional pointers for advanced users

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

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

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.

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

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

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

Use strict volume identification

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

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

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

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

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

Protect root-level items

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

And you have these items on the destination volume:

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

Find and replace corrupted files, "Backup Health Check"

CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. CCC then uses these MD5 checksums to determine if a file should be copied. This option will increase your backup time, but it will expose any corrupted files within your backup set on the source and destination. This is a reliable method of verifying that the files that have been copied to your destination volume actually match the contents of the files on the source volume.

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

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

Note: CCC will never replace a valid file on your destination with an unreadable, corrupt file from the source. If CCC cannot read a file on your source volume, any existing backup of that file will remain intact on your backup volume and CCC will report an error, advising you to replace the source file with the intact backup version.

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

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

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

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

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

Troubleshooting Options

Run a deletion pass first

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

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

Don't update newer files on the destination

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

Don't preserve permissions

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

Don't preserve extended attributes

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

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

Related Documentation

• CCC reported that the destination is full. What can I do to avoid this?
• Troubleshooting slow performance when copying files to or from a network volume

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 back up user data to network volumes (e.g. AFP and SMB via macOS and Windows File Sharing) and to other non-macOS-formatted volumes such as FAT32. 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 HFS+ 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.

CCC will only back up system files to 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 non-macOS filesystems, important metadata are invariably 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 limitation, 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, 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", not HFS+ or APFS. It is not possible to update an OS backup on a network volume. If you would like to maintain a backup of macOS on a network volume, you can back up to a disk image on the network volume. See the related documentation below for additional information on this backup strategy.

Related Documentation

• Backing up to a disk image
• Learn about alternatives to backing up macOS to non-macOS-formatted volumes
• Preparing your backup disk for a backup of macOS

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 Clone 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 sharepoint. 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 sharepoint is a Mac, you can modify ownership and permissions in the Get Info panel for that folder (on the Mac hosting the sharepoint):

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 Gear 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 sharepoint 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 as HFS+ 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 Cloning Coach's warnings by clicking on the yellow caution button in the Task Plan header. 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. PogoPlug, 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.

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 Cloning 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 sharepoint. Reconnect to the sharepoint and try the backup task again.
• Connect to the sharepoint 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/sharepoint " or "afp://servername.local/sharepoint " 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, try backing up to a disk image on the network volume instead.