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 every backup task.
CCC doesn't copy virtual memory or the Trash
CCC also excludes the contents of the Trash, so you may want to empty the Trash, then compare again the source and destination. The complete list of items that CCC excludes from every backup task is documented here: 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 see in Disk Utility, it does not explain it all. A 1-3GB discrepancy is not uncommon when you're booted from the source or (subsequently) the destination. The problem is that the disk usage value that is reported by Disk Utility (and Finder Get Info for the volume) is a bit misleading. The value that Disk Utility reports is the amount of space consumed on the volume as reported by the HFS+ filesystem. It is not, however, the amount of space consumed on the drive by all the files and folders that can be seen by the OS and applications. There are other filesystem "implementation details" that consume space on the volume, but cannot be seen by the OS and cannot, and should not, be copied by any application.
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.
"So how can I tell that all of my data was actually copied?"
A basic enumeration of the files and folders on your source and destination volumes will give you meaningful numbers to compare. The Volume Disk Usage Details tool can help you collect this kind of enumeration. When this tool has completed scanning the 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.