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.
By default, CCC uses the name and Universally Unique Identifier (UUID) of your source and destination to positively identify those volumes. By verifying both of these identifiers, there is less risk in, for example, backing up to a volume that has the same name as your usual destination but is not actually the destination.
While beneficial, this behavior can sometimes have the wrong result. For example, if you rotate between a pair of external hard drives, CCC will not backup to both of them even though they have the same name (e.g. Offsite Backup). CCC will instead claim that the UUID of one of the volumes does not match that of the originally chosen destination.
To accommodate a "rotating pair of backup volumes" solution, you can uncheck this option to indicate that CCC should only use the volume name to identify the destination volume. When deselecting this option, be vigilant that you do not rename your destination volume and that you never attach another non-backup volume to your Mac that is named the same as your destination volume.
This option is automatically disabled when the destination volume does not have a UUID. Network volumes and some third-party filesystems, for example, do not have volume UUIDs.
Note: This setting is only applicable to the destination volume. CCC always uses the name and UUID to positively identify the source volume.
Note: If your rotating destination volumes are encrypted, CCC will only be able to unlock and mount the original encrypted volume selected as the destination for your backup task. CCC must have a unique identifier of the destination volume in order to unlock that volume, and CCC will only retain that information about one destination volume for a particular task. If you would like to rotate a pair of backup disks that are encrypted, we recommend using two separate tasks for that purpose; one for each encrypted destination.
If you have files and folders that are unique to the root-level on your destination volume and you want them to be left alone, yet you want to keep your backup "clean", use the Protect root-level items option. This option is enabled by default when CCC's SafetyNet option is enabled. To understand how this feature works, suppose you have these items on your source volume:
And you have these items on the destination volume:
With the Protect root-level items option, the Videos folder will not be moved to the _CCC SafetyNet folder because it is unique to the root level of the destination. The Users folder is not unique to the root of the destination (it also exists on the source), though, so its contents will be updated to match the source. As a result, the olduseraccount folder will be moved to the _CCC SafetyNet folder (or deleted if you have disabled the SafetyNet).
CCC normally uses file size and modification date to determine whether a file should be copied. With this option, CCC will calculate an MD5 checksum of every file on the source and every corresponding file on the destination. If the checksums differ ,CCC will recopy the file. This option will increase your backup time, but it will expose any corrupted files within your backup set on the source and destination.
Media failures occur on nearly every hard drive at some point in the hard drive's life. These errors affect your data randomly, and go undetected until an attempt is made to read data from the failed sector of media. If a file has not been modified since a previous (successful) backup, CCC will not ordinarily attempt to read every byte of that file's content. As a result, it is possible for a corrupted file to go unnoticed on your source or destination volume. Obviously this is a concern if the file is important, and one day you actually need to recover the contents of that file.
Frequent use of the checksum calculation option is unnecessary and may be a burden upon your productivity, so CCC offers weekly and monthly options to limit how frequently the checksumming occurs.
Note: CCC will never replace a valid file on your destination with an unreadable, corrupt file from the source. If CCC cannot read a file on your source volume, any existing backup of that file will remain intact on your backup volume and CCC will report an error, advising you to replace the source file with the intact backup version. The Find and replace corrupted files setting will only automatically replace corrupted files on the destination, and only when the source file is completely readable.
What is a "corrupted" or "unreadable" file?
With regard to files on the source, CCC's Find and replace corrupted files option specifically refers to files that cannot be physically read from the disk. It does not refer to files that have been mistakenly or maliciously altered such that they cannot be opened by the application that created them.
CCC's checksum option verifies the integrity of the files on your destination volume before files are copied, it is not a verification of files that have just been written. In general, the checksum of a file immediately after it is written to disk is of questionable value. Most disks have a write cache, and file data goes to the cache before it is written to actual media. If you write a file and then immediately ask to read it back, as much as x amount of data (where x = the size of the cache) is going to come from the volatile cache. If any of the file's data comes from the write cache, then the checksum doesn't reflect the status of the data on the permanent media, and that really defeats the purpose of checksumming the file in the first place.
If you want to verify the integrity of the files on your destination immediately after copying files, a subsequent backup with CCC's Find and replace corrupted files option is the best way to do that. You can even automate this process by creating a second task that uses this option, then select the second task in the "Run another backup task" popup menu in the After task runs section of advanced settings.
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.
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.
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.
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.