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 Advanced Settings button.
- Check the Don't update newer files on the destination setting in the Troubleshooting box.
- Save and run your task.
Related Documentation
A time zone shift can affect modification dates on some filesystems
HFS+, APFS, 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 Mac-formatted volumes (or between Mac-formatted filesystems and a NAS device that uses local time for time stamps). 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.
Microsoft MSDN Library: File Times
Coping with the Daylight Saving Time shift with backups to and from the aforementioned filesystems
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 (despite the setting's name, it is not limited to NAS filesystems). If you have a bootable backup task, this setting would not be applied.
Mail's "Log Connection Activity" setting creates enormous files
If you enable "Log Connection Activity" in the Connection Doctor window in Mail and you forget to disable that setting, Mail will create enormous log files that will eventually fill up your startup disk. If you find that CCC is copying an unusually large amount of data during every backup, even backups run back-to-back, try the following to verify that this large amount of data is not related to Mail activity logs:
- Open Mail
- Choose "Connection Doctor" from the Window menu
- Uncheck the box next to "Log Connection Activity"
- In the Finder, hold down the Option key and choose "Library" from the Finder's Go menu
- Navigate to Library > Containers > com.apple.mail > Data > Library > Logs > Mail
- Delete the large log files