Contribute
Register

<< Solved >> How to make a perfect clone of my boot disk?

Wow! Thanks for the explanation and useful information.

I have never actually tried to boot from the clone as I couldn’t see all the files present so gave up.

I have also been advised to connect the clone disk via a USB enclosure or similar rather than connecting directly to a sata interface.

Would you agree with that?

I will give it another go.
 
I have also been advised to connect the clone disk via a USB enclosure or similar rather than connecting directly to a sata interface.
Without more context, I don't see why that advice would be offered.

I see it the other way, that using SATA avoids risk of startup failure due to USB mapping issues causing the drive to be disconnected during boot. But USB problems usually manifests very early in the boot process (usually but not always). OTOH, SATA can have its own probs depending on version of macOS and build. This is briefly covered in Dortania Guide Open Core Guide.

Be sure to boot the clone from an EFI which properly supports your main drive.

A bootable clone reformats the target drive, including its ESP, so you need to replace the EFI on the target to let the drive stand alone.

As a total aside: There's a hidden step to making a macOS drive bootable involving a very ancient part of Mac lore called the "bless" command, which more-or-less ensures that UEFI knows how to run macOS code at startup. It's a Terminal command applied by the cloning tool to finalize a macOS copy. There are rare edge cases for blessing a boot drive that can lead to startup problems, which might be why there's lore such as you need to be booted from the drive you are copying when making a bootable clone. Look up the bless commend if you're curious.

Re backups:

Once you have the backup clone bootable, you can use CCC to do Data-only Normal backups and the clone will continue work. But a problem comes when you need to do macOS updates. Stability problems may ensue from doing CCC's Normal backups to a drive at a different macOS rev, including not being able to boot the backup, or "Damaged" apps. I handle this with the following rules of thumb:

- Set aside a working backup for emergencies.

- Update the main drive and another backup in concert.

- Review the essential functionality of the updated backup after the first Normal backup from the updated main drive.

- Fully reclone to a backup if in doubt. Some people use CCC shell script hook to automatically copy over the source drive's EFI to the clone. I think scripts have been posted that you can re-use.

The worst case recovery will be that you have reinstall macOS and use Migration Assistant to pull over your backup, which is what Bombich recommends.
 
Just attempted my first CCC Legacy Bootable Copy of an erased NVMe inside an PCI-E card and after just 13 seconds, it FAILS for reasons I don't immediately understand. The troubleshooting suggests that the drive must be a Thunderbolt or USB connecting drive. Is that important? Can't it be an internal PCI-e Card? I clicked on the option where it ALLOWS CCC to erase the drive (again) for me. I do have an external USB thingy where I can put the blank NVMe SSD on and connect it to the Mac that way.

Safety Net is turned off and the Snapshot appears disabled? There's no "log" that gives information of what happened except the message is just that it failed (13 seconds!)

I followed the Troubleshooting tips, to reboot, erase the drive again and Select Different Destination Drive and in the new attempt the results appear the same. The only recourse I can see is moving the SSD to a USB connected NVMe Enclosure? I very appreciate any suggestions! I did have a standard backup of my Monterey drive on this destination NVMe previously but that's all erased now for this effort.
 
It doesn't matter how the drive is connected, except that no errors are tolerated, whatsoever.

If CCC detects any I/O error, it gives up because there's no way to complete signing of the system volume, so it will be useless.

You can try another attachment method for the drive, assuming that there's something wrong with the PCIe card.

If you go to the "Volumes" tab, and click on the drives, CCC will show a blue IO progress panel at the bottom of the screen which indicates the number of hard errors recorded since the last boot.

If either drive is recording errors, then the best you can do is either replace the drive (destination), or run a regular CCC copy (not bootable, from the source) to get as much data as you can onto another drive. In normal copy mode, CCC will provide a list of affected files at the end of the copy operation so you can evaluate the implications of lost data.
 
It doesn't matter how the drive is connected, except that no errors are tolerated, whatsoever.

If CCC detects any I/O error, it gives up because there's no way to complete signing of the system volume, so it will be useless.

You can try another attachment method for the drive, assuming that there's something wrong with the PCIe card.

If you go to the "Volumes" tab, and click on the drives, CCC will show a blue IO progress panel at the bottom of the screen which indicates the number of hard errors recorded since the last boot.

If either drive is recording errors, then the best you can do is either replace the drive (destination), or run a regular CCC copy (not bootable, from the source) to get as much data as you can onto another drive. In normal copy mode, CCC will provide a list of affected files at the end of the copy operation so you can evaluate the implications of lost data.

Thank you so much for replying. This is a brand new Samsung 970 Pro that I bought so that it would become the primary drive. I am working off an brand new Samsung SATA that is supposed to become the backup drive. I did have previous "standard backups" from previous efforts with SuperDuper and previous CCC before I was knowledgable about the existence of Legacy Bootable Cloning. I didn't realize there are now special methods required. I erased those previous efforts. The file format is proper: APFS and a GUID Partition. Previous cloning efforts appear normal on both SD and CCC.

The only information I have is that "The APFS replication procedure failed." I'm anxious to get this done! :)
Supposedly SuperDuper does indeed work with higher than Mojave OS but it no longer makes Monterey bootable? ShirtPocket should update that app to be as modern and current as possible...

My only recourse is to, indeed, change the location of the SSD and see if that makes a difference? And if it works, then I'll have to switch it back to the PCI-e card and boot there.

Will it improve the process if I turn SafetyNet ON?

It's amazing to me that CCC is probably the ONLY cloning software out there that does this service! Initially I thought just standard cloning of the drive and then adding an EFI file would be all I need, but that's not the case, the drive itself has be "made bootable" and CCC does that. Apparently the new file system structure that Apple added to newer OS drives is what makes this a difficult, specialized cloning process.

How about if I engage in a standard backup cloning to the destination drive and then using OCLP and ADD and INSTALL Monterey (again!) on top of that drive? and let that process occur. I succeeded previously going from Mojave to Monterey to THIS drive now. And the MacOS installer can make that drive bootable?
 
Last edited:
The only information I have is that "The APFS replication procedure failed."
Yes, this means that an error has occurred in the Apple APFS system replicator that prevents creating an intact copy of the signed system volume. This is the Apple seal that since Monterey ensures that system code is not tampered with. It requires perfect bit fidelity because the seal is a tree of hashes, similar to use of MD5 to ensure that distributed SW is not tampered with, but for the entire system (but not user files).

My only recourse is to, indeed, change the location of the SSD and see if that makes a difference? And if it works, then I'll have to switch it back to the PCI-e card and boot there.
Check for listed I/O errors as previously described.

It's amazing to me that CCC is probably the ONLY cloning software out there that does this service! Initially I thought just standard cloning of the drive and then adding an EFI file would be all I need, but that's not the case, the drive itself has be "made bootable" and CCC does that. Apparently the new file system structure that Apple added to newer OS drives is what makes this a difficult, specialized cloning process.
The "replicator" is an Apple utility that is invoked by CCC.

How about if I engage in a standard backup cloning to the destination drive and then using OCLP and ADD and INSTALL Monterey (again!) on top of that drive? and let that process occur. I succeeded previously going from Mojave to Monterey to THIS drive now. And the MacOS installer can make that drive bootable?
The better approach is to clean install macOS on your target drive, then use Migration Assistant to pull over all your user state from the old drive.

But if there's a chance the old drive is failing, you may want to you CCC in normal mode to get your data onto a known good drive first, because CCC's copier is tolerant of I/O errors and gives you a list of affected files. This makes sure you don't waste time with a failed migration, and you will know what files were affected by hard errors. There's a good chance you might care about them.

Best to you
 
Just to be clear, you are running an actual Mac?

If so, then use OCLP to do the clean install and go from there to recover per above.

* * * For anyone else reading this, OCLP is not a hackintosh tool and cannot make viable EFIs for hacks. Only for legacy Macs. If you read about OCLP on these forums, its only purpose to install older Wifi driver support — legacy Broadcom on Sonoma — via its "Post Install" capability.
 
Yes, this means that an error has occurred in the Apple APFS system replicator that prevents creating an intact copy of the signed system volume. This is the Apple seal that since Monterey ensures that system code is not tampered with. It requires perfect bit fidelity because the seal is a tree of hashes, similar to use of MD5 to ensure that distributed SW is not tampered with, but for the entire system (but not user files).


Check for listed I/O errors as previously described.


The "replicator" is an Apple utility that is invoked by CCC.


The better approach is to clean install macOS on your target drive, then use Migration Assistant to pull over all your user state from the old drive.

But if there's a chance the old drive is failing, you may want to you CCC in normal mode to get your data onto a known good drive first, because CCC's copier is tolerant of I/O errors and gives you a list of affected files. This makes sure you don't waste time with a failed migration, and you will know what files were affected by hard errors. There's a good chance you might care about them.

Best to you

Thank you so much for all your words! I did succeed going from Mojave to Monterey but avoiding Migration Assistant by doing it as an MacOS Installer upgrade. But in this circumstance I'm not going "up" to another OS, all apps and settings after using Migration Assistant will be the SAME, so I'll try the USB enclosure in one attempt and if that fails again, I'll do what you suggest. And yes, both drives are brand new Samsung SSDs (SATA and NVMe)!
 
BTW, if something is preventing CCC from unmounting the target drive, that will appear as an non-descript error. Given that the copy fails after only a few seconds, you might double check that something like file sharing or some other program isn't preventing an unmount.

At Terminal, you can use lsof to find out what processes have open files on a volume, which may be blocking unmount.

Re migration assistant, it can be used if you are just recovering to the same rev of macOS. It doesn't matter if you're not upgrading. But I don't think you can't go to an older rev.
 
Seems like very thorough description.

It would be great to have a bit more detail on 4. "copying an EFI" seems potentially fraught with the same issues you would have cloning any volume. How should we do this?

-Does creating a new APFS formated partition or volume automatically create an EFI partition?
-How do we "copy the EFI" to this new partition?
-Will CCC do this for us?
 
Back
Top