macOS 15.2 was released a few days ago, with a surprise. A terrible, awful surprise.
Apple broke the replicator. Towards the end of replicating the Data volume, seemingly when it’s about to copy either Preboot or Recovery, it fails with a Resource Busy error.
…
Because this is their code, and we’re forced to rely on it to copy the OS, OS copying will not work until they fix it.
I haven’t seen any comments about how this affects Carbon Copy Cloner or ChronoSync, but if the problem is in Apple’s asr (Apple Software Restore) tool, those apps would likely be similarly affected. Until Apple fixes the bug, you can protect your work with a data-only backup of everything except the system, as I wrote in “The Role of Bootable Duplicates in a Modern Backup Strategy” (23 February 2021). In the event of a disaster, you would reinstall a clean version of macOS and then restore your data with Migration Assistant.
And if you must have a bootable backup, you can follow Mike Bombich’s recommendation to make a backup of the Data volume and then install macOS (from an installer image) over that backup, to make it bootable.
Not as convenient as having one app do all the work, but it will produce the desired result.
Subsequent (incremental) backups will only update the Data volume, but you can boot the backup and run Software Update to update the system volume.
Note the restriction: you can only do this to a non-encrypted APFS volume.
On Intel, I’ve successfully done it the other way: install macOS on to a volume, then clone the Data volume over it. But I don’t know if that will work with Apple Silicon, where you get into the issue of “ownership” of the startup volume.
Copying Apple’s system is an Apple-proprietary endeavor; we can only offer “best effort” support for making an external bootable device on macOS. We present this functionality in support of making ad hoc bootable copies of the system that you will use immediately (e.g. when migrating to a different disk on an Intel Mac, or for testing purposes), but we do not support nor recommend making bootable copies of the system as part of a backup strategy.
Please bear in mind that you can restore all of your documents, applications, and system settings from a standard CCC backup without the extra effort involved in establishing and maintaining a bootable device.
I will admit to some real uncertainty here. I felt that this was important news to get out when I came across it shortly before the issue deadline, but I haven’t had a chance to contact either Mike Bombich or Dave Nanian to learn more.
Although I’ve been making bootable backups of my 2020 Intel-based 27-inch iMac with SuperDuper for a long time now, I haven’t checked to see if they will actually boot it. And my understanding is that it’s entirely different on M-series Macs.
Since updating to Sequoia my Time Machine backups “fail”. I get a message saying “Backup Failed”. I have two SSD’s and when the first one said it failed I used my other and got the same error. But if I go to Time Machine settings I see both have a date range that covers the day I made these backups. Any chance these are related this issue with SuperDuper?
I’ve been having Time Machine backups fail since Sonoma. I have two TM backups and sometimes only one fails and sometimes both fail. But whenever they fail, I open Settings, right-click on the backup and choose “back up now” and it backs up and starts working again automatically for some period of time. Since the 15.2 update, it hasn’t happened (yet). Knock wood.
I also have a bootable clone. I created it by running the OS installer on a CCC clone backup (which is what Bombich recommends). I have used both CCC and SD! to run the backups. Since updating to 15.2 I haven’t tried to boot from it, but it still shows up as a choice in Settings—>Startup Disk, so I assume it stil works. I’ll find out when I find time to update its OS to 15.2. It shows up as a 15.1.1 system, although I’ve done CCC backups to it since updating. I haven’t done an SD! backup to it since updating.
I can’t see how, given that the SuperDuper problem is with asr, whereas Time Machine doesn’t copy the system files or attempt to make a bootable backup. I have seen a few complaints about Time Machine with macOS 15.2, but they seem unrelated.
The asr bug apparently also affects making bootable backups of an Apple silicon Mac using a Synology NAS. From a list I’m on:
I just spoke with Synology support, who confirmed that the failures I have been seeing in the Active Backup for Business Mac Agent are due to the same issue.
The client runs correctly on my 2018 Intel Mac mini also on MacOS 15.2.
Just looked into my CCC (not current 7x version…I need to update) and its backup seems ok.
However my TimeMachine to a networked Timecapsule… ALL backups are gone!*** Except last one. I have a 4TB drive and there should be atleast months of backups and… nothing there.
I’m on a Mac Studio mac M2 silicone with 15.2.
***WAIT. Now I just revisited Browse my Time Machine Backups (its doing one right now) and I see All the back ups again…To November 2022… Scratching my head.
And now BackUp Failed message after some time away.
Edited.
So I ran the TM again, and it Shows it done. I watched the progress. I also screenshot the Browse Time Machine… and while backing up, it showed all the intervals back to Nov 2022. But once done, I revisited and it now only shows till Today with the backup archive labeled “Data@snap3073876”
Thanks Apple. TM is broke.
UPDATE: so I am thinking its not broke but really slow to see my TimeCapsule and its index. Because when I select Browse Time Machine… its only showing last backup…but if I wait up to 2 minutes…the side will then populate with the backups from 2022 to present. I’m on Gigabit so the only thing that has changed is the OS update.
Foreboding to me to figure out new networking solution for backups! (TimeCapsule is old…)
I disabled TM to network destinations a couple years back as being completely unreliable amd therefore broken although it does work to local drives. Setup CCC tasks using the Remote Mac destination option and they are bulletproof as well as being Finder readable instead of .dmg images.
@bombich has now posted on the CCC blog with an extremely helpful explanation of why bootable backups may limp along for a while, but will never be fully supported. The core problem is that platform security is Apple’s top priority, and even with asr doing the copying, the possibility for security being compromised exists.
I’ll just add that even though I originally purchased CCC for its bootable backup option, CCC remains a valuable utility for me even though it is now intended for data backups only. Why? Mainly because I maintain two data backups, one Time Machine and one CCC (for risk management), and because Bombich Software has a good record of updating the software and of supporting users through both an online knowledge base and direct contact.
Bombich’s post clearly and understandably explains why bootable backups for Apple Silicon Macs are a waste of time and energy.
Ever since Apple sealed the system volume, I have considered it part of the system firmware; it’s the supplier’s responsibility to maintain it and see that my apps and data work with it.
It is a good idea to have two independent backup strategies like TM and SD or CCC.
But that 2nd backup, at least on an Apple silicon Mac, does not have to be bootable.
The writing has been on the wall for bootable clones. And as much as cloning and booting any Mac from a clone has been a great Mac feature for a long time (and yes, we bemoan its demise), times change and circumstances change and what once made sense is perhaps indeed no longer the right path forward. I used to do and rely on many bootable clones, I no longer do. And I agree with Apple that overall security trumps the inconvenience of having to go Recovery + MA vs. just clone and boot from that. IMHO what we gained from going Apple silicon and SSV by far makes up that minor convenience penalty. Obviously, that’s just my personal opinion so YMMV.
How does asr copying the System volume compromise security? It still is a signed-sealed-volume, and won’t boot if it doesn’t pass the cryptographic hash checks.
Thus, I don’t see how creating a bootable clone is any less secure than installing macOS on an external volume. You’re guaranteed to get the same result either way. If there was some way to intercept and change what’s written to the volume, you could do the same for a macOS install.
I’m not a security expert like @rmogull, and I have no inside information, but we’re assuming that asr has the same level of security checks as the macOS installer, which may not be true and may not even be possible. After all, the macOS installer is a coherent app that contains its own data, so it can maintain cryptographic consistency throughout. In contrast, asr is reading data from what is essentially an unknown source. We might know it’s a signed system volume, but we don’t know if asr has the same knowledge. And even if it does, because asr is reading local data, it’s conceivable that an attacker could somehow get between the data and asr to insert malicious code or tamper with the system integrity.
This is all very theoretical, and while I’m sure Apple works to ensure these sorts of things don’t happen, the security engineers must be aware of the possibility of attack vectors. Plus, as Mike Bombich said, Apple has invested a lot of effort into Recovery Mode and Migration Assistant to be able to ensure that users can perform clean installs of macOS that are verified and signed. From Apple’s perspective, there’s little benefit in maintaining two approaches to the same end goal (bringing a clean Mac back to a fully functional state), and having two merely increases the attack surface.
