CCC doesn't copy virtual memory or the Trash
There are a couple legitimate explanations for a mismatch between the capacities reported in Disk Utility. First, some system files and folders are excluded from a backup task either because they are regenerated every time your machine reboots, or they are not appropriate to back up or because they won't work properly on another hard drive or computer. The largest and most notable excluded item is the /private/var/vm/sleepimage file. The sleepimage file contains the live state of your Mac's RAM, so it will be as large as the amount of RAM that you have installed. Considering that the amount of RAM pre-installed is only increasing, and that this file changes constantly and gets recreated on startup, CCC excludes this file from your backup task.
CCC also excludes the contents of the Trash, so you may want to empty the Trash, then compare again the source and destination. An exhaustive list of the items that CCC excludes is included in the CCC Help section labeled "Some files and folders are automatically excluded from a backup task".
If your source volume is the startup disk, the Size of Trash and VM application will quickly tell you exactly how much data is in these folders that CCC is excluding. In most cases, this explains all of the discrepancy that users notice during an initial backup task.
The sum of all your files may never match the disk usage value reported by Disk Utility
While the exclusion of these items explains much of the disk capacity discrepancy you may discover in Disk Utility, it does not explain it all. A user suggested the following scenario after cloning his entire source to his destination drive:
Boot drive - 39.67 GB used Backup drive - 38.55 GB used
Should I be concerned there's more than a GB missing? Could this be a swap file or something? Is there an easy way to isolate what files are not on both?
One GB seems like a lot, but it's not surprising, not for 40GB used (the discrepancy increases with the amount of data on your boot volume). Discrepancies like this are not uncommon when you're booted from the source or (subsequently) the destination.
The issue is that Disk Utility (and Finder Get Info for the volume) is misleading. The value that Disk Utility reports is indeed the amount of space consumed on your hard drive, however, it is not the amount of space consumed on the drive by all the files and folders that you can see. And I'm not referring to the other files as simply "invisible", these other files and directories that make up the rest of the space you're "missing" are simply not presented to the operating system. These items are filesystem implementation details, and it isn't possible to copy them directly with file-level copying tools.
Does this mean you're losing data? Absolutely not. It's pretty easy to prove it to yourself too, just boot from your cloned volume and take a look at the capacity reports in Disk Utility. Here's an example we performed on a test machine:
** Booted from the original source volume Source: 5,258,776,576 bytes Clone: 5,025,562,624 bytes
**Booted from the clone volume Source: 4,996,599,808 bytes Clone: 5,250,097,152 bytes
Disk Utility can't really be used as a good measure of success for your clone. That's not to say that what it reports is wrong, it simply isn't telling the whole story.
"Right, OK, but how can I tell that all of my data was actually copied?"
The numbers reported by Disk Utility and Finder for total disk usage on the source and destination are essentially irrelevant if they can't be meaningfully compared. What can be compared, however, is a basic enumeration of the files and folders on your source and destination volumes. The Volume Disk Usage Details tool can help you collect this kind of thorough enumeration. When this tool has completed collecting this enumeration for your source and destination volumes, you can compare the reports to find any discrepancies. You can use this tool to enumerate individual folders as well if you need to get more granular details about a discrepancy in a particular folder. Note: This utility has not been tested for use on network volumes. It can do no harm, but you may encounter permissions errors with items on network volumes, or it may simply report inaccurate values for those volumes. We recommend using this tool only on locally-attached volumes or mounted disk images.
If you find a discrepancy that you cannot explain, or that appears to be errant, please let us know and we'll help you get to the bottom of it.