It’s Time to Move On from Bootable Backups

Article Comments
1

Originally published at: It’s Time to Move On from Bootable Backups - TidBITS

The latest installment in the story of how bootable Mac backups will eventually disappear started with a blog post by Shirt Pocket Software’s Dave Nanian. In it, he explained why SuperDuper could no longer make bootable duplicates on M-series Macs running under macOS 15.2 Sequoia, blaming Apple’s asr (Apple Software Restore) utility. This tool is the only way to create a bootable backup for M-series Macs.

I read Nanian’s blog post shortly before publishing the final TidBITS email issue of the year, so I only had time to write a short warning (“macOS 15.2 Sequoia Breaks Bootable Backups in SuperDuper,” 16 December 2024) and add a proviso to my suggestion in another article (“OS X.2 Updates Boost Apple Intelligence and More,” 11 December 2024) that now was a good time to upgrade to macOS 15:

Until Apple fixes the bug or we learn more about what’s going on, anyone relying on a bootable backup—as opposed to a data-only backup—should hold off updating or upgrading.

Such is the problem with deadlines. I was curious if the problem with asr affected other backup apps like Carbon Copy Cloner and ChronoSync, but no information was available at that point. However, now that the necessary details have emerged, I have updated my recommendation on updating and upgrading.

Tests Confirm Problems on M-Series Macs

First, I confirmed that the problem was real but limited to M-series Macs. On my Intel-based 27-inch iMac, SuperDuper had no problem completing a backup, and I was easily able to boot my iMac from that backup. However, when I tried the same backup on my M1 MacBook Air, SuperDuper failed quickly with the Resource Busy error that Dave Nanian mentioned.

SuperDuper failure

I also verified that changing SuperDuper’s settings to use the standard “Backup – all files” script with the Smart Update copying option successfully created a data-only backup of the M1 MacBook Air.

SuperDuper data-only configuration

Next up, I tried ChronoSync. It wasn’t encouraging to start, with its assistant warning me, “Note: Bootable Backups have been losing relevance on recent versions of Apple hardware and will eventually not be supported. You should consider creating a Data Volume Backup instead.” The app’s developers weren’t being alarmist. While I can’t definitively blame a bug in asr for ChronoSync’s failure, fail it did. Twice!

ChronoSync failure

Carbon Copy Cloner’s in-app text was similarly down on bootable backups, noting, “Creating a bootable copy of the source OS requires an Apple-proprietary procedure. CCC provides this functionality in a ‘best effort’ manner. Please click the ‘?’ button to the right to learn about the caveats associated with this procedure.”CCC also failed twice, though again, I don’t definitively know why. The destination SSD has worked fine in the past, and SuperDuper’s data-only backup to it completed with no errors, so I don’t believe it’s a hardware problem.

CCC failure

Regardless of whether asr caused these problems, such uncertainty is problematic when it comes to backups. I feel terrible for Shirt Pocket Software, Econ Technologies, and Bombich Software because they’re trying to provide a longstanding feature that users want—bootable backups—and they’re entirely at the mercy of Apple’s asr tool to do so. As we’ll see, Apple has relatively little interest in supporting bootable backups.

From the Horse’s Mouth: No More Bootable Backups

Shortly after I completed my testing, Mike Bombich posted a blog entry that shared information from a 2020 call with Apple. (He had missed the start of the kerfuffle, being away to help a family member when macOS 15.2 shipped.) As he outlines in the post, Apple made it clear that it was willing to address problems associated with making backups “as long as it did not require making a compromise to platform security.”

From Apple’s perspective, allowing system files to be copied inherently introduces opportunities for attackers to modify system components. Since macOS 10.15 Catalina, the separate system volume is immutable, locked, and validated using cryptography—what Apple calls the “signed system volume.” Any method that allows it to be copied onto a bootable drive must preserve the same verification to ensure nothing has changed.

To mitigate this move away from easily making bootable backups, Apple has invested a lot of effort into macOS Recovery and Migration Assistant. It is now trivial and streamlined to boot a Mac into macOS Recovery, install macOS, and restore user files using Migration Assistant. With a separate system volume, a reinstallation just creates a new, secured, immutable volume and then copies your user files to the data volume. Because Apple controls every part of that process, there’s no worry about the security of the system being compromised.

The other aspect of this topic is the value of an external boot drive to an M-series Mac. While Macs with Apple silicon allow booting from external drives, they remain dependent on their internal storage during that process, as Glenn Fleishman wrote in “An M1 Mac Can’t Boot from an External Drive If Its Internal Drive Is Dead,” 27 May 2021.

The fresh information here is that an M1-based Mac relies on its internal SSD to allow external drives to boot. If the internal SSD has failed or been entirely erased—it contains several hidden volumes—you can no longer boot from an otherwise valid volume on an external drive. Why would Apple do this? To increase security.

Mike Bombich closes his post by explaining that Carbon Copy Cloner will continue to support the Legacy Bootable Copy Assistant because it remains useful for Intel-based Macs. But he stresses that no one should base their backup strategy on bootable backups. While Apple may fix the asr bug, the writing is on the wall, with Bombich saying:

Apple made it unambiguously clear that “bootable backups” and System cloning are fundamentally incompatible with platform security.

I’ve been preaching the need to move on from bootable backups since early 2021, when I wrote “The Role of Bootable Duplicates in a Modern Backup Strategy” (23 February 2021). A slightly updated version of the backup strategy I recommended in that article would include:

  • Versioned backup: Everyone should make versioned backups using Time Machine to an external drive, preferably an SSD for higher performance and lower environmental noise. Versioned backups are essential for recovering from corruption or inadvertent user error by allowing you to restore an earlier version of a file, a deleted file, or the contents of a deleted folder. Other apps can make versioned backups, but Time Machine backups are particularly useful because of how Apple integrates them into macOS. It’s a quick process to go back in time and select files, folders, or volumes—though the interface is archaic and awkward—and Time Machine snapshots are the basis of migrations and system restores. Time Machine is far from perfect, but it has insider access to technical and security changes in macOS and generally works acceptably.
  • Internet or offsite backup: Local backups are worthless if all your equipment is stolen or damaged by fire or water. Historically, the recommendation was to rotate backup drives offsite, but in the modern world, an encrypted Internet backup service like Backblaze is much easier.
  • Nightly data-only duplicate: Data-only duplicates can still be a worthwhile part of your backup strategy. Duplicating your data every night adds diversity by relying on different software if Time Machine falls prey to bugs, putting a backup on another external drive (don’t configure Time Machine and your duplicate to share a drive), and eliminating the need for special software to restore data. Plus, if you have to switch to another Mac, a duplicate would quickly let you get back to work on your files.
  • Cloud-based access to key data: Cloud storage is a weak form of backup, and it’s not a required part of a backup strategy because some people can’t or don’t wish to store data in the cloud. But, for many, cloud storage is an excellent way to access essential data from any device or location—and it may offer you a last-ditch way to retrieve lost files. For instance, $9.99 per month gets you 2 TB of iCloud Drive storage, and Apple’s Desktop & Documents Folders syncing feature could make it particularly easy to get back to work on another Mac. A similar amount of money would provide 1 or 2 TB of storage on Dropbox, Google Drive, or Microsoft OneDrive.
  • Backup Mac or another device: Given how hard it is for anyone but Apple to repair Macs, if you can’t afford days of downtime, think about what device you could use for your work if your Mac were to fail and how you’d get your data to it. It might be a laptop you mainly use when traveling, your previous desktop Mac, or even an iPad. Just be sure to take your backup device out for a test run before you need it.

I realize that most people won’t have all five of these, so if you have to choose, I recommend Time Machine paired with Backblaze to protect against disasters that would affect your Mac and Time Machine drive. But whatever you do, please make backups. Losing data is a matter of when, not if.

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.

9 Likes
2

More than that. It’s the only way for Intel Macs running macOS version 11 (“Big Sur”) and later.

Very interesting. This tells me that this may actually be an ASR bug, and not a design change. If it was deliberate, then I’d expect it to fail on Intel systems as well.

Especially since (according to the SuperDuper screen-shot) the error occurs when duplicating the Data volume, not the System volume.

I also find it interesting that the error is “Resource Busy”, which usually means that the device is in use by something else. I wonder if there might be a way to install SuperDuper (or one of the other tools) to the Recovery volume or to an independent volume (not the system’s Data volume), and run it from Recovery mode where (hopefully), the system’s System and Data volumes are not mounted and should not be in use.

Of course that would be really awkward and inconvenient. Nobody wants to have to boot an alternate OS in order to run a backup. But I wonder if it would work.

Of course, ASR is an undocumented system utility and is meant for use by Apple for installing the initial software image on newly-manufactured Macs, so they have little motivation to fix a bug that doesn’t impact that use-case.

2 Likes
3

What would be the best approach for a “nightly data-only duplicate” over a network? Arq or ChronoSync to a folder in a drive mounted over a network? Or to a disk image on a network drive?

4

@seanp

Carbon Copy Cloner has a great feature called “Remote Macintosh” that I use for this purpose. It requires that the backup destination be a Mac, but what it does is it backs up directly to the remote filesystem using rsync, copying all file attributes.

This works great over a local network and also over the internet. In my case, I have an 8 TB SSD connected to a Mac Mini in a closet. Carbon Copy Cloner backs up my MacBook Pro daily to the SSD over the network. This is a complete backup of the Data volume, and is fully compatible with Migration Assistant. I can simply plug the SSD into any Mac and do a full restore using Migration Assistant.

CCC doesn’t natively support versioning using this approach, so what I’ve done is write a simple shell script to create an APFS snapshot on the remote SSD after every backup completes (I create them using CCC’s Snapshot entitlement, so they are independent of Time Machine snapshots and won’t be pruned by macOS).

3 Likes
5

I use Carbon Copy Cloner to perform a “data only” back up to a Synology NAS RAID over night. Works well.

1 Like
6

Thank you and very kindly both for that insight on your uses of Carbon Copy Cloner and also for clarifying the notion of copying the “data volume” and not some more abstract notion of “data-only backups” (e.g., the home directory). CCC sounds very workable.

Just one or two follow-up questions: can ChronoSync or SuperDuper do a data-only clone, since I already own both? An option to clone only the data volume in SuperDuper wasn’t obvious but perhaps I’m missing something. And in either case, might they also be able to natively also copy the APFS snapshots (nice, but not essential, since this backup is already on top of both Time Machine as well as remote, versioned backups).

1 Like
7

The “nightly data-only duplicate” is to have a copy of the data ready to use - that must be folders and files really accessible to the backup Mac.

Arq is ruled out because it backs up to a different structure which would require a restoration step.

CCC would do it, but its performance is limited by using SMB to mirror data to the backup destination.

Chronosync (CS) is faster as it uses its own network protocol to connect to a Chronosync Agent running on the backup Mac. I would definitely prefer CS with its agent to CCC.

Both CCC and CS need to be scheduled. For instant (a few seconds) synchronisation, I would use Resilio Sync to send data (documents, photos, etc.) to the backup/secondary Mac.

Note that I consider the "nightly data-only duplicate” (preferably more often or continuous) to be most useful with the “Backup Mac or another device” strategy.

1 Like
8

Do System Preferences reside on the System volume or the Data volume?

1 Like
9

My understanding is that the System Volume contains only the contents of /System and possibly some of the Unix-specific folders such as /bin and /sbin. Everything else that the Finder shows as being on your boot drive should be on the Data Volume.

Most settings in System Preferences will be stored in ~/Library, with those that affect multiple or all users residing in /Library. None of them should be in /System, which should get modified only during system updates.

3 Likes
10

Thanks Marquelle. It’s always the prefs which take the longest time to (re)build so if they’re on the Data Volume they should all come across with a Migration or restore.

11

I use SuperDuper and it failed (as expected) to do the ‘Erase then copy all files’ of 15.2 on my M1 MBPro. The advice is to do an ‘Erase then copy’ after a major system update ie; 15.1.1 to 15.2. I sent the log to Dave Nanian and he replied (very quickly) that this was the error he mentions in his latest blog. He suggested I do a ‘smart update’ instead. I reformatted the external SSD then did as he suggested. This went through without any problems though I haven’t tried using any of the data on that backup.

12

So, according to the CCC documentation, backups to a NAS are not compatible with Migration Assistant:

First and foremost, backups to a NAS will not be compatible with Migration Assistant, and they do not support backup versioning. If you want those benefits in your backup strategy, you should use NAS storage only as a secondary backup. To create a backup of your startup disk that is compatible with Migration Assistant and supports backup versioning, configure a task to back up to locally-attached storage (e.g. a USB hard drive attached to your Mac).

Source: https://support.bombich.com/hc/en-us/articles/20686464585239-I-want-to-back-up-my-data-to-network-attached-storage-NAS

I wonder if the use of the term “NAS” Is very specific and does not similarly affect a drive shared over a network from a Mac Mini? Or if it does, how are the folks in this thread using CCC over a network addressing this issue?

13

I went with data-only backups when the data volume became a thing and CCC supported it. In the preceding years, I think I used a bootable backup, both personally and professionally, a handful of times and most of those were for testing/verification.

Now, if I could only get Recovery to re-install the version of macOS I want….If I have Sonoma on a system, it appears to be hit or miss if I get Sonoma or Sequoia currently. I’ve read Apple’s info about Recovery, but nowhere do they specify how to accurately choose an OS version. It would be useful to have a pop-up which might read something like “Your Mac supports these macOS versions:” and have a list from which to select the version to install. OTOH, this might be too complex for some people or they’ll install an older version, so maybe the list could be gated to only allow the currently installed version or newer, unless you held down Command-Option or a similar set of keys to display all possibilities.

But, back to trying to reliably get a version, does any of the assembled wisdom here have a way to figure this out? I’ve read Apple’s articles & guides as well as a number of other sites (especially Howard Oakley’s excellent eclecticlight.co) and haven’t found a solution.

14

Ah, good catch. I was so focused on the fact that only M-series Macs failed to boot that I conflated the two facts. I’ll fix.

1 Like
15

Given all of the above I see little reason to even keep my data on the internal SSD of any Mac running Mac OS 15.0 and beyond.

Lonnie King

16

I think you’d see a substantial performance decrease if you kept all your data on even the fastest external SSD, if that’s what you meant to imply.

17

There may be some performance decrease, but “substantial” is in the eye of the beholder and will depend greatly on what kind of data you’re actually dealing with.

For example:

  • A media collection used mostly for playback (e.g. Music, TV and Books apps) probably won’t see any decrease, because all but the slowest storage devices will have no problem keeping up with the data rate of the media.
  • Apps that load the entire document into memory when working (e.g. text editors and most office apps), won’t see much decrease. Load/save times might be a little bit slower, but other operations should see no difference.
  • Apps that perform a lot of file I/O during normal operation (e.g. Photoshop, iMovie, some database apps) will see a distinct performance drop. The amount will depend greatly on the size and complexity of the document/database being worked on.

My recommendation for those who can’t or don’t want to keep documents on internal storage is:

  • Move archival files (those that have not been edited recently) to external storage.
  • Move playback-only media files (music, movies, books, etc.) to external storage.
  • Move trivial-sized documents to external storage.
  • Keep active databases on internal storage.
  • Use internal storage for temporary-file storage for apps like Photoshop (which lets you specify the location for temporary files).
  • For media editing, keep the project on internal storage while work is in progress. Move it to external storage when you’re done with it.

Don’t install apps to external storage. In addition to potentially impacting performance, you don’t want the apps to become unavailable if external device is unavailable (e.g. unmounted, powered off or disconnected).

The above is applicable whether the external storage is an SSD or HDD. And you will see a much more significant slowdown if it is an HDD. But (depending on the app and document in question), the slowdown may or may not be acceptable to you.

2 Likes
18

FWIW I’ve had many external drives fail without warning, including SSDs. I’ve never had an internal Mac SSD fail, going back to a 2014 Mac mini (still using it) and 2015 MacBook Air (still using it, occasionally.)

19

Update: Carbon Copy Cloner does support backups over a network to a remote Mac that are compatible with Migration Assistant:

Source: https://support.bombich.com/hc/en-us/articles/20686445637655-Using-CCC-to-back-up-to-from-another-Macintosh-on-your-network

1 Like
20

A problem with the Recovery + Migration method is it takes two external hard drives:

  1. Use Recovery to install macOS on to an external drive. This is drive A.
  2. Migration Assistant to import the data-only backup from drive B to drive A.

Sure, you could install macOS onto a partition on the backup drive, but then the backup drive would have to be twice as big as your data.

Compare to the bootable backup method:

  1. Boot from your backup.