All Posts by Date or last 15, 30, 90 or 180 days.

As an Amazon Associate I earn from qualifying purchases @AMAZON

Designed for the most demanding needs of photographers and videographers.
Connect and charge all of your devices through a single Thunderbolt or USB-C port.

Carbon Copy Cloner 3.3.3 Cautionary Advice When Cloning to a Larger Volume

Update 7/18/2010 — My original post follows verbatim further below (excepting the title). The facts I stated have not changed, but there is an explanation. I was contacted by a very concerned Mike Bombich, author of Carbon Copy Cloner, and I believe I now understand what happened.

All my past cloning for backup purposes has been from a 3TB volume(with 1.8TB of data) to a 2TB volume. In that case, CCC always does an incremental clone, exactly what I want. This saves considerable time, since only changed items are copied.

But with the 6TB volume, CCC chose to do a block-level clone this particular time (explanation below). That means wiping out the target volume and recopying the entire source volume, or at least all 1.8TB of data on it. For me at least, that totally defeats the purpose of using CCC for backup.

CCC does issue a "may delete files and folders" warning, which I understood/understand to mean files and folders that no longer exist on the source volume, not all files and folders.

The fine print at the bottom of the main window that states “What will happen” is contradictory; it’s an either/or, so the user can’t know what will really happen. I took it to mean “will be efficiently updated”, since that’s what had always happened for me before.

In my case, a particular detail contributed: CCC was able to unmount the source volume, and thus was able to wipe out the target volume in preparation for a block-level clone. This caused software I had running (Dropbox) to immediately complain, which startled me, which is why I then clicked Stop. At that point, I had no backup left, since it had just been wiped out. That seemed Bad.

Retesting today showed totally different behavior. The difference? Today I had files open on the source volume (as I almost always do), so that CCC could not unmount it. So CCC thus chose to perform a file-level incremental clone, which is what I wanted all along.

User interface suggestions

This non-deterministic behavior is confusing, and needs to be addressed in the user interface. The user should know exactly what will happen, since the behavior could change unpredictably, depending on current system status (eg apps running with open files, or not).

The fine-print at the bottom of the window should be eliminated; it is long and confusing at best, and ambiguous as to what will actually happen.

In the case of a full erase and copy, the user should be told explicitly that the volume will be erased, and this should be confirmed with a dialog eg “The entire target volume Backup will be erased and the entire contents of the source volume Master will be copied to it. OK | Cancel” .

Something like that. If this had been in place, I would never have proceeded with the clone. As it was, it turned a 10 minute quick update into a 5 hour backup.

 

Original post follows...

-------------------------

Update! I cloned my Master volume to a 2TB backup drive— different and correct behavior (no “Initiating system restore...” nonsense). All worked well. So it appears that either the volume size is at issue (6TB vs 2TB), or there is something about the device itself (both devices used the same PCIe eSATA card, a FirmTek SeriTek 2ME4-E).

This morning, I turned on my OWC QX2 for a weekly backup. There it was, safe and sound on my Desktop. I have my QX2 set up as a 6TB volume (4 X 2TB drives as RAID 5). To the Mac, it just looks like one 6TB drive.

The last time I backed up to to the QX2, Carbon Copy Cloner also had a problem, but I wrote it off as a fluke (I did a Finder-copy backup instead). But this time, I thought that since an incremental backup would be much faster (just changed files), I decided to use cloning. CCC offered to install its latest update, so I did so. I don’t know if that is related or not. Since it misbehaved last week also, I don’t think it’s necessarily version 3.3.3 that’s the issue.

Not wanting to copy 1.8TB again, I decided to give CCC a fresh chance:

  1. Initiate the clone: Master => 2010-0717.
  2. CCC gives its usual warning, then I notice that it says “Initiating system restore...”. This sounds pretty scary— it’s not what I usually see when I clone. I do NOT want to restore my system! Maybe it’s an erroneous message, but I don’t remember getting that message for other clones.
  3. Dropbox software now complains that its folder is missing (which is on the source volume to be backed-up). Now I’m getting really nervous. I don’t want the source volume screwed with.
  4. CCC is apparently stuck doing nothing, so I click "Stop".
  5. My backup volume vanishes from the desktop.
  6. Because the backup volume had vanished, I reboot, and my backup drive is now toast—Disk Utility shows that the volume is just gone. My Master drive (the one I was backing up) seems to be OK, but I’m feeling very concerned, to say the least.
My backup drive, after a Carbon Copy Cloner attempt

I’ve had plenty of success using Carbon Copy Cloner many other times (on smaller volumes).

I might try using SuperDuper to see if it has a similar issue, which could be the case if it were a volume capacity issue. Perhaps CCC has an issue with large volumes? My QX2 backup volume was/is 6TB.

The QX2, as seen in Disk Utility

Bottom line

One reason I use Finder-copy for backups is to avoid scenarios like this. More software = more problems; no software ever written is ever problem-free. The Finder has bugs too of course, but I’ve not had it fail me copying files to local drives.

View all handpicked deals...

Sony WH-1000XM5 Noise-Canceling Wireless Over-Ear Headphones (Black)
$398 $328
SAVE $70

diglloyd.com | Terms of Use | PRIVACY POLICY
Contact | About Lloyd Chambers | Consulting | Photo Tours
Mailing Lists | RSS Feeds | X.com/diglloyd
Copyright © 2020 diglloyd Inc, all rights reserved.
Display info: __RETINA_INFO_STATUS__