Clone larger than source, after erase/copy.

[dnanian]

It's happening to everyone that's copying file-by-file from what we can tell. It's hard to notice, though, which is why we didn't catch it.

It's not really a concern. When we figure out a way to fix it, you'll simply get back space on your backup.

Some data in /Applications, /Library and /System is being copied each time we back up. We think it has to do with prebinding: modification dates are changing on the backup drive. Still researching.

[MacCetera]

Originally Posted by mikebore

Main questions are:

1. Is it happening to everyone using Superduper, CCC and Chronosync? or only some people. I would have expected it to be more widely reported.

As an experiment this morning, I ran the latest CCC (3.3b3) and did Mike's equivalent of a smart update of my boot 10.6 drive to my identical SD clone, and there was a similar 3.2 GB discrepancy over approx. 240 GB of files.

This supports thinking the root problem is a change in the function of the API's under Snow Leopard.

I'm going to try a nuke-n-pave of the clone with both SD and CCC today and see if the results yield any other details.

-- Marc

[dnanian]

Don't nuke and pave. Let us investigate this, Marc... seriously. We have seen some clues about what's going on. Wiping your own system is just going to take your time unnecessarily.

[MacCetera]

Originally Posted by dnanian

Don't nuke and pave. Let us investigate this, Marc... seriously. We have seen some clues about what's going on. Wiping your own system is just going to take your time unnecessarily.

Oh well... I erased the clone, and started a CCC run... then left to pick up my daughter. I was hoping that CCC would attempt a block copy, but it's flying along with a file-based copy - currently about 65 of my 240 GB done at 40 minutes.

I'm expecting to see the same bloated results, and taking your advice will leave it be (with the exception of probably running a SD smart update just to make sure my scheduled run at 1 am tonight doesn't bail).

FWIW, I enjoy this sort of stuff... empirical knowledge has value

-- Marc

...and some time later:

1. The file-based CCC copy was larger than the source - in a comparable range to the SD differences.
2. The SD smart updated backup schedule for this pair had to be recreated because erasing the target volume in DU prior to the CCC test yielded a new UUID for the volume, which naturally didn't pass the SD sniff-test.
3. After recreating the backup schedule, SD ran through the CCC-created copy like it was its own.