OK I misunderstood...AFAIK an incremental update of the data volume won't make a bootable clone unbootable.
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
Sciuriware
macrumors 6502a
arw
macrumors 65816
Recovering/updating the data volume from an image to a bootable clone‘s data partition additionally deletes the target‘s system partition (since CCC version 6.0.5 afaik).
In my eyes this is totally unnecessary.
CCC only keeps the system partition, when you are actually booted from said partition during recovery from an image.
So simply updating the data partition of an external disk (clone, whatever) from a dmg, always deletes its system, rendering it un-bootable.
It‘s designed to be like that although it means a huge additional effort to re-install the OS after each recovery (and SSD-wear).
Last edited:
Learning about the legacy erase/clone option in order to make a bootable copy, I did this procedure yesterday to a SSD drive. It completed, was shown as bootable in startup disk, and upon selecting and restarting started to boot. However, a little under halfway through the book progress line it stalled, then rebooted. The Apple logo disappeared, the loading progress line showed up, but froze at the same point and stayed there for at least 10 minutes. It was at that point I hard shut down the boot and gave up.
Was that a CCC issue, a Monterey issue, or what?
I gave up on the main Mac Mini SSD running Mont and clone restored back to Mojave because of the transfer speed issues with my USB3 NVME enclosure (which only started with Mont).
This transfer speed/video buffering/Chrome cache loading delay issue that's part of Mont is a deal breaker for me unless someone knows how to fix it (I don't know if it could be present in Cat or Sur because I haven't used those OSs). I feel I'm force stuck on Mojave.
Was that a CCC issue, a Monterey issue, or what?
I gave up on the main Mac Mini SSD running Mont and clone restored back to Mojave because of the transfer speed issues with my USB3 NVME enclosure (which only started with Mont).
This transfer speed/video buffering/Chrome cache loading delay issue that's part of Mont is a deal breaker for me unless someone knows how to fix it (I don't know if it could be present in Cat or Sur because I haven't used those OSs). I feel I'm force stuck on Mojave.
If that happens just make a new legacy bootable clone, otherwise you can still use this snapshot for Migration Assistant to restore a MacOS environment if something happens. Yes Monterey ASR process is not fixed yet. Thats Apple's problem to resolve.
There are some confuion here. CCC makes perfect bootable clones on any macOS version, including on Silicon macs.
That´s all.
Also I can tell you that boot on a cloned Monerey by USB often does NOT work. Maybe a big part o the confusion is here. You have to use an Thunderbolt port, or an ESATA adapter connected to it.
Anyway, as you know, Apple NEVER supported oficially boot by USB, though always have worked.
For instance, a CCC clone of monterey connected to a Thunderbolt port on my Macbook Pro 2019, using an USB adapter, does not work, hangs. Same clone connected to an ESATA adapter, boots fast without any problem.
That´s all.
Also I can tell you that boot on a cloned Monerey by USB often does NOT work. Maybe a big part o the confusion is here. You have to use an Thunderbolt port, or an ESATA adapter connected to it.
Anyway, as you know, Apple NEVER supported oficially boot by USB, though always have worked.
For instance, a CCC clone of monterey connected to a Thunderbolt port on my Macbook Pro 2019, using an USB adapter, does not work, hangs. Same clone connected to an ESATA adapter, boots fast without any problem.
Last edited:
When I first said 12.3 beta broke ASR, believe it. 12.3RC Apple sorta made work again, but both developers had to workaround this corrupt volume issue with Bless Utility. Perhaps if you beta test you would experience the joy of getting something fixed by the time it’s issued to the public. 😀
Sciuriware
macrumors 6502a
So, USB does not work? Well, all my backup disks are USB disks, so why bother about bootability at all .....
IF I ever must boot from those, how will I accomplish that; I did not get it from the above messages.
;JOOP!
It is working for me from 12.3 RC onward. (12.3, 12.3.1) I use some older USB based HDD storage for snapshots during beta testing. 😉
Sciuriware
macrumors 6502a
Great; I deploy 5¼' sized WD disks of 1Tb and 2Tb; easy: they do not need other than USB power.
Would be a drag if those were useless for reboot.
And 12.3 ... I'm saving money for a brand new Mac Studio this summer, so ......
Thanks for the quick answer.
;JOOP!
CCC 6.1.2-b1 now available if you have beta downloads enabled.
- Changed
Fixed the window location of the Dashboard window when multiple screens are present. The Dashboard window will now be presented next to the menubar icon that was clicked, rather than retaining its previous window position. - Changed
The minimum data threshold for "When files are modified on the source" tasks is now 1MB (i.e. 0.001GB). - Changed
Addressed an issue specific to macOS Catalina in which a verification of files on the source or destination would errantly report System volume files as missing. - Changed
Resolved a latency issue that a handful of users were noticing when switching between tasks. We tracked the latency down to poor performance of Apple's "nsattributedstringagent" service on macOS Monterey. In some cases the service was crashing repeatedly, and when macOS throttled its relaunch, there would be a noticeable delay when CCC attempted to render the Task Plan. We no longer rely on that macOS service for rendering the Task Plan. - Changed
Fixed a couple cases where the background color of a view was not switching automatically when the system appearance was changed in System Preferences (e.g. Dark to Light). - Fixed
Corrected the error handling in cases where unreadable folders are encountered on the source. - Changed
Corrected the presentation of dropped OneDrive placeholder files for pre-Monterey users. - Changed
Addressed a race condition that could occur if two tasks try to simultaneously mount the same NAS volume. One task would "win", the other task would wait indefinitely for the system's NetAuthSysAgent service to reply.
Fallinangel
macrumors regular
If the CCC boot image were not boot-able, would that entail that you wouldn't be able to restore your corrupt boot volume with disk utility, by simply wiping the latter and copying (or mirroring) the backup volume over?
Nop, you can install macOS and at the end import the accounts ferom the clone with Migration Assistant. But with bootable clone the operation take few minutes.
Fallinangel
macrumors regular
Sad? I say again: bootable clones woerks like a charm in every and each mac an any Os X or macOS.
Fallinangel
macrumors regular
Yes, but since CCC allegedly can't do bootable ones on Monterey and Apple Silicon, it's sad. 😉
Are you being funny after I said it worked on M1 macs using 12.4 beta 2?
Fallinangel
macrumors regular
I must have missed that. Thanks for pointing it out again.
Do I get this right that the legacy procedure in CCC let's you do bootable clones, but it needs to erase the entire backup and start from scratch after each macOS update to make it work, and you need to manually prompt it to do it?
Are incremental backups thus only possible between system backups?
Is the standard procedure nowadays to simply make a non-legacy, non-bootable clone, re-install macOS, and then use Migration Assistant to copy relevant files over?
I still prefer to restore an exact copy. I mean there's no guarantee that Migration Assistant doesn't miss something and it's probably rather slow because it needs to compare each and every file, whereas copying can be rather fast with thunderbolt 3 or 4 at least... This might be sad after all? 🙂
jasnw
macrumors 65816
From the direction Apple appears to be heading, I am thinking that now is the time to start rethinking backup strategy, as Mike B. has suggested. I've always backed up to bootable clones, but with Apple clearly wanting the user (as in the person who owns the #@!%%#@ computer) doing anything OS-related it seems this isn't a hill worth dying on. I'll continue using CCC, but will work on learning how to recover the OS using Apple's procedures when either it or the media it's on goes kaput.