Carbon Copy Cloner 7 - Users Thread

[yellowhelicopter]

You can't use CCC to incrementally update the system version after making a legacy bootable clone. Thats why the developer says it like a limited time snap shot. It's also why we do a complete wipe of the volumes before running a legacy bootable clone process. (APFS replication)

OK, so I had cloned my Mac Mini M1 internal drive (12.5) to external SSD some time ago because I wanted to use external drive instead of internal (don't ask me why). And because somehow I couldn't properly install MacOS on this external SSD by standard means with MacOS installer (the SSD just refused to boot IIRC), so I just used CCC to clone the whole thing. To my surprise it booted, and keeps to work fine since then.

But now I have a problem. As you probably guessed I can't update the system on this bootable external SSD. I wanted to update to 12.6, it went all the way to 100% and said "Update failed", BTW it's weird that it didn't say NO from the start, I had to wait for like half an hour.

Well, now that I understand it's not possible to update the system snapshot made with CCC, I have a question. What is the best way for me now if I want to update the system on this drive and continue to use it as bootable? The problem is that it's a 1TB and quite full.

Is the only way to temporally move all the data to some place, update the system on internal SSD, then clone it once again (wiping all the external SSD), and then move all the data back? Quite cumbersome and time consuming if so, especially if I have to repeat the procedure every time I want to update MacOS. Then I may have to think about just moving my user folder and programs to external if it's possible and boot from internal.


PS: There are two volumes on my external SSD in a container that CCC created - one is "System volume APFS" which store system snapshot which apparently cannot be changed, and other is "Data volume APFS" where everything else is stored. Is it possible to erase and clone anew only the system volume leaving the data volume intact?

 

[Realityck]

CCC 6.1.3 (7412) released to fix a issue from its initial 6.1.3 update

Build 7412: Fixed an issue introduced in the initial 6.1.3 update that was causing trouble with tasks configured to back up to or from a remote Mac.

 

[Realityck]

OK, so I had cloned my Mac Mini M1 internal drive (12.5) to external SSD some time ago because I wanted to use external drive instead of internal (don't ask me why). And because somehow I couldn't properly install MacOS on this external SSD by standard means with MacOS installer (the SSD just refused to boot IIRC), so I just used CCC to clone the whole thing. To my surprise it booted, and keeps to work fine since then.

But now I have a problem. As you probably guessed I can't update the system on this bootable external SSD. I wanted to update to 12.6, it went all the way to 100% and said "Update failed", BTW it's weird that it didn't say NO from the start, I had to wait for like half an hour.

Well, now that I understand it's not possible to update the system snapshot made with CCC, I have a question. What is the best way for me now if I want to update the system on this drive and continue to use it as bootable? The problem is that it's a 1TB and quite full.

Is the only way to temporally move all the data to some place, update the system on internal SSD, then clone it once again (wiping all the external SSD), and then move all the data back? Quite cumbersome and time consuming if so, especially if I have to repeat the procedure every time I want to update MacOS. Then I may have to think about just moving my user folder and programs to external if it's possible and boot from internal.


PS: There are two volumes on my external SSD in a container that CCC created - one is "System volume APFS" which store system snapshot which apparently cannot be changed, and other is "Data volume APFS" where everything else is stored. Is it possible to erase and clone anew only the system volume leaving the data volume intact?

I continue to wipe a backup snapshot via disk utility and run CCC legacy backup copy for each OS beta increment. For an additional backup you could alway use a USB 3 2 TB HDD, these run a lot slower but hey for $80 they are cheap fall back from your SSD.

 

[yellowhelicopter]

So currently there is no way to not erase the whole destination container (system+data volumes) when using "Legacy bootable copy assistance", am I right?

If yes, I see only two ways for updating MacOS on cloned bootable external drive: a) to try and update it directly with MacOS installer from Apple store; b) to erase the whole volume container and clone the updated system anew.

 

[gilby101]

a) to try and update it directly with MacOS installer from Apple store; b) to erase the whole volume container and clone the updated system anew.

b) From the help:

"Do I have to erase the destination to make a bootable copy of the system?​

If your Mac is running Big Sur or later, yes. As of macOS Big Sur, we're required to use Apple's APFS replicator to establish a bootable copy of an APFS volume group. We're unable to leverage the SafetyNet feature, and it's no longer appropriate to store other data on the destination volume. You must dedicate a volume to your bootable copy of the system."

No doubt, you can try a), but it is not the recommended way.

Remember that "legacy bootable copies" are not fully supported - only "best effort".

 

[flowrider]

I have never tried to update a cloned disc. I use the clone simply as a backup. When the boot disk proves trustworthy. I erase the clone and reclone. Works for me👍 Although not sure what I will do if my boot disk ever becomes corrupted🧐

But, as I recall, when booting from a clone there is a message on the first boot allowing you to turn off cloning identification. Maybe doing that allows it to be updated?

Lou

 

[yellowhelicopter]

Well, I used MacOS cloning only because my attempt to directly install Monterey from Apple Store on external SSD failed, it's strange because the clone works just fine.

Anyway, I think maybe to make two volumes on this SSD - one small for cloning, and keep all the data (Applications, docs, storage) on the second volume. It would be great if ALL folders in data volume of the cloned container could be moved to other separate volume, leaving only folder aliases instead. Then it would be only a matter of cloning an updated system and restoring aliases after the cloning.


PS:

After further thinking, it's much easier to just make a new volume on the same external ssd, move all your stuff including applications there, carbon copy the updated OS, and then move the apps back leaving other stuff on that new volume to ease future OS update procedures. No additional drive or messing with simlinks needed.

 

[yellowhelicopter]

But, as I recall, when booting from a clone there is a message on the first boot allowing you to turn off cloning identification. Maybe doing that allows it to be updated?

Hmm, I don't remember seeing such message. I doubt it's possible on the latest MacOSes because, as I understand, the read-only status of a system clone is applied by ASR and cannot be changed. I may be totally wrong and it would be great if it could though.

 

[Realityck]

CCC 6.1.3 (7413) released to fix a issue from its initial 6.1.3 update

Build 7413: Fixed a pair of issues introduced in the initial 6.1.3 update — the "Restore" button in CCC's toolbar was errantly disabled, and tasks configured to back up to or from a remote Mac were failing to copy CCC's file copier to the remote Mac.

 

[Realityck]

Now available CCC 6.1.4-b1 (7417) - This is a pre-release update of CCC 6.1.3

Spoiler: CCC 6.1.4-b1 Fixes and Changes

• Fixed
  The "Only on the next run" and "Once a quarter" options are no longer hidden in the frequency popup menu adjacent to the "Find and replace corrupted files" setting.
• New
  CCC will now preserve the "Date Added" attribute on files and folders on filesystems that support that attribute.
• New
  CCC will now preserve the space savings of pure "cloned" files (duplicated via the clonefile() function, e.g. duplicated in the Finder) when copying from an APFS volume to another APFS volume.

2 new changes

 

[Realityck]

Now available CCC 6.1.4-b2 (7418) - This is a pre-release update of CCC 6.1.3

Fixed
Improved the handling of errors when free space is depleted on the destination volume.

 

[Realityck]

Note so far no issues with the recent CCC 6.1.4-b2 (7418) doing legacy backup copy (limited time snapshot) with previous Ventura beta 10, and todays Ventura beta 11 released to developers.

 

[0134168]

Note so far no issues with the recent CCC 6.1.4-b2 (7418) doing legacy backup copy (limited time snapshot) with previous Ventura beta 10, and todays Ventura beta 11 released to developers.

Great!

 

[Realityck]

Now available CCC 6.1.4-b3 (7425) - This is a pre-release update of CCC 6.1.3

• Fixed - When CCC is configured to copy files from a volume that lacks support for file ownership (e.g. a NAS volume, or any volume with ownership disabled), ownership of files copied to the destination (when applicable) is set to the user account that configured the CCC task. This update fixes an issue in which numeric user account IDs larger than 32768 were getting improperly applied. This is not a common scenario; typically user account IDs start from 501, but in some corporate environments they can be much larger.

 

[Realityck]

If you are running MacOS 13.1 beta 2 and you have prepared a wiped external volume with disk utility, and you start CCC legacy bootable copy and it warns you that this will be slow. Dismount external volume and unplug it, and replug it in again, then it shouldn't give that issue.

 

[0134168]

If you are running MacOS 13.1 beta 2 and you have prepared a wiped external volume with disk utility, and you start CCC legacy bootable copy and it warns you that this will be slow. Dismount external volume and unplug it, and replug it in again, then it shouldn't give that issue.

Weird.

 

[macguru9999]

I tried the latest CCC release with the latest osx monterey release today and when i tried to open it i got the message "Carbon copy cloner could not be opened". (on a compatible imac) Any ideas ??

 

[Realityck]

I tried the latest CCC release with the latest osx monterey release today and when i tried to open it i got the message "Carbon copy cloner could not be opened". (on a compatible imac) Any ideas ??

Is this with latest MacOS 12.6.1 release? I would first try booting in safe mode and see if it runs OK. Download another copy of CCC (replace yours), in case something odd happened to the application. On a M1 based macs I had no such instance with Monterey up to the point I started using Ventura back in July 2022. I assume you’re discussing this with an Intel imac?

 

[Realityck]

Now available CCC 6.1.4-b4 (7435) — This is a pre-release update of CCC 6.1.3

Spoiler: CCC 6.1.4-b4 Fixes and Changes

• Changed
  b4: The "Command+R" keyboard shortcut for starting a task now also works for starting a task group.
• Fixed
  b4: Fixed an issue in which the throttling mechanism applied to "When the source or destination is reconnected" tasks was not getting applied consistently.
• Changed
  b4: Fixed an edge case in Ventura where the "Legacy Bootable Copy" method would fail with a "destination is full" error in cases where the destination was a disk image and the source was a clean install of macOS Ventura.
• Changed
  b4: Added a Ventura download link to the macOSInstaller Media Assistant.
• Changed
  b4: Added a global exclusion for a "@Recently-snapshot" folder that appears on some NAS devices. Copying each snapshot within this folder will typically overrun the capacity odf the destination.
• Fixed
  b4: Fixed preflight mounting and ownership enabling on Remote Mac destination volumes on Ventura+ Macs.

 

[Realityck]

Now available CCC 6.1.4-b5 (7443) — This is a pre-release update of CCC 6.1.3

Spoiler: CCC 6.1.4-b5 Fixes and Changes

• Changed
  b5: Errors related to minor filesystem corruption in /Users/username/Library/Biome on macOS Ventura are now suppressed.
• Changed
  b5: CCC will no longer raise concerns about dropped cloud-only placeholder files. With a minor adjustment and some additional testing of several scenarios, we have determined that there is no longer a restore concern related to dropping these placeholder files. If you previously excluded the CloudStorage folder from your backup, you may remove that exclusion. You're also welcome to leave the exclusion in place. In our tests, the cloud service providers populated the absent content just fine.

 

[Realityck]

CCC 6.1.4 (7449) is now available. Works with MacOS 13.1 beta 4.

Spoiler: CCC 6.1.4 Fixes and Changes

• New
  CCC will now preserve the space savings of pure "cloned" files (duplicated via the clonefile() function, e.g. duplicated in the Finder) when copying from an APFS volume to another APFS volume.
• New
  CCC will now preserve the "Date Added" attribute on files and folders on filesystems that support that attribute.
• Changed
  CCC will no longer raise concerns about dropped cloud-only placeholder files. With a minor adjustment and some additional testing of several scenarios, we have determined that there is no longer a restore concern related to dropping these placeholder files. If you previously excluded the CloudStorage folder from your backup, you may remove that exclusion. You're also welcome to leave the exclusion in place. In our tests, the cloud service providers populated the absent content just fine.
• Changed
  The errors associated with an ExFAT+Ventura-specific filesystem bug now direct the user to the macOS Ventura Known Issues Kbase article, which documents the problem, a workaround, and a potential solution.
• Changed
  Errors related to minor filesystem corruption in /Users/username/Library/Biome on macOS Ventura are now suppressed.
• Fixed
  Improved the handling of errors when free space is depleted on the destination volume.
• Fixed
  The "Only on the next run" and "Once a quarter" options are no longer hidden in the frequency popup menu adjacent to the "Find and replace corrupted files" setting. Same deal for the "Archives that are older than" option in the SafetyNet pruning limit popup menu in Advanced Settings > Preflight.
• Changed
  The "Command+R" keyboard shortcut for starting a task now also works for starting a task group.
• Fixed
  Fixed an issue in which the throttling mechanism applied to "When the source or destination is reconnected" tasks was not getting applied consistently.
• Changed
  Fixed an edge case in Ventura where the "Legacy Bootable Copy" method would fail with a "destination is full" error in cases where the destination was a disk image and the source was a clean install of macOS Ventura.
• Changed
  Added a Ventura download link to the macOSInstaller Media Assistant.
• Changed
  Added a global exclusion for a "@Recently-snapshot" folder that appears on some NAS devices. Copying each snapshot within this folder will typically overrun the capacity of the destination.
• Fixed
  Fixed preflight mounting and ownership enabling on Remote Mac destination volumes on Ventura+ Macs.
• Fixed
  When CCC is configured to copy files from a volume that lacks support for file ownership (e.g. a NAS volume, or any volume with ownership disabled), ownership of files copied to the destination (when applicable) is set to the user account that configured the CCC task. This update fixes an issue in which numeric user account IDs larger than 32768 were getting improperly applied. This is not a common scenario; typically user account IDs start from 501, but in some corporate environments they can be much larger.

 

[0134168]

CCC 6.1.4 (7449) is now available. Works with MacOS 13.1 beta 4.

Spoiler: CCC 6.1.4 Fixes and Changes

• New
  CCC will now preserve the space savings of pure "cloned" files (duplicated via the clonefile() function, e.g. duplicated in the Finder) when copying from an APFS volume to another APFS volume.
• New
  CCC will now preserve the "Date Added" attribute on files and folders on filesystems that support that attribute.
• Changed
  CCC will no longer raise concerns about dropped cloud-only placeholder files. With a minor adjustment and some additional testing of several scenarios, we have determined that there is no longer a restore concern related to dropping these placeholder files. If you previously excluded the CloudStorage folder from your backup, you may remove that exclusion. You're also welcome to leave the exclusion in place. In our tests, the cloud service providers populated the absent content just fine.
• Changed
  The errors associated with an ExFAT+Ventura-specific filesystem bug now direct the user to the macOS Ventura Known Issues Kbase article, which documents the problem, a workaround, and a potential solution.
• Changed
  Errors related to minor filesystem corruption in /Users/username/Library/Biome on macOS Ventura are now suppressed.
• Fixed
  Improved the handling of errors when free space is depleted on the destination volume.
• Fixed
  The "Only on the next run" and "Once a quarter" options are no longer hidden in the frequency popup menu adjacent to the "Find and replace corrupted files" setting. Same deal for the "Archives that are older than" option in the SafetyNet pruning limit popup menu in Advanced Settings > Preflight.
• Changed
  The "Command+R" keyboard shortcut for starting a task now also works for starting a task group.
• Fixed
  Fixed an issue in which the throttling mechanism applied to "When the source or destination is reconnected" tasks was not getting applied consistently.
• Changed
  Fixed an edge case in Ventura where the "Legacy Bootable Copy" method would fail with a "destination is full" error in cases where the destination was a disk image and the source was a clean install of macOS Ventura.
• Changed
  Added a Ventura download link to the macOSInstaller Media Assistant.
• Changed
  Added a global exclusion for a "@Recently-snapshot" folder that appears on some NAS devices. Copying each snapshot within this folder will typically overrun the capacity of the destination.
• Fixed
  Fixed preflight mounting and ownership enabling on Remote Mac destination volumes on Ventura+ Macs.
• Fixed
  When CCC is configured to copy files from a volume that lacks support for file ownership (e.g. a NAS volume, or any volume with ownership disabled), ownership of files copied to the destination (when applicable) is set to the user account that configured the CCC task. This update fixes an issue in which numeric user account IDs larger than 32768 were getting improperly applied. This is not a common scenario; typically user account IDs start from 501, but in some corporate environments they can be much larger.

Updated. Thanks!

 

[mastermamo]

Found a workaround for this if post 3 doesn't work because you accidentally erased the wrong partition.
Format the destination drive in APFS format. Run the Monterey installer and choose to install to the new drive, Let it run until it has roughly 2 mins left then cancel the installer. This will create the Data volume for you that CCC can't.

Then as per Step #3...Erase both in the disk utility -> unmount backup target storage, erase system volume not the data volume, select erase volume group as preparation. In CCC you need to target that one volume as a destination in CCC with a new task. Then you will need to use the CCC choices in under your destination.

NB: For this on unsupported Macs using OpenCore, don't forget to run the open core patcher to the new OS drives EFI partition. If you don't and have the same drives in the machine you will not be able to boot from any drive until that EFI is updated.

 

[Realityck]

Now available CCC 6.1.5-b3 (7461) — This is a pre-release update of CCC 6.1.4

Spoiler: CCC 6.1.5-b3 Fixes and Changes

• Changed
  Adjusted the sidebar width when exiting full screen mode.
• Changed
  Fixed a layout issue in the task plan when hiding and then revealing the sidebar (specific to Ventura).
• Changed
  When a task fails because the source or destination is missing, and the user has enabled the "Don't send error notifications" (when the source or destination is missing) setting, the error will now be presented with the "cancelled by the user" icon in the Task History window, rather than an error icon.
• Fixed
  Fixed an issue in which a "Backup Health Check" would errantly (but harmlessly) recopy a certain class of files that did not need to be recopied.
• Changed
  Errors that occur due to a disagreement between the source and (typically NAS) destination filesystems on how composed characters should be stored are now presented with more specific advice and a link to a new Kbase article.
• New
  Network change events are now listed in the Activity tab of the CCC Dashboard application if any CCC tasks require network resources.

 

[Realityck]

Now available CCC 6.1.5-b4 (7464) — This is a pre-release update of CCC 6.1.4

whats new with this b4 version

• Changed
  When applicable, more context is presented now in cases where a task fails due to a stall at the source or destination (e.g. what specific file or folder is involved in the stall).
• Fixed
  b4: Fixed an issue introduced in 6.1.5-b3 that was causing changes to snapshot retention policy settings to not "stick".