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.