John Gruber has a long, thoughtful piece at Daring Fireball about the complications (and relative importance) of creating bootable backups in the modern Mac era (triggered by a now-fixed Apple bug):

I don’t think anyone would dispute that “creating a bootable startup drive clone” has gotten complicated in the Apple Silicon era, which began with MacOS 11 Big Sur in late 2020. Not to mention the complications that were introduced with the switch from HFS+ to APFS with MacOS 10.13 High Sierra in 2017, and the read-only boot volume and SIP with MacOS 10.15 Catalina in 2019. M-series Macs boot weirder than Intel-based Macs. Not bad weird. I think it’s all justified in the pursuit of security (SIP stands for System Integrity Protection, and is aptly named) and elegant system architecture. But booting is now makes-things-much-more-difficult-than-before weird for tools like SuperDuper and Carbon Copy Cloner.

He goes into deep detail about how bootable backups work with SuperDuper, his backup tool of choice. (For what it’s worth, my preferred app has long been its “archrival”, Carbon Copy Cloner, which I’ve been using—and recommending—for at least two decades, though the earliest reference I can find to it is a 2008 post on my now-defunct personal blog. I also worked with the author, Mike Bombich, when we were both at Apple.)

Gruber concludes:

Having my SuperDuper-cloned backup drive be bootable is nice to have, but I really can’t say I need it any more. 20, 15, even just 10 years ago, that wasn’t true — I really did want the ability to boot from my backup drive at a moment’s notice. But that’s really not true any more for me. It probably isn’t for you, either. It definitely isn’t true for most Mac users.

But it remains true for some people, who are using (or responsible for) Macs in high-pressure tight-deadline production environments. Live broadcast studios. Magazines or newspapers with a deadline for the printer that’s just hours (or minutes) away. Places with strict security/privacy rules that forbid cloud storage of certain critical files. If the startup drive on a production machine fails, they need to get up and running now. Plug in a backup drive, restart, and go. Anything longer than that is unacceptable.

I agree with Gruber broadly: I was also once a “bootable backups” guy, and I too haven’t used one in at least a decade. And certainly production environments need fast recovery options to handle time-critical failures.

But booting from a backup drive “at a moment’s notice”? Well, that’s just straight-up bananas!

OK, let me be clear: Gruber is a smart and technically savvy fellow, and I’m confident he doesn’t mean it the way I’m (overly dramatically) interpreting it here. But let me state for the record:

A backup you boot from is no longer a backup. It is now a production device.

(I’d originally added to the end of that, and the sole copy of your data, but that’s not necessarily true (and certainly not what Gruber meant). In an environment like what Gruber describes, there would (should!)never be a “single backup” of critical data. The backup drive that you plug in, restart, and go would likely be one of multiple such drives, kept up to date and designated as, effectively, a “hot spare.” In fact, I’d wager most such environments go beyond mere data redundancy, to device redundancy: Backup computers, not just backup data.)

I spent a significant part of my early career working in technical support and as a sysadmin at various magazine publishers, and later, in early web publishing at marketing companies and advertising agencies. Among other things, I was the person responsible for creating and implementing backup policies. Part of that was having options for handling critical path failures—recovering quickly when computers or drives failed.

Bootable backups were part of that process, but not in the way Gruber appears to imply. We’d never use a backup as a boot drive without having another copy of that drive.

Whether we were continuously making that second backup, or made it at the time we needed it, we always ensured that a second backup existed before we attempted any recovery. The last thing we wanted was to screw up the backup too.

The only time I would use a bootable backup drive directly—without making another copy—was if I specifically made it to boot from it. This wasn’t a backup in the traditional sense, but a clone, a snapshot from which to work. It wasn’t a hedge against the future, but a way of replicating a system to work on now. In this scenario, it didn’t matter if I screwed up the bootable backup, because the data still existed and could be re-cloned.

To be very clear: In the production environments I worked in, we would never use the current and only backup to recover and keep working (or as Gruber put it, to “get up and running now”). Our data was as important as our deadlines, and we invested the necessary time and money into systems that allowed fast recovery without sacrificing either.

One standard process we implemented was having boot partitions and data partitions. We created bootable recovery drives—so computers could be used if the boot partition failed—and separate datadrives, with backups running to those as often as the amount of work we were willing to lose. Thosedrives were themselves also backed up near- or offline.

For any “critical path” data or systems, we also kept “hot spares”—devices we could press into service at a moment’s notice. These were maintained as if they were in active use, because at any moment, they could be.

Rebuilding a Backup Process

Gruber mentions that he’s “suffered very few disk calamities.” He’s fortunate. I’ve had seemingly more than my fair share of catastrophic disk failures—some caused by my own poor backup hygiene. Over the years, my backup process has oscillated between very disciplined and a totally laissez-faire approach.

Today, it leans toward the latter, in part because a lot of my data is in The Cloud™ and I can get to it from multiple devices—it almost feels like a backup. It’s not, but I might be excused for acting otherwise. 

Many of us keep irreplaceable information in the cloud: Photos of your kids. Early email flirtations with your now-spouse. Tax records. Software serial numbers. The list is endless. We trust Apple and Dropbox and Google Drive to keep our stuff safe. But they’re not backups. You delete it here, it deletes it there and everywhere. Or, worse still, they delete it without having adequate backups of their own.

This is why I enable iCloud Photos to “Download Originals to this Mac” and disable iCloud’s “Optimize Mac Storage” in System Settings. If the files are local, I take responsibility for them.

It’s also why I have dozens of old hard drives with copies of copies of backups of data I’ll probably never look at again, but which makes me happy knowing I have them, just in case.

My backup process works fine but is not as regimented as it could be. It currently relies on a combination of Carbon Copy Cloner for local backups (semi-automated on drive connection, not done as regularly as I should, sadly) and Backblaze, which I’ve used since at least 2012, for automatic, remote backups. Both have saved my bacon more than once, but it’s unfocused, made worse by having multiple computers in various states of sync.

I plan to revamp my backup process soon. I’m thinking of reintroducing Time Machine for more granular, local backups; with Carbon Copy Cloner handling replication of those (and other) backups; and Backblaze acting as my online-and-offsite copy. I’ve been eyeing a Synology since my Drobo died several years back (and the company went out of business), but I’m considering a Mac mini with a JBOD (Just a Bunch of Disks). And I’m looking into a local offsite backup with friends and potentially cold storage with family in another state.

My biggest challenge is the sheer volume of data I have—approaching 80TB across several drives. How much of that is duplicate data? Who knows! (Prolific podcaster John Siracusa has a brilliant new app (currently available in TestFlight for ATP members) that would help here. I’m excited by its potential.)

I’m open to hearing about experiences with and alternative strategies for backup solutions.