Sound the trumpets!

We're happy (and, frankly, relieved) to announce the immediate availability of SuperDuper v3.5 Beta 1: our first version to fully support Big Sur backups.

That's right: bootable Big Sur backups for Intel and M1. Today!

Shut Up and Give Me My Download

For those who aren't interested in reading about this stuff (you really should), you can download SuperDuper v3.5 B1 from here.

Note If you're on an M1 Mac, you will not be able to boot from a SuperDuper backup unless you are running macOS 11.4 or later. The new macOS version is in beta, and you can get it here: macOS 11.4 Public Beta. (The usual caveats about running a beta OS apply.)

As you might expect, you can't boot an M1 Mac from an Intel Backup or vice versa. You can still restore, though, using Apple's "first boot" restore process, or by using Migration Assistant.

When starting off with the v3.5 beta, you must first make an erase-then-copy backup. On success, you can switch to Smart Update.

Finally, we know Big Sur Erase, then copy image backups don't work yet—Smart Updates work fine—but we wanted to get this out to those of you who have been patiently waiting. Remember: Beta!

As is always the case with our Betas, this version will automatically update to future Beta versions of v3.5 (assuming our update check is on in Preferences) until the final v3.5 is released. At that point, it will install the release version and move to the regular update check.

Let's Hear What He Has to Say!

(Have those folks in a rush gone? OK, good. For the rest of you, here's the deal.)

As we've been saying for some time, release of our Big Sur version had been gated on factors not fully in our control.

For security reasons, Big Sur forced the use of Apple Software Restore, or asr, for backups that contain a System volume (that is, any startup volume).

Until recently, asr didn't work properly with M1 Macs. It would copy the System volume, then throw various errors, including one indicating that the "source volume format was not yet supported".

Of course, the "source volume format" was APFS, something it clearly did support, so this was weird. Clearly they meant something else, like the various new support volumes the M1 Macs use.

But given that asr wouldn't run at all, there wasn't much point trying to copy the System volume. So we decided to wait, thinking that a fix would be just around the corner.

Which, needless to say, it wasn't. Or it was, but given that blocks are longer in San Francisco than they are around here (and, frankly, Apple had its hands full with a bunch of new Macs, iPads and the like), the fix took much longer than expected. So we needed to do something.

Since copying the Data volume was the only thing that worked, and was still fully restorable, we released a workaround while we waited.

This had two major advantages. First, we didn't need to fully test and beta a new version that half worked, sometimes, with caveats...something we were loath to do. Instead, it made it clear it was a workaround.

Second, it meant that we didn't have to "half wrap-up" our in-progress work.

New Stuff Has Come to Light

Of course, we kept plugging away at it and, when we checked the new macOS 11.4 beta, we were happy to see the "not yet" message had gone away, which suggested "not yet" had finally become "can". Or, at least, "might".

More testing and configuring ensued and, as of late Saturday night (livin' the high life here at Shirt Pocket HQ), we were finally able to boot from a SuperDuper copy of an M1 MacBook Pro, made to a regular USB SSD, without any post-copy OS install.

Finally.

As such, we can finally release a Beta that works as expected on both Intel Macs (now) and M1 Macs (assuming you have installed 11.4 Beta 1 or later).

To be clear, this is only possible because Apple made it possible in macOS 11.4. I'm certain it required changes to the M1's startup process and to asr to finally make it happen. Without those changes, we couldn't have done this in a supported way.

I'm really happy the teams involved made the effort. Thanks, folks!

The "Did I Say No Caveats?" Caveats

Remember, though, Apple is not finished. There's movement, and success, but we honestly don't know whether the final, non-beta release of 11.4 will work.

Given things are clearly changing, and heading in the right direction, we thought putting this out now would be useful.

As indicated above, you can't boot an Intel Mac from an M1 backup or vice-versa. You can, however, boot an M1 Mac from a backup of a different M1 Mac, once you've authorized it with a user on the Mac you're booting.

Regardless of processor, you can still restore using Apple's "first boot" restore process, or by using Migration Assistant. So it's not a problem to move from Intel to M1 or M1 to Intel.

Important Note asr copies at a low level and works a drive quite hard. In our internal testing, some SSDs couldn't handle the load without intermittently overheating and generating errors.

This seems to be because the controller was trying to manage freed blocks, or wear-level, while still trying to manage the flow of incoming writes.

When this happened, we started to get obscure errors from asr ("resource busy" is quite common). Allowing the device to settle and cool typically resolved the problem. I'm hoping Apple will improve its handling of this error as development continues.

We had the most success with the Angelbird SSD2GO PKT MK2, with its SSD Manager installed and the most recent Western Digital MyPassport SSD (affiliate link).

Erasing a drive from the top/hardware, rather than just erasing the volume, seems to help some drives, too.

Or you can just use Smart Update, which will only copy the Data volume. To wit...

Notes on a Revolution

With macOS releases prior to Big Sur, we could update the OS when changed, regardless of whether it was hosted on a separate System volume (as done under 10.15 and later) or on the same volume (all previous versions).

However, with Big Sur, a system update requires us to use asr to recopy the drive. And asr won't (currently?) just copy the System volume: it's all or nothing.

That's fine with an Erase, then copy backup, because you are asking for a full backup.

But with a Smart Update, fully erasing the drive when an OS changes just isn't appropriate.

So, we decided that under macOS 11 and later, a Smart Update of a "volume group"—that is, a startup volume—will only copy the Data volume, updating your applications and data but leaving the system as-is.

This gives you some interesting options:

  • You can keep your backup under an earlier version of the OS, while keeping your own files and applications up to date
  • It's now possible to restore just your applications and data into an existing OS install, whether through migration or by copying with SuperDuper
  • By updating your backup with Smart Update, and then restoring with Erase, then copy, you can roll back the OS to the version on the backup, while keeping your most recent files and applications intact

You can think of it as a modern Sandbox: you can try a new minor OS version and still roll back if you don't like it...without losing your "new" data. Pretty nice!

Have at it

So there you go. It's been a long, frustrating road, we know—believe me, we know—but we can clearly see our destination. Enjoy the new version, thank you for your patience, and we look forward to your comments and feedback.

Download SuperDuper! v3.5 B1