I received word that a update will come likely tomorrow for CCC.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Carbon Copy Cloner 7 - Users Thread
- Thread starter Realityck
- Start date
- Sort by reaction score
CCC 6.1.1-b2 now available if you have beta downloads enabled.
- Fixed
Fixed a cosmetic accounting issue that was making it look like more files were re-verified than were copied. - Changed
macOS 12.3 introduced a problem that causes Legacy Bootable Copies of the system to fail on Apple Silicon Macs. In earlier beta builds of 12.3, that failure rendered the destination unmountable. In the final release of 12.3, that failure is now innocuous. CCC now ignores the error and completes the task.
Since this was a last moment fix by Apple, checking to see if its only against the public release build (21E230) versus the 12.3RC which has the same build (21E230)
Last edited:
So it's established that this problem was changed on the 12.3RC issue, so both that and public are the same.
CCC 6.1.1-b3 now available if you have beta downloads enabled to test with.
CCC 6.1.1-b3 now available if you have beta downloads enabled to test with.
Last edited:
I had a chance to test CCC 6.1.1-b3 with 12.3, this version with some programing changes, did work the first time making a legacy bootable copy method using 12.3RC using a M1 Mac.
If you are using any version before this one with newly released Mac OS 12.3, I would update to this latest beta.
If you are using any version before this one with newly released Mac OS 12.3, I would update to this latest beta.
CCC 6.1.1 is available
- Fixed
Fixed an exception that was causing tasks to fail with no clear reason when a task was configured with a remote Mac source or destination, and the specification for that remote Mac was missing a "volume name" attribute. - Changed
macOS 12.3 introduced a problem that causes Legacy Bootable Copies of the system to fail on Apple Silicon Macs. In earlier beta builds of 12.3, that failure rendered the destination unmountable. In the final release of 12.3, that failure is now innocuous. CCC now ignores the error and completes the task. Please note that we still recommend using this procedure only when making a copy of the system that you intend to use immediately (e.g. when migrating to a new disk, or setting up a sandbox test system). A CCC "Standard Backup" provides a more comprehensive strategy for regularly-updated backups. - Changed
Fixed a cosmetic accounting issue that was making it look like more files were re-verified than were copied. Also fixed an errant subtask timeout that was occurring during postflight verification.
OS 12.3, 2017 iMac, CCC 6.1.1 (updated today).
I've been away from home for a week or so. While away I received email from CCC telling me that a back-up task had failed because the destination volume (APFS) was not writeable. I have successfully made weekly CCC backups to that volume since 2020, so this surprised me.
It turns out I'm not smart enough to fix this.
What do I do?
I've been away from home for a week or so. While away I received email from CCC telling me that a back-up task had failed because the destination volume (APFS) was not writeable. I have successfully made weekly CCC backups to that volume since 2020, so this surprised me.
It turns out I'm not smart enough to fix this.
What do I do?
Is this destination volume SSD or HDD? Use Disk Utility (utilities) -> First Aid, select the volume which is two parts (example Macintosh HD, Data), check for errors with each. You just updated to CCC 6.1.1 yesterday, did you update to 12.3 before that? If so try running it again.
It turns out to be a long and time consuming story.
Mike Bombich was kind enough to send detailed instructions (delete the System volume) on what to do. Unfortunately, and, as predicted, I was too stupid to follow his instructions to the letter and inadvertently deleted the Data volume instead of the System volume. So, I had to erase the entire volume and start over again. This is an external spinning drive.
I tried another CCC backup, but this time CCC reported errors on the source drive (the iMac internal drive). It turns out that the error was on a single subdirectory. I deleted that from the internal drive (it was an ancient iCloud Messages backup) and then booted into recovery mode. I ran First Aid on both volumes in the volume group. First Aid found no errors.
That's it.
Mike Bombich was kind enough to send detailed instructions (delete the System volume) on what to do. Unfortunately, and, as predicted, I was too stupid to follow his instructions to the letter and inadvertently deleted the Data volume instead of the System volume. So, I had to erase the entire volume and start over again. This is an external spinning drive.
I tried another CCC backup, but this time CCC reported errors on the source drive (the iMac internal drive). It turns out that the error was on a single subdirectory. I deleted that from the internal drive (it was an ancient iCloud Messages backup) and then booted into recovery mode. I ran First Aid on both volumes in the volume group. First Aid found no errors.
That's it.
CCC 6.1.1 (build 7323) released to replace (build 7316)
Couple of additional changes.
Couple of additional changes.
- Changed
Build 7323: CCC will no longer issue an error about failing to delete transaction records when deleting task events associated with a task that was already deleted. - Fixed
Build 7323: Fixed the handling of an error condition when the destination filesystem fails to create a folder (typically affecting NAS destinations, and typically when the folder name was not accepted by the NAS).
I'm both glad and sad I found this thread. Glad because it helped answer some questions from someone who upgraded from being on Mojave to Monterey last night and not knowing why my clone to a new drive wasn't showing as bootable, but very sad to know that- from what I'm understanding- I can no longer do a simple clone / incremental clone of my hard drive at any point or update like it is in Mojave and it's bootable. Now if I want a bootable clone and there's been any system updates, I have to wipe the drive each time.
That's heartbreaking to hear, and breaks my backup method I use. I have a single volume 1 TB hard drive with a bootable copy of 10.14, and my other drives pointed to it as well separated at root-level, so the different jobs don't erase the other tasks. If I'm understanding correctly, that is no longer possible, unless I try to partition my backup drive now into different volumes, or will a that screw it up as well? So confused...
Some people are saying SuperDuper doesn't have this problem, is that true?
That's heartbreaking to hear, and breaks my backup method I use. I have a single volume 1 TB hard drive with a bootable copy of 10.14, and my other drives pointed to it as well separated at root-level, so the different jobs don't erase the other tasks. If I'm understanding correctly, that is no longer possible, unless I try to partition my backup drive now into different volumes, or will a that screw it up as well? So confused...
Some people are saying SuperDuper doesn't have this problem, is that true?
Now do an update to the Monterey clone. After I did that, the clone was no longer bootable.
It’s not suppose to be a clone you can update the system on, it’s a one time APFS replication of a source.
Every time I update the source MacOS volume it requires a complete legacy bootable copy which means you work with a erased backup volume that is the target.
You then can do standard incremental backups until you need to go to a newer MacOS with 12.x
No. His blog doesn’t detail at all the fact that Apple only sorta fixed the issue on 12.3RC and the later two public releases, and it was broken on all the betas of 12.3. It still is not completely fixed by Apple, both developers worked around this issue in similar manner.
Super duper! is the same.
The difference is that Dave Nanian of SD presents SD as fully capable of making bootable clones, and makes light of the need to erase System Volume after macOS update.
While Mike Bombich of CCC is strongly pushing Data-volume only clones and made this the default.... and has relegated the bootable clone option (LBBA) to semi hidden.
Personally I agree with Mike Bombich. I don't have a need to reboot within five minutes of a problem, and anyway booting form clones plays havoc with some apps like BackBlaze and CrashPlan. When I need a clone I can take the extra 30 minutes to reinstall and migrate.
In earlier versions (up to mid Big Sur) i always created a dmg of my whole Mac after significant changes.
This way I had a hassle-free possibility to revert to an older state.
This used to include Data partition as well as the macOS partition.
Is there a way in current versions to backup Data and OS to a dmg and recover these to a clean or disk?
In newer versions, even if I use an old backup that has Data and OS it always deletes the macOS partition on the target disk so I have to do a time-consuming re-install of macOS to the target??
edit: I know a legacy clone includes Data and system, but I explicitly mean the same functionality but for dmg archiving purposes.
Thanks!
This way I had a hassle-free possibility to revert to an older state.
This used to include Data partition as well as the macOS partition.
Is there a way in current versions to backup Data and OS to a dmg and recover these to a clean or disk?
In newer versions, even if I use an old backup that has Data and OS it always deletes the macOS partition on the target disk so I have to do a time-consuming re-install of macOS to the target??
edit: I know a legacy clone includes Data and system, but I explicitly mean the same functionality but for dmg archiving purposes.
Thanks!
Last edited:
Thanks, that's too bad but at least it seems I'm not missing something essential.
So I really appreciate your post!
Last edited:
Yes as of
Yes the days of incremental bootable backups ceased with Big Sur versions at times. You can see it mentioned in the blog
Everything was dandy up thru Catalina, Monterey introduced more issues as Apple broke ASR again. 12.3 changed it again, hence the 6.1.1 version. The Bless utility issues relate to container corruption failures that occur when ASR tries to replicate the Preboot or Recovery volumes. Consider that just bandaged, not fixed.
Hi, from curiosity: what exactly makes a clone un-bootable after an ordinary incremental DATA backup?Yes as of
Yes the days of incremental bootable backups ceased with Big Sur versions at times. You can see it mentioned in the blog
Everything was dandy up thru Catalina, Monterey introduced more issues as Apple broke ASR again. 12.3 changed it again, hence the 6.1.1 version. The Bless utility issues relate to container corruption failures that occur when ASR tries to replicate the Preboot or Recovery volumes. Consider that just bandaged, not fixed.
;JOOP!
incremetal DATA volume only clones still work. The Q was about putting System and Data on an image. No longer possible since Apple made so that the only way of clone the System vol is with ASR.
Last edited:
Sorry, I was NOT referring to the image question,
rephrased: if an ordinary incremental backup can not 'touch' the system partition,
how could it ever make a clone un-bootable?
Or, as the only way to backup the System partition is a full ASR clone, erasing the target,
then, how could anyone ever end up with an un-bootable target?
;JOOP!