Carbon Copy Cloner 6/7 - Users Thread

[gilby101]

Recently I updated to OCLP 1.5.0 and macOS 14.7. Found that when restore using a CCC or TM snapshot that was made in the older versions, would cause the computer not able to boot. Likewise, migration assistant using the same older version snapshot would not boot as well. In other words, all the snapshots I had make for the past several months become useless. Not sure if this just me doing something wrong.

OCLP changes your recovery strategies. From a total disaster you need to install an Apple supported macOS, upgrade it via OCLP to the version you want to use and then, with macOS running, use the Migration Assistant to recover. You can't use MA during the install.

Re your post before, there are two obvious and distinct reasons for backup.
1) To recover the whole system to a known recent state. You don't need much history for that.
2) To restore files that you deleted or modified at some point in the past and to get them back from an old backup.
Taking those two in to account, you can decide how much history you want. More history, more disk space consumed.

Don't expect Apple to add any options to TM. It is supposed to be a simple (no tweaks) backup solution.

 

[dai-leung]

Thank you so much for your big picture view of backup and your advice on OCLP! I had been chasing down the wrong rabbit hole. Now I think I understand how I should use backups — only after much hard work on the wrong direction. Thanks gain for your time and effort!

 

[Realityck]

CCC 7.0.3 (8063) is now available — This is a update of CCC 7.0.2 (8048)

Spoiler: CCC 7.0.3 Fixes and Changes

• Fixed
  Fixed an issue in which CCC's helper was occasionally not completely exiting on startup in cases where there were no scheduled tasks. This was leading to cases where the task history database would be closed, thus disallowing new entries to be recorded.
• Changed
  Improved the experience of editing a password in the email server settings panel.
• Fixed
  Addressed an edge case scenario where file ownership/permissions were preserved despite using the "Don't preserve permissions" advanced setting in cases where files were cloned via the APFS clonefile() method (i.e. in cases where the source and destination are folders on the same APFS volume).
• Changed
  CCC will apply a more strict 5GB minimum free space requirement when the destination is the startup disk (or a volume in the same APFS container as the startup disk).
• Changed
  Adjusted how ASR is invoked when creating a legacy bootable copy of macOS Sequoia on Apple Silicon Macs. This corrects somecases where the destination would fail to boot and the macOS Boot Recovery Assistant would indicate that macOS would need to be reinstalled. This does not resolve all of those issues, though. We have still found ASR to be a little bit inconsistent in its ability to produce bootable devices on the Apple Silicon platform, despite creating perfect byte-for-byte copies.
• Changed
  Implemented a workaround for some oddly-specific folder corruption on Lucidfs that occasionally prevents CCC from creating the write readiness cookie file, despite having no trouble creating other files in the same folder.
• Changed
  Task groups no longer get a "success" icon if they run (e.g. on a schedule) but have no tasks to run (e.g. because all tasks within it are disabled, or because the group has no tasks at all).
• Fixed
  Fixed a false-positive postflight re-verification error that was affecting filesystem-compressed files on macOS Sequoia.
• Changed
  Resolved a scenario where files that had been duplicated via the APFS clonefile() procedure were getting re-cloned on the destination during each run because macOS adds a GateKeeper extended attribute to files on the destination.

 

[Realityck]

CCC 7.0.4-b1 (8067) is now available — This is a pre-release update of CCC 7.0.3 (8063)

Spoiler: CCC 7.0.4-b1 Fixes and Changes

• Fixed
  Fixed an issue introduced in the 7.0.3 update that would cause postflight shut down and restart requests to fail if the task was started manually.
• Changed
  Added yet another workaround for Apple's restriction on access to the current WiFi network name in macOS Sequoia. These restrictions are affecting our ability to limit task execution to when the Mac is connected to a specific WiFi network. Thanks to the assembly of WiFi network name+location databases (e.g. collected by companies that provide street-view imagery), WiFi network names can be used for location fingerprinting. As such, Apple deems this to be "private" data. Access to this information is only granted to an application that specifically requests access to location information. That's way more information than we want or need for this particular feature within CCC. Making the matter yet worse, that location service isn't even available to background "daemon" applications, like CCC's helper tool. While this update includes a workaround that will temporarily allow us to continue pulling the current WiFi SSID from the system, we anticipate that Apple will eventually "fix" these gaps as well, and the feature will have to be disabled.
• Changed
  Fixed an odd edge-case condition where CCC was failing a task in the readiness phase because a source NTFS volume lacked support for a common system call.

 

[Realityck]

CCC 7.0.4-b2 (8070) is now available — This is a pre-release update of CCC 7.0.3 (8063)

Spoiler: CCC 7.0.4-b2 Fixes and Changes

• Fixed
  Fixed a logic issue introduced in the 7.0.3 update that leads to an error when running "legacy bootable copy" tasks on Intel Macs running Sequoia.
• Fixed
  Fixed an issue introduced in the 7.0.3 update that would cause postflight shut down and restart requests to fail if the task was started manually.
• Changed
  Added yet another workaround for Apple's restriction on access to the current WiFi network name in macOS Sequoia. These restrictions are affecting our ability to limit task execution to when the Mac is connected to a specific WiFi network. Thanks to the assembly of WiFi network name+location databases (e.g. collected by companies that provide street-view imagery), WiFi network names can be used for location fingerprinting. As such, Apple deems this to be "private" data. Access to this information is only granted to an application that specifically requests access to location information. That's way more information than we want or need for this particular feature within CCC. Making the matter yet worse, that location service isn't even available to background "daemon" applications, like CCC's helper tool. While this update includes a workaround that will temporarily allow us to continue pulling the current WiFi SSID from the system, we anticipate that Apple will eventually "fix" these gaps as well, and the feature will have to be disabled.
• Changed
  Fixed an odd edge-case condition where CCC was failing a task in the readiness phase because a source NTFS volume lacked support for a common system call.
  

Changes from beta 1 is
Fixed a logic issue introduced in the 7.0.3 update that leads to an error when running "legacy bootable copy" tasks on Intel Macs running Sequoia.

 

[Realityck]

CCC 7.0.4-b3 (8076) is now available — This is a pre-release update of CCC 7.0.3 (8063)

Spoiler: CCC 7.0.4-b3 Fixes and Changes

• Changed
  b3: The CCC-created keychain entries in the System keychain will be modified in preparation for some changes coming in CCC 7.1. This should go completely unnoticed, but if you see anythin awry with sending email notifications or mounting encrypted volumes, please let us know via CCC's Help menu > Report a problem.
• Changed
  b3: The Snapshot Navigator now indexes bundle contents too, so we can search for files within, for example, a Photos library bundle file.
• Fixed
  Fixed a logic issue introduced in the 7.0.3 update that leads to an error when running "legacy bootable copy" tasks on Intel Macs running Sequoia.
• Fixed
  Fixed an issue introduced in the 7.0.3 update that would cause postflight shut down and restart requests to fail if the task was started manually.
• Changed
  Added yet another workaround for Apple's restriction on access to the current WiFi network name in macOS Sequoia. These restrictions are affecting our ability to limit task execution to when the Mac is connected to a specific WiFi network. Thanks to the assembly of WiFi network name+location databases (e.g. collected by companies that provide street-view imagery), WiFi network names can be used for location fingerprinting. As such, Apple deems this to be "private" data. Access to this information is only granted to an application that specifically requests access to location information. That's way more information than we want or need for this particular feature within CCC. Making the matter yet worse, that location service isn't even available to background "daemon" applications, like CCC's helper tool. While this update includes a workaround that will temporarily allow us to continue pulling the current WiFi SSID from the system, we anticipate that Apple will eventually "fix" these gaps as well, and the feature will have to be disabled.
• Changed
  Fixed an odd edge-case condition where CCC was failing a task in the readiness phase because a source NTFS volume lacked support for a common system call.

Whats new this beta

• b3: The CCC-created keychain entries in the System keychain will be modified in preparation for some changes coming in CCC 7.1. This should go completely unnoticed, but if you see anythin awry with sending email notifications or mounting encrypted volumes, please let us know via CCC's Help menu > Report a problem.
• Changed
  b3: The Snapshot Navigator now indexes bundle contents too, so we can search for files within, for example, a Photos library bundle file.

 

[basslik]

I have a question>? thanks.
With APFS and modern macOS you can no longer do incremental backups to a clone and have it still be bootable?

 

[Realityck]

I have a question>? thanks.
With APFS and modern macOS you can no longer do incremental backups to a clone and have it still be bootable?

True, APFS utility was changed by Apple that disabled that. Anyone can do a non-bootable standard backup to a ASR volume (ext SSD example) and keep doing incremental backups. Perhaps the thought was its just easier if something goes very wrong to do a DFU restore (factory settings - complete wipe , then install new OS/FW) after that is completed, just use the ext SSD (ASR volume) with MacOS migration assistant to get all your settings/apps/data back to the last saved incremental backup time point. The legacy snapshot method does run a APFS backup but can't have incremental backups. In some instances it will still boot, but that is using a thunderbolt SSD, it's not like it was running back in MacOS 13 days

ASR = Apple Software Recovery

 

[basslik]

True, APFS utility was changed by Apple that disabled that. Anyone can do a non-bootable standard backup to a AMSR volume (ext SSD example) and keep doing incremental backups. Perhaps the thought was its just easier if something goes very wrong to do a DFU restore (factory settings - complete wipe , then install new OS/FW) after that is completed, just use the ext SSD (ASMR volume) with MacOS migration assistant to get all your settings/apps/data back to the last saved incremental backup time point. The legacy snapshot method does run a APFS backup but can't have incremental backups. In some instances it will still boot, but that is using a thunderbolt SSD, it's not like it was running back in MacOS 13 days.

Thank you for the information.👍

 

[Realityck]

For the time being there is a new bug with the first MacOS 15.2 beta that causes the APFS replication (Legacy Snapshot) to fail to mount the external target SSD (either USB-C or TB) upon its completion.

If you want to backup while testing MacOS 15.2 beta, please use the standard backup instead which will serve as an ext ASR volume. This is with the latest CCC beta 7.0.4-b3. CCC Dev is aware of this issue.

 

[Realityck]

The bug with APFS replication (Legacy Snapshot) that first showed up with MacOS 18.2 beta is still occurring with this weeks MacOS 15.2 beta 3. Keep using standard backup which is working with external ASR volume.

 

[Realityck]

CCC 7.0.4 (8081) is now available — This is a update of CCC 7.0.3 (8063)

Spoiler: CCC 7.0.4 Fixes and Changes

• The Snapshot Navigator now indexes bundle contents too, so we can search for files within, for example, a Photos library bundle file.
• Fixed
  Fixed a logic issue introduced in the 7.0.3 update that leads to an error when running "legacy bootable copy" tasks on Intel Macs running Sequoia.
• Fixed
  Fixed an issue introduced in the 7.0.3 update that would cause postflight shut down and restart requests to fail if the task was started manually.
• Changed
  Added yet another workaround for Apple's restriction on access to the current WiFi network name in macOS Sequoia. These restrictions are affecting our ability to limit task execution to when the Mac is connected to a specific WiFi network. Thanks to the assembly of WiFi network name+location databases (e.g. collected by companies that provide street-view imagery), WiFi network names can be used for location fingerprinting. As such, Apple deems this to be "private" data. Access to this information is only granted to an application that specifically requests access to location information. That's way more information than we want or need for this particular feature within CCC. Making the matter yet worse, that location service isn't even available to background "daemon" applications, like CCC's helper tool. While this update includes a workaround that will temporarily allow us to continue pulling the current WiFi SSID from the system, we anticipate that Apple will eventually "fix" these gaps as well, and the feature will have to be disabled.
• Changed
  Fixed an odd edge-case condition where CCC was failing a task in the readiness phase because a source NTFS volume lacked support for a common system call.

Note
"The APFS replication procedure failed, possibly due to a hardware error."
This bug with Legacy Snapshot backup method is still unresolved because of Apple changed APFS utility operation with MacOS 15.2 beta 1 thru 3 when replicating to an external drive. Standard backup as a workaround to external ASR volumes works fine.

 

[Realityck]

Wondering if CCC is ever in the news and I came upon this recent article tonight . . .

Use a cloned drive to recover from Mac failures

Last month, my Mac Studio stopped working. It went quickly from a bizarre error message to the inability to install software updates to a failure to reinstall the base operating system to a trip to…

sixcolors.com

Details what a lot of us do to recover from something weird happening to a Mac you use.

 

[0134168]

Wondering if CCC is ever in the news and I came upon this recent article tonight . . .

Use a cloned drive to recover from Mac failures

Last month, my Mac Studio stopped working. It went quickly from a bizarre error message to the inability to install software updates to a failure to reinstall the base operating system to a trip to…

sixcolors.com

Details what a lot of us do to recover from something weird happening to a Mac you use.

I stopped to write in this thread a little time ago. So tired of telling that CCC makes perfect clones. Use SSd´s since many years ago. Poeple don´t want to learn. Want to make their problems be solved without effort.

 

[rjalex]

Please be patient, English not my first language so might not be fully understanding instructions.

I have a 2020 Mac Mini M1 and will receive a new 2024 Mac Mini M4.

Old machine runs Sequoia 15.1 and has a CCC 7.04 running hourly full disk verified incremental backups to external SSD.

I am a freelance Python developer and have many products/environemnts/data/settings I'd like to have on the new machine as quickly as possible.

I am confused on the different roles of the Migration Assistant (never used it) and CCC.

What would be the best process to resume my work on the new machine as quickly as possible?

Should I run a new different task on the old machine with CCC to speed up things?

 

[Realityck]

I am confused on the different roles of the Migration Assistant (never used it) and CCC.

When CCC does a standard back up of your system settings, applications, and data files to a external SSD it is considered a ASR (Apple Software Recovery) volume that Migration Assistant will recognize and can work from when need to restore all your stored personal information after MacOS install overwrite everything.

How to use Migration Assistant
see https://support.apple.com/en-us/102613

Please note if you are able to setup your new M4 Mac next to the M1 Mac with bluetooth and Wifi active you can run this process without involving ASR volume and CCC. That ASR volume that CCC made is there in case this fails ands you need help from an Apple Store to reinstall the OS with a full wipe, and use that external SSD with Migration Assistant.

The Apple document explains both for you.

 

[eldho]

Migration assistant brings everything over to your new machine - all applications and settings. Once the process has completed you then carry on using your new computer in just the same way as your previous one - except that your new computer is rather faster and all that.

The standard way of using Migration Assistant that I am familiar with involves letting Migration Assistant use your CCC clone as a source in order to shift everything across. Realityck in the previous post speaks of an even more direct method - it is your choice which you use but you will end up at the same place.

 

[rjalex]

Very useful document and advice. I am both very excited for this upgrade and also scared. LOL. Thanks a lot.

 

[Realityck]

CCC 7.0.4 (8082) is now available — This is a update of CCC 7.0.4 (8081)

Spoiler: CCC 7.0.4 (8082) Fixes and Changes

• Changed
  Build 8082 improves some 7.0.4 changes to the handling of low free space conditions on the destination.
• Changed
  The Snapshot Navigator now indexes bundle contents too, so we can search for files within, for example, a Photos library bundle file.
• Fixed
  Fixed a logic issue introduced in the 7.0.3 update that leads to an error when running "legacy bootable copy" tasks on Intel Macs running Sequoia.
• Fixed
  Fixed an issue introduced in the 7.0.3 update that would cause postflight shut down and restart requests to fail if the task was started manually.
• Changed
  Added yet another workaround for Apple's restriction on access to the current WiFi network name in macOS Sequoia. These restrictions are affecting our ability to limit task execution to when the Mac is connected to a specific WiFi network. Thanks to the assembly of WiFi network name+location databases (e.g. collected by companies that provide street-view imagery), WiFi network names can be used for location fingerprinting. As such, Apple deems this to be "private" data. Access to this information is only granted to an application that specifically requests access to location information. That's way more information than we want or need for this particular feature within CCC. Making the matter yet worse, that location service isn't even available to background "daemon" applications, like CCC's helper tool. While this update includes a workaround that will temporarily allow us to continue pulling the current WiFi SSID from the system, we anticipate that Apple will eventually "fix" these gaps as well, and the feature will have to be disabled.
• Changed
  Fixed an odd edge-case condition where CCC was failing a task in the readiness phase because a source NTFS volume lacked support for a common system call.

Note
Build 8082 improves some 7.0.4 changes to the handling of low free space conditions on the destination.

 

[Just_Kevin]

I'm reevaluating my backup strategies after I recently had an important pdf file become corrupt. I currently store most of my files on a NAS with two RAID 1 HDD. Since they are formatted in btfs, there are some limitations working with Mac and I cannot do snapshots. The NAS was in place years before I bought a Mac. I think I've come up with a new plan.

Store folders/files I access on a somewhat regular basis, say quarterly and more frequently, locally on the Mac. Folder/files I may access less frequently I will continue to store on the NAS. Use CCC to run an automated task to do a back up to an external APFS formatted SSD, connected to the MacBook (via Docking Station) creating snapshots. I will continue to use the Synology program to run backups from the Mac to the NAS. As an additional safety net, I can use a Cloud Service, like Carbonite, to back up the external SSD. Carbonite includes one computer & one external drive for one price. To do backups from the NAS to Carbonite would be a much higher cost.

If I am correct in my thinking, this will provide protection against a file becoming corrupt, since CCC will be doing backup versioning. That is what I am understanding from this link anyway, https://support.bombich.com/hc/en-us/articles/20686443871383-Introduction-to-Snapshots

 

[eldho]

f I am correct in my thinking, this will provide protection against a file becoming corrupt, since CCC will be doing backup versioning

That is my understanding too - that you can browse back through the snapshots to find the version of the file that you want and then simply click 'restore'. If you are needing to restore your whole system it seems that you can use only your last version of CCC as discussed earlier on this thread.

 

[dai-leung]

“

When CCC does a standard back up of your system settings, applications, and data files to a external SSD it is considered a ASR (Apple Software Recovery) volume that Migration Assistant will recognize

Sorry to ask a dump question: when on CCC dash board, when I click on the volume on top left that is the CCC backup, I see a list of snapshots, which one is the “standard backup”? How do I distinguish a “standard backup” vs a snapshot? Where is the “standard backup” stored?

 

[gilby101]

I see a list of snapshots, which one is the “standard backup”? How do I distinguish a “standard backup” vs a snapshot? Where is the “standard backup” stored?

On the CCC destination volume, all backups are snapshots. All snapshots are equally complete backups. They are only distinguished by date and time. None of them are more "standard" than any other.

 

[rjalex]

Using CCC snapshot disk with the migration assistant made my transition from my older Mini M1 to my new Mini M4 almost painless. Now in the first days with the new machine I sometimes have to re-login to services or reauthorize applications (for example this morning I had to grant google meet to be able to record video). Great !!!

Now right after the migration I am using the same target disk for my hourly snapshots and all seems smooth as silk.

Thank you all.

 

[dai-leung]

On the CCC destination volume, all backups are snapshots. All snapshots are equally complete backups. They are only distinguished by date and time. None of them are more "standard" than any other.

Thank you for your explanation which really help me to understand more about snspahots!

I am still confused.

Q1) Am I correct that any snapshot can be “considered a ASR (Apple Software Recovery) volume that Migration Assistant will recognize and can work from…”? Yes?

but when I opened MA in Application/Ultilities and select CCC backup drive as source, I was not given a choice to select any snapshot. What was on this external drive that I was using it as a source? Was it the latest snapshot on the snapshot table or something else?

If I use the time machine backup drive in MA, it does let me choose a TM backup on any date and time.

Q2) Likewise, On CCC dashboard, when I selected “Restore” on the top, then for “source”, I selected CCC external backup drive. Same question as in (Q1). What was on this external drive that I was using it as source? Was it the latest snapshot on the snapshot table or something else? Again I was not given a choice to use any snapshot.