macOS 15.2 Breaks Bootable Backups

Dave Nanian (Mastodon, 2, Hacker News):

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.

In the past, Resource Busy could be worked around by ensuring the system was kept awake. But this new bug means, on most systems, there’s no fix. It just fails.

[…]

Since Apple took away the ability for 3rd parties (eg, us) to copy the OS, and took on the responsibility themselves, it’s been up to them to ensure this functionality continues to work. And in that, they’ve failed in macOS 15.2.

I wonder if this is related to the problems I’ve been having since Sequoia where I can’t cleanly eject drives, e.g. after making a non-bootable backup. Finder will show a spinner for a while and then offer to let me Force Eject even though Sloth and other tools show no open files.

Bri:

It pains me to see the authors of good software like SuperDuper! just having throw up their hands and say there’s nothing that can be done, because Apple broke our shit and there’s no way to work around it since they intentionally locked down the system and made it impossible for us, the users, to do what we want.

Remember when copying a system was as simple as just copying the System Folder to another drive? How far we’ve fallen.

Previously:

• macOS 15.2
• Use a Cloned Drive to Recover From Mac Failures
• Time Machine in Sequoia
• SuperDuper 3.9 Beta
• Finding Open Files
• The Role of Bootable Duplicates in a Modern Backup Strategy

Update (2024-12-18): Adam Engst:

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.

See also: MacRumors.

Dave Nanian:

Unfortunately, the first Developer Beta of macOS 15.3 does not fix Apple’s replicator problem, which still fails with “Resource Busy” at the end of its operation.

For Apple folks, again, this is FB16090831. It seems to only affect Apple silicon Macs.

Update (2024-12-19): I continue to see reports of Time Machine problems with macOS 15.2, but these seem to be separate issues, perhaps related to SIP rather than ASR.

Bombich Software (via Adam Engst):

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.

See also: John Gruber (Mastodon), Reddit, Apple Discussions.

Mike Bombich:

While some developers seem surprised by a change in macOS 15.2, we’ve known for several years that making bootable backups would eventually become impossible.

[…]

Participating in that (Dec 2, 2020) conference call was the APFS team lead, someone from Developer Technical Support, and to my surprise, Apple’s Director of Product Marketing. When I joined the call I was prepared for a technical discussion of what was broken in ASR and whether Apple would be able to fix those issues and make it reliable enough for a commercial backup solution. The call didn’t quite go in that direction. The Marketing Director kicked off the call by asking:

So how would it look if someday in the future you simply couldn’t make a copy of the System at all?

He (and the more technical folks on the call) went on to explain why only ASR could be allowed to copy the system, and that they were committed to addressing any problems with it as long as it did not require making a compromise to platform security. Platform security is a top priority at Apple, and one of the keys to that security is a Secure Boot environment — without compromise. Allowing system files to be copied introduces an opportunity for attackers to modify key system components. Some of this can be mitigated by only allowing Apple’s ASR utility to make the copy, but there are still inherent opportunities to inject changes when copying system files.

There’s nothing like documenting changes in strategy through private conference calls. Now we are in a weird situation where ASR was included in Sequoia but no longer works, and we don’t know whether Apple intends to fix it.

Also, I don’t think this is a good security tradeoff. I don’t understand exactly what the threat is. Who is going to modify the encrypted clone drive that’s sitting in my office and force me to boot from it? (If they can do that, I have much bigger problems.) What could be modified without detection given that the system volume is signed? The problem with Migration Assistant is that it takes a long time. With a bootable clone, I can be back up and running in a minute or two. And this would just be a stopgap: I would eventually migrate back to the internal storage so the security risk would only be temporary.

Update (2024-12-23): Adam Engst:

Finally, let’s return to the question of updating or upgrading to macOS 15.2 Sequoia. Assuming you’re willing to change any bootable backups to data-only backups, I think it’s safe to proceed.

But be careful if you’re using Time Machine. I and others have seen some serious problems such as incorrectly pruning large quantities of old backups, errors completing Time Machine backups, and backups not running when you aren’t at the Mac. I would keep at least one Time Machine drive with old backups not connected to a Mac running Sequoia.

Update (2025-01-02): John Siracusa has the same take as me, that bootable backups are still useful because they save time and that it’s not clear why copies made by ASR (Apple code copying a signed volume) would be insecure.

Riccardo Mori:

This gradual move away from bootable backups is part of Apple’s Mac OS lockdown procedure, as I’d like to call it. It’s all disguised as providing users with hardened security for their Macs, while effectively limiting their choices when it comes to managing machines they purchased and own.

[…]

I only have anecdata, but several people in my circle of friends and acquaintances have told me their experience with Migration Assistant — especially with recent Macs — hasn’t been smooth at all, citing freezes and failure to transfer all the expected data. And it’s not as fast as having a bootable cloned disk at hand in case of catastrophic failures. Well, in case of a catastrophic failure, like your Mac’s internal SSD dying, you obviously can’t transfer anything. Unless you have some backup lying around, you’re done.

Unfortunately, even with a bootable backup, Apple Silicon Macs won’t boot at all if the internal storage doesn’t work—again prioritizing security at all costs.

Whatever your opinion on this whole matter, there’s an unescapable fact — recovering from a serious hardware failure or data loss used to be faster and simpler than it is now. Did it involve a lesser degree of security? Theoretically, yes. In practice, we accepted the security trade-off of being able to use a quicker, more ‘open’ procedure to get back on track instead of having to jump through largely overkill security loops that ultimately create a lot of friction and encumbrance for the end user. A user who’s simply dealing with data loss or hardware failures, with reasonably near-zero risk that ‘some attacker’ may target their machine or information.

Backup Bug Mac macOS 15 Sequoia Sloth Storage SuperDuper

6 Comments RSS · Twitter · Mastodon

---

---

---

---

---

---

Leave a Comment

Name

E-mail (will not be published)

Web site

Δ