CCC will copy only items that are different between your source and destination. So if you complete a backup task, then run it again the next day, CCC will copy only the items that were created or modified since that last backup task. CCC determines that a file is different using its size and modification date. If a file's size or modification date is at all different on the source and destination, CCC will copy that file to the destination.
Before concluding that CCC is recopying every file, open your most recent completed task in CCC's Task History window and compare the "Total size of source data set" and "Data copied" values. It is not uncommon for as much as 2-5GB of files to be updated between daily backups, for example, even when it seems that you have made no changes to the source volume. macOS is constantly updating various cache and log files, and these can really add up over the course of a day. If the amount of data copied is just a fraction of the total data set, then the amount of data being copied is probably normal.
Organizational changes will lead to large amounts of data being "recopied"
If you have made large organizational changes on your source volume, e.g. renamed or moved a folder that had a lot of data in it, that will result in many items being recopied to the destination because the path to those items has changed. You can avoid this recopying behavior by applying the same organizational changes to the destination prior to running your backup task.
Some antivirus applications may actually change file modification dates
After CCC has copied a file to the destination, the very last thing that it does is to set the file's modification date to the modification date of the source file. This filesystem activity prompts the AV software to scan the file, which is generally OK (albeit with a performance hit to the backup task). Reading a file is not sufficient to change the file's modification date, so well-written AV applications should cause no harm by scanning the files that CCC copies. When an AV application "touches" the file, however, or otherwise makes changes to the file, the modification date will be updated to the current date.
If the modification date of the files on your destination are getting set to the date and time of the backup tasks, there's a good chance that AV software or some other background service is making changes to the files after CCC has copied them. If you cannot resolve the modification date tampering of your AV software (or other software), you can configure CCC to avoid updating files that are newer on the destination. To apply this setting, select your backup task in CCC's main application window, then:
- Click the Use Advanced Settings button.
- Open the Troubleshooting Options disclosure triangle.
- Check the Don't update newer files on the destination box.
- Save your task.
HFS+, NTFS, and other modern filesystems store the modification date of files based on the Coordinated Universal Time (UTC — comparable to GMT). FAT filesystems, on the other hand, store file modification dates based on the local time zone setting of your computer. Generally this difference isn't a problem, but there is a drawback if you copy files between FAT volumes and NTFS or HFS+ volumes. During time zone shifts and the Daylight Saving Time/Summer Time shift, the modification dates of files on FAT32 volumes will appear to have shifted. As a result, CCC will see these files as out of date and will recopy each file. Unfortunately CCC cannot remediate this shortcoming of the FAT filesystem, so if you have to copy files to or from a FAT volume, we recommend that the corresponding source or destination volume is also FAT formatted.
We have also received sporadic reports of this same problem when copying files to some network filesystems (NAS devices). If you encounter this problem, try the suggestion above to use the Don't update newer files on the destination advanced setting.
This same problem that is described above can occur when copying files to or from some network filesystems (NAS devices). If you encounter this problem, the suggestion above to use the Don't update newer files on the destination advanced setting will resolve the problem for one of the DST changes, but not the other. Another approach is to configure CCC to use a more lenient resolution on timestamp differences. This can be achieved by setting CCC's global "NASTimestampLeniency" attribute. This is an advanced global configuration option that can be set using CCC's command-line utility, e.g. in the Terminal application:
"/Applications/Carbon Copy Cloner.app/Contents/MacOS/ccc" -g NASTimestampLeniency int 3601
With that setting, CCC won't recopy a file if its modification date is less than an hour (and one second) within the modification date of the same file on the destination. Note that a difference in the file's size will have precedence. Also, while this is a global setting, it only applies to tasks that have a non-HFS and non-APFS source or destination. If you have a bootable backup task, this setting would not be applied.