by Mike | September 3, 2014

Finally! We're ready to open the CCC beta testing gates!

I know, you all have been waiting forever for this, right? You probably think we're taking our sweet time getting CCC qualified on Apple's next OS, but I want to assure you that that couldn't be further from the truth. Apple has finally resolved a showstopper bug with the release of a seventh developer preview, and now we're ready to open up our own beta testing program. I'm sorry it took this long, but that's the nature of beta OS releases -- they have bugs!

We're testing more than just an update for Apple's next OS, though. Our team has spent the last 18 months tearing CCC down to studs and completely rebuilding it. I'm very proud to announce the next major version of CCC: Carbon Copy Cloner 4. The complete list of changes could fill a book, the really long list that I've included below is just the big stuff.

New CCC 4 Interface

What's New in Carbon Copy Cloner 4

  • The main task configuration window and the scheduled tasks window have been consolidated. Tasks can be saved, scheduled, and edited, all in the same window.
  • Configuring a backup task is far simpler -- complex settings are hidden by default, but accessible at the click of a button.
  • Menubar application for quick access to information about CCC backup tasks
    • Current task progress
    • Last run status
    • Last run and next run dates
    • The ability to open CCC to a specific task
    • Start and stop tasks
    • Defer a task that is currently running
    • Unobtrusively indicates when errors have occurred in a backup task
    • Menubar icon indicates whether a task is running, and a simple icon next to each task indicates progress.
  • Tasks can be chained together to form more complex backup routines
  • New runtime conditions offer more control over when and how scheduled tasks run:
    • Run only on week days or only on weekend days
    • Wait for another task to finish if that other task is writing to the same destination
    • By default tasks will not start if a laptop is running on battery power, and the task will start as soon as AC power is restored
  • A Task History window indicates when a task ran and whether it was successful. All history events are listed in one window, and can be sorted by task name, source/destination name, start time, and status.
  • Email account settings are now specified in CCC's preferences. Test email notifications are now much more proactive about reporting configuration errors.
  • Customizable email templates
  • Simplified interface for customizing filters. Filters are now explicitly retained per-task, and can... Read More
by Mike | June 4, 2014

Will CCC work with [insert Apple's pre-release OS here]?

Every time Apple makes a new operating system available to developers, we spend several weeks evaluating CCC on that new OS. We look for changes to the features and behavior of the HFS+ filesystem, how the new OS supports (or fails to support) network filesystems, changes to the boot process, changes to support for USB, Firewire, and Thunderbolt -- and a bunch of other things. If nothing has changed and no problems are encountered, the process takes a couple weeks. Realistically, it takes at least three weeks to complete qualification, and in the worst case scenario (e.g. Snow Leopard and Lion), it takes several months to fix problems or add support for new OS and filesystem features. It's a lot of work -- a lot more than the average developer would face when a new OS is released because our software relies so heavily on filesystem functionality and operating system behavior (especially stuff that is poorly documented or not documented at all, like the Recovery HD). We clone the OS, and when Apple ships a new OS, we'd better be doing that correctly.

Because the qualification process consumes so much of our time, we approach it in two phases:

  • Evaluate functionality on the Developer Preview. Identify major problems and develop a strategy and timeline to resolve them. As problems are addressed, we may post betas for external evaluation.
  • When the GM is announced and delivered to developers, we complete final qualification. Our final product is ready when the "Golden Master" is made available to customers on the AppStore.

It would be foolish for us to complete a thorough qualification on the Developer Preview because a) the Developer Preview is usually quite buggy and Apple's bugs waste my time and b) qualification on the Developer Preview has no relevance to the final product -- we would have to repeat qualification as soon as the Golden Master is posted. Based on experience with past OS X releases, cloning software should not be used to clone new OSes until it has actually been tested on the new OS. While that seems like a common-sense statement, it's apparently not a common practice. That's our policy, though, and that's why you get a dialog that says CCC isn't qualified on Yosemite.

Last year, I had time set aside to produce a beta that would work on Mavericks shortly after the Developer Preview was made available. The announcement of Mavericks was highly anticipated, so I could budget my time really well. This year, Yosemite came with less warning. As a result, I'm in the middle of other work that can't be set aside to start Yosemite evaluation. I plan to start evaluating Yosemite in a few weeks, though, and I hope to provide a beta once any surprises are sorted out.

For every major release of OS X since 10.3, we have had a qualified version of CCC ready the moment that Apple shipped the new... Read More

by Mike | January 24, 2014

Carbon Copy Cloner has two different methods of providing progress indication, "fast" and "more accurate". "Perfectly smooth progress indication every time" is what many people want, along with an estimate of how long the task will take, but they often don't realize the cost to achieve that for a backup task that copies only items that have changed since a previous backup task.


If you don't deselect anything from CCC's list of items to be copied, CCC will start copying files immediately. Because CCC has no idea how much data will have to be copied to the destination, it bases progress indication on the number of files that have been processed vs. the number of files reported to exist on the source volume. If you have several really, really large files, progress indication may appear a bit uneven -- the progress bar will move steadily as CCC processes smaller files, but will move very slowly when large files are encountered. People generally want CCC to start copying right away, though, because it's faster to do it that way, and people are impatient.

More accurate

If you have excluded any items from the list of items to be copied, the total number of files on the source volume (which is easy to obtain very quickly) is no longer an accurate measure of how many files will be considered in the backup task. CCC will pre-scan the source volume to get an exact list of the items will be considered for copying. With this list in hand, CCC knows exactly how much data is in the data set that you're copying. With this information, CCC can now provide progress indication based on the amount of data that has already been considered vs. the total data in the data set. This method has its drawbacks as well, if you have several really, really large files that CCC decides are already up to date, the progress bar will jump ahead quite a bit when those files are considered.

Perfectly Smooth Progress Indication Every Time

The only way to achieve perfectly smooth progress indication, and to provide a "time remaining" estimate would be to pre-scan the source and the destination and compare those lists of files to determine not only how much data is in the data set, but also to determine which files are already up to date and which files will need to be copied. This would give a third data point, "total data that needs to be copied", and CCC could use that to determine progress. I have thus far decided against implementing this kind of progress indication because it is impractical. The goal of running CCC is to get your stuff backed up and to do so with as little effect to your productivity as possible. The amount of time that it would take to basically do a dry run of the backup is a significant portion of the time that it would take to actually do the backup (for times that you are updating an existing backup). I don't think I've ever drawn up these numbers before, so I decided to do that this morning.... Read More