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
And the changes in 7.1.2:
This is the official qualification build of CCC for macOS 26 (Tahoe).
- CCC has a new "glass" icon that looks great on macOS Tahoe! Big thanks to our UI designer Enelia at Abacus Finch who was able to find a way to keep our beloved page curl with the new glass material.
- The CCC menubar icon can now be moved around in the menubar, or removed by holding down the Command key while dragging the icon. Removing it in this manner will sync with the "Show CCC's icon in the menubar" setting in CCC Settings Dashboard. Tahoe users: If you disable the CCC menubar icon via the new System Settings > Menu Bar > Allow in the Menu Bar interface, CCC cannot be aware of that setting. For the best experience, we recommend that you use the settings inside of CCC for controlling whether the CCC menubar icon is visible.
- The "Find and replace corrupted files on the destination" setting is now officially named "Backup Health Check".
- Removed the "Standard Copy" button; the name of this button was a misnomer. This button was only present when Quick Update was enabled on a task, and in those cases, running the task with the Quick Update setting is the "standard" way of running that task. The Standard Copy button was added as a way to suppress the Quick Update feature in an ad hoc manner. This button was not frequently used, and its presence with that particular name was leading to some unnecessary confusion and concern. In lieu of a separate button, you can now hold down the Option key while clicking the Start button if you would like to have CCC rescan the entire source and destination (i.e. suppress Quick Update). Additionally, you can hold down the Control key to perform an ad hoc Backup Health Check. The resulting behavior of the modifier key presses is reinforced by icons on the Start button that correspond to the Quick Update and Backup Health Check features, as well as customized tooltips that will appear when you hover your mouse over those buttons.
- Added a menu item to the Volumes sidebar contextual menu that offers to delete an APFS volume (e.g. if you accidentally added an extraneous volume via the Backup Volume Setup Assistant). Select the volume in the sidebar first, then right-click on the volume to get an option to delete it.
- Added yet another workaround for Apple's restriction on access to the current WiFi network name for the macOS Sequoia 15.6 update. CCC uses the WiFi network name only in support of the option to limit a scheduled task to running when the system is connected to a specific WiFi network.
- Improved the repopulation of extended attributes in cases where the "Don't support extended attributes" setting was disabled after initially populating the destination while the setting was enabled. In cases where this setting was initially enabled because the destination was a NAS volume, CCC will now proactively seek out absent resource fork and FinderInfo extended attributes on files that are otherwise unmodified if the task is subsequently configured to preserve extended attributes.
- Adding "/*" to the end of a search expression in a Task Audit will now show the content of a matching folder.
- Resolved an issue where CCC would fail to import tasks or restore the CCC application support folder if CCC's helper tool was not yet registered with macOS. CCC will now prompt to register the helper tool prior to importing tasks.
- Fixed a crasher that could occur if many, many tasks were started simultaneously (e.g. in response to a volume mount event).
- Fixed a logic issue that was causing some "Folder was deleted" audit transactions to get a "circle with plus" icon rather than the "circle with minus" icon. Addressed another issue that was leading to extraneous folder entries in an audit when those folders had not actually been modified.
- Orphaned compression attributes are dropped when transferring a file or dataless folder that does not have the associated "this file is compressed" flag (this part is not new). Addressed a logic issue that was causing files (or more commonly, no-longer-dataless folders) with these vestigial attributes to appear in the task audit every time the task is run, despite that the files were not actually getting modified.
- Addressed an issue in which CCC was prematurely aborting a task due to an apparent stall while collecting the attributes of files in a folder that had an exceptionally high file count (e.g. 100K).
- Fixed an issue that affected how sparse files are copied between volumes that have different optimal buffer sizes.
- Improved the experience of switching between Simple Mode and Standard Mode, especially when CCC's helper tool has not yet been registered with macOS.
- CCC will avoid auditing a Quick Update task if the destination NAS filesystem URL has only a DNS-suffix difference (e.g. smb://user@host vs. smb://user@host._smb._tcp.local are now treated as the same).
- CCC now verifies that the device ID of the "_CCC SafetyNet" folder matches the device ID of the destination volume. If that folder has been replaced with a symlink that points to some other volume (for example), CCC will abort the task. This change resolves the errors that would occur if the SafetyNet folder was on some other volume (e.g. because files cannot be moved across device boundaries, they would have to be copied, then deleted). CCC only moves content into the SafetyNet folder — copying and then deleting the content defeats the purpose of the SafetyNet feature.
- Fixed an issue in which the Backup Volume Setup Assistant would be unresponsive when opened via the button in the Backup Coach window.
- Fixed the collection of total snapshot disk usage for the source and destination popup menu charts.
- Fixed an issue where CCC was failing to create a new folder because the parent folder was locked on the destination.
- Corrected an issue that was leading to "Audit failure" messages in the Task Filter window when a previously-excluded folder had been replaced by a symbolic link. CCC never follows symbolic links, so having filter rules that descend from a symlink is invalid — these obsolete rules are now removed from the filter whenever the filter window is opened.
- Fileflags (e.g. hidden, locked) that can be preserved on the destination are now preserved by default when backing up to or from a NAS volume.
Hey guys,
A bit late to the party but on an older macpro5,1 and Monterey and simply want a bootable clone of my slower current Boot drive so I can carry on with a faster NVME blade. Being Monterey, CCC 6 is the supported version and believe the legacy option is the only way to do it. Can anyone confirm?
I saw some posts about reinstalling the OS and and pointing to a backup as another method. Just want the best way for a bootable clone to move forward with without having to reinstall and reconfigure all of my apps/settings.
Thanks,
Dave
A bit late to the party but on an older macpro5,1 and Monterey and simply want a bootable clone of my slower current Boot drive so I can carry on with a faster NVME blade. Being Monterey, CCC 6 is the supported version and believe the legacy option is the only way to do it. Can anyone confirm?
I saw some posts about reinstalling the OS and and pointing to a backup as another method. Just want the best way for a bootable clone to move forward with without having to reinstall and reconfigure all of my apps/settings.
Thanks,
Dave
Using the default standard CCC backup (which is of the -Data volume only) as the migration source after a reinstall ….which is the recommended CCC method of using a backup…. does NOT require reinstalling apps and settings. Every app and every tiny setting to macOS or Apps are restored, just as if booting from a bootable clone. Just takes a bit longer, but against that making a bootable clone and keeping it up to date is not as straightforward. This is why Mike Bombich made the Bootable method as legacy and the -Data volume only as default.
Can’t really answer your questions but if you go to their site they have a very good Q&A section. Also, if you contact them from the app you’ll get a quick response in the next 24 hr or so.
Thanks for the info guys. I decided to go for the legacy option just to see how it went. I was able to boot into my clone after moving the necessary EFI info over to it's EFI partition since I'm using Martin Lo's macpro5,1 opencore (v1.0.1). Everything seems fine.
Regarding updates, as far as I understand, Apple aren't offering updates to Monterey anymore and I don't plan on moving past Monterey at all.
Is there still a benefit to the preferred/default method of data only given my situation? If so, can someone condense the way to do so? I've read this thread but after 33 pages, brain turns to much. Just not sure of the order of things to do it the "proper" way... or maybe it's not required for someone like me that is staying on the last version of monterey and apparently won't get updates anymore.
Current state is successful bootable monterey clone (12.7.6).
Thanks,
Dave
Regarding updates, as far as I understand, Apple aren't offering updates to Monterey anymore and I don't plan on moving past Monterey at all.
Is there still a benefit to the preferred/default method of data only given my situation? If so, can someone condense the way to do so? I've read this thread but after 33 pages, brain turns to much. Just not sure of the order of things to do it the "proper" way... or maybe it's not required for someone like me that is staying on the last version of monterey and apparently won't get updates anymore.
Current state is successful bootable monterey clone (12.7.6).
Thanks,
Dave
Have you read the support page Creating legacy bootable copies of macOS? That really covers most of it. Obviously, you can ignore all the warnings which apply only to Apple Silicon Macs. And, since you are running opencore, you already understand the tricks required to make the external bootable.
I am not surprised your brain has turned to mush - there are some misunderstandings in this thread. But there are pearls of wisdom too.
All done!!!
Have you configured and tested a regular backup of the data volume to the clone? Then you will have a bootable clone ready for use when needed.
Yep I've read that page multiple times. I guess I'm one of those guys on the final hurrah of the wonderful macpro4,1 flashed to 5,1 and will be staying on Monterey until I move to a current gen mac mini/studio.
I guess I was seeing if there was really a reason in my use case to do the modern ccc clone method but after a bunch of research, seem to be a good candidate for the legacy option.
I can boot fine using legacy method, still have slower OWC Accelsior E2 m.2 as a safety-net, have time machine & backblaze for other backup methods... and was hoping to just switch over to the 970 Evo plus blade, which I've now done.
Not sure what you mean about configuring and testing regular backup of data volume. My clone (now my main drive) is bootable already and now the older slower drive is my backup... if that makes sense.
I guess I was seeing if there was really a reason in my use case to do the modern ccc clone method but after a bunch of research, seem to be a good candidate for the legacy option.
I can boot fine using legacy method, still have slower OWC Accelsior E2 m.2 as a safety-net, have time machine & backblaze for other backup methods... and was hoping to just switch over to the 970 Evo plus blade, which I've now done.
Not sure what you mean about configuring and testing regular backup of data volume. My clone (now my main drive) is bootable already and now the older slower drive is my backup... if that makes sense.
I was wondering if, after creating a bootable clone, you were able to configure ongoing (possibly scheduled) CCC backups to maintain the data volume without needing to recreate the bootability (is that a word?) very time. But you are already one step ahead (now using the 970 Evo clone as your normal boot disk). Don't let me confuse you!
The CCC Legacy method uses ASR (Apple System Replicator) to clone the SSV (Signed Sealed System Volume). It can only do this onto an erased empty destination. After creating your first legacy bootable backups subsequent backup cannot update the SSV on the clone, only the -Data volume.
Mike Bombich says this in this article, which is for CCC version 6:
“If I continue to make regular backups to the destination, will it remain bootable?
You should not expect the destination to remain bootable after running additional backup tasks to the destination (i.e. via manual or scheduled backups). The Legacy Bootable Copy Assistant is intended only for creating ad hoc, bootable copies of the system that you intend to use immediately.”
So the safe way of making ongoing bootable backups is to erase the destination each time and do a fresh Legacy backup every time, which will include the SSV of course. This sounds horrendous but with modest sized boot volumes and fast SSD destinations is very quick, and how I did it when I used Legacy. This is why I said earlier that the Legacy method was not as straightforward to keep up to date.
Caveats: I did use the Legacy method briefly a few years ago but soon switched to the recommended way…so I don't speak from current experience of the Legacy method. I am also pretty rusty on CCC6 vs CCC7 which I have used since it was released. Monterey has a separate SSV and -Data volume so pretty sure it is subject to all the same issues as current OSes as far as bootable clones are concerned. I also don't have experience of opencore.
Last edited:
