When I had to choose between SD and CCC, Leopard had just come out and I had finally had my fill of Retrospect as a backup solution. Time Machine had passed all my initial tests with flying colors, but I wanted to have another backup solution that would make bootable clones. (I was also a little nervous about TM's predilection for backing up a running system. I don't trust digital backups of data that's being modified, and OS X is always modifying stuff in the background.)
At that time, CCC had been upgraded to work with Lion but SD's Leopard-compatible version was noticeably late out of the gate. Still, I went to both sites, read what they had to say, and checked all the reviews. Here's what I saw:
SD does a file-level backup. CCC will do either a sector-level backup or a file-level backup. In the many cases where I've ever had to actually use a backup to restore from, the problem was almost always in the disk catalog, not in the physical media. A sector-level backup will copy catalog corruption, often even before you realize it's corrupted. In my opinion, sector-level copies have no place in a robust backup solution. CCC provided a checkbox to force a sector-level copy, but no option to forbid one! One point for SD.
CCC was just a GUI front end to unix command-line tools that did the actual copying. I actually have experience writing backup software for mainframes, and I've learned the hard way that scripting low-level routines to do your work is deucedly difficult. It's easy to do if you're willing to assume that nothing will go wrong, but nearly impossible if you need to handle errors. The extra layer of indirection means you can't really put your finger on the error, and can't really recover. Sometimes, if you want the job done right, you have to do it yourself.
CCC in particular uses rsync to do its file-level copying. rsync is a nice tool, but it has one glaring deficiency: it does not handle errors gracefully. If it cannot copy a file, it quits. Right then and there. To recover, you would have to figure out which file failed to copy, and then submit an amended request to copy the rest. But an amended request cannot deal properly with hard-links: rsync will notice if two of the files it needs to copy are hard-linked, and will optionally hard-link them in the output, but only if they're both being copied by the same call to rsync. If one of the files was copied in the initial request, and the other only gets copied in the amended request, rsync won't detect the hard-link. Unless the amended copy-list includes all the files already copied, in which case rsync squanders a lot of time re-examining already-copied files. (Did I mention that trying to pass work on to lower-level utilities quickly gets very messy if you're trying to do it right?)
SD, on the other hand, does its own copying. My experience tells me that's the only reliable way to do it. Score another point for SD.
I read the blog on the Shirt Pocket site, where the programmer was documenting why SD was so slow to be updated for Leopard, and liked what I saw. He was concerned with getting all the edge cases exactly right. It was clear that he was holding back the release until it correctly handled even obscure cases that CCC was simply sweeping under the rug. One of those edge cases was correctly cloning a TM backup, something that CCC still won't do correctly. At the time, CCC wasn't even correctly copying xattrs. SD wanted to handle xattrs, ACLs, hard links (even to directories), TM backups (which rely heavily on all of those), and do all that while still recovering from errors. Score another point for SD.
So, I waited patiently for the Leopard-compatible release of SD, and immediately bought it to replace Retrospect. I've been very happy with it.
I've been told that CCC now handles ACLs and xattrs correctly, and reputedly handles hard-links too (but I suspect that's only if nothing goes wrong, for reasons given before). CCC still does not correctly copy TM backups.
Snow Leopard introduced extensive file compression techniques. SD had to come out with a patch to keep the files compressed in the backup. Decompression is done at a very low level in the HFS+ filesystem, and is normally completely transparent to "ordinary" tools like rsync, which see only the decompressed data. Since rsync does not support preserving compression, CCC will still de-compress compressed files during a file-level copy. (A sector-level copy will preserve compression, but I don't trust sector-level copies.)
On Snow Leopard and later, Finder can be used to clone TM backups, but it's still useful to have that feature in SD. (Case in point: I wanted to clone my TM backup for a talk I was doing on TM. I used Finder to clone it, but foolishly forgot to disable Spotlight on the destination, and they started fighting over control of the disk heads. I didn't notice until the drive overheated about 2/3 the way through the copy. I let the drive cool down, and then let SD finish the job.)
I also use SD to clone my install discs onto my offsite TM backups, making them "bootable", after a fashion: they boot into the OS X installer, which can restore from the TM backup on the same volume. Only SD will clone onto a volume that contains a TM backup without disturbing that backup. Another point in SD's favor.
