Sorry to hear that. . . It works on my 2018 Mac Mini (APFS internal drive) and Mojave. I enter Time Machine and the recent local files are accessible at the bottom of the TM grid under “Today.” Anything later than that is not visible. (It may display differently when using a newer Mac OS versions.)
If you are using a Mac OS Extended (HFS+) formatted internal drive, it only works on laptops and when you have Time Machine enabled.
CCC 6 works on Mojave? According to the Bombich web site, minimum requirement is Catalina. Or do you mean Time Machine?
Not CCC, the internal snapshots feature that I described in my replies to Walter. . .
I completely agree, let us support independent and clever developers like Mike, very appreciated!
Since I’m limited to MacOS 10.13.6, I’m SOL on CCC from now on.
You should be fine. From the CCC download page (directly below a button for downloading CCC 5):
Carbon Copy Cloner 5 is compatible with Yosemite (10.10), El Capitan(10.11), Sierra (10.12), High Sierra (10.13), Mojave (10.14), Catalina (10.15) and Big Sur (11.*). Note that while this version of CCC may work on OSes newer than Big Sur, we recommend that Big Sur+ users upgrade to CCC 6. We offer technical support for CCC 5, but we are no longer actively developing it. If you are having trouble downloading CCC from the link above, try this alternate download location.:
Sorry for the delay in replying as I just moved. Yes I have CCC 5 already; I meant I’m SOL regarding CCC 6.
But is this really a problem? If you’re running 10.13, then CCC version 5 has no problem making bootable backups.
Yes, version 6 has changes that make it a bit faster, but I don’t think you’re missing that much by sticking with version 5.
I love how the developer devotes hundreds of words on his website dancing around the loss of essential functionality of his software on Big Sur & M1 Macs. He actually says he was “stoked” at no longer needing to support the “logistical idiosyncrasies” of bootable backups.
Yes, bootable backups are a discussion point for sure.
I haven’t gotten around to reading it yet (I’ll likely upgrade my older version when the second round of M-series chip’d machines arrive!), but Joe Kissell’s new book “Take Control of
Backing Up Your Mac, 4th Edition (2021)” does some explaining here:
Also see/listen here, where he talks about it:
https://www.takecontrolbooks.com/blog/joe-kissell-talks-mac-backups-on-macvoices
;-)
EDIT: And this article/forum page:
I’m now at 6.0.2, and no problems - major speed improvements are very welcome.
Many thanks to Bombich - their deep knowledge of the OS is apparent, and massively reassuring.
I really hate the direction that Apple are taking with this. We’ve run Mac servers at our publishing company for over 25 years and our standard procedure was to have data on attached drives and our servers all have clones. In the event of a server failure we simply boot another Mac from the clone, plug the data drives in and we’re up and running again within a couple of minutes.
I’m not sure where the OS Sharing information is stored on Big Sur but if it’s inside the fenced System it’s going to be impossible for us to keep a copy of our User permissions and Shares. Bootable clones have saved us many times in the past, I’ll be disappointed to see them go.
Although not as convenient, there is still a workaround.
Instead of cloning the entire system, you should instead:
The result should be a bootable system containing all of the user data (including accounts, preferences, apps, etc.).
The only files that belong to the sealed System volume are files that never change after system installation (since any change to any file there would require un-sealing it, re-certifying the contents, and then re-sealing it). The System volume only changes when a macOS system installer runs.
Any and all system configuration (including sharing) will be stored as a part of the Data volume, where “normal” security measures (file permissions, SIP, etc.) apply.
The only issue here is that when system updates are installed, the only way to apply them to your bootable backup is to boot it and run Software Update from there. But you don’t necessarily have to do this. Any of the following should work fine:
Never update the system volume on your backup. If your internal storage fails, you won’t be running from that backup. You’ll boot it and then use it to re-image your internal storage (assuming you could replace it) by installing macOS, then restoring the Data volume.
Occasionally update the system volume. When you think it appropriate (maybe by a calendar/schedule, maybe after a major OS release), boot the backup and run Software Update to bring its System volume up to date.
Only update the system volume when you need to start using it. If your internal storage fails, boot the backup and run System Update to bring its System volume up to date. Then use it as normal until you can replace the computer or its storage device.
To do this, should the external drive be formatted into two volumes (as I understand the internal drive is)? Would the installer do this automatically, if it’s appropriate? If I were to do this (big if), I would use an external solid state drive with APFS. Would the instructions be different for someone using a spinning platter drive?
I don’t doubt you, but it seems odd that one could install macOS onto an external (non-boot) drive but not install a macOS update onto an external (non-boot) drive.
Thank you for the above and all your other knowledgeable posts.
I don’t have personal experience with installations like this. I’d recommend reading Howard Oakley’s article on the subject.
The most important takeaway is that you are pretty limited if you try to just run the installer application (after downloading it). You should be able to run it if you want to install a version of macOS that is the same or newer revision than what is currently running, but trying to install an older version may likely fail with a cryptic message about the installer being broken.
To make sure the installer works, no matter what the version of the currently-running OS may be, it’s best to make a bootable installer, boot that, and run the installation from there. Or maybe run the installer from Recovery mode (but that is also pretty restrictive about what versions you can install).
You will need to partition the new device (as GUID) and format it as APFS (which will create the container), but I don’t think you should create any system volume. The installer should do that. It’s unclear from the article if the installer will create a new data volume or if it will use the existing volume for that (binding it to the system volume). Either way, you should be fine because all volumes that share an APFS container share the same free space. If you end up with a leftover empty volume at the end, you can just delete it with Disk Utility.
Unfortunately, I don’t know for certain. I have only read about this procedure.
WRT updating, the reason why you need to boot the clone should be obvious - the System Update utility in System preferences only updates the running system.
I don’t think you can just download an updater and run it against a different installation. At least nobody has talked about this. I suspect it is because you need to unlock and then re-lock the signed system volume and it’s probably not possible for other installations to do that. At least that’s my understanding.
You only need to partition first if you’re doing multiple computer backups to the same drive…and SSD vs spinning drive is no difference.
I don’t recall if the combined updates you can download will only update the boot volume or not…but it seems like it would since it’s essentially an installer just like the x.0 installer is.
Thank you for the thorough, informative and reasoned response. Given what you’re saying it would appear as long as we have an up-to-date data volume backup we should still be able to boot another machine from its ‘fenced system’ and be able to be up and running. I guess the key question is how intrinsically linked are the data and ‘fenced’ volumes. IOW, will it ‘just work’ if attached to a new machine or will it need to be restored?
My other curiosity is where Apple is going with fairly standard *nix packages like FTP, Apache, PHP etc. I’m guessing they’re going to be deprecated which will leave us reliant on either building ourselves or using Homebrew/MacPorts installs which (I assume) would now reside on the data volume.
It makes me miss the old days when OSX Server was a serviceable product which could comfortably run a reasonably sized business without needing IT specialists - sigh…
CCC 6 has a built-in integrity checker too! It checksums all your files. So if you have a bit decay on you hard drive, it knows! And it knows whether the backup or original is bad.
If I understand what you’re saying, that existed in CCC 5 and was called Find and replace corrupted files. The user could choose to have CCC perform this check never, once a week, once a month, or every time the task ran.
I don’t know that CCC 5 had that capability, but I’m a pretty simple user.
Bombich is nothing if not verbose, but bottom line CCC is best left for cloning the Data volume. For example, if the Mac’s internal drive is damaged, it will not boot from a cloned drive at all. Apple has made accepted methods obsolete at worst and confusing at best.
The absolute best source of information on these issues is the multitude of articles by Howard Oakley, as David C. mentions above: