SuperDuper 4’s Radical New Interface Explains Itself as You Use It

This may help: Restore macOS Firmware on an Apple Silicon M1 Mac + Boot to DFU Mode

1 Like

Jane, no, don’t feel like that! The two forms, Revive & Restore, of device firmware update (DFU) are easy to use once one has gotten the target computer into DFU mode.

The real issue, as Dave says here, is having a second Mac from which to run Apple Configurator 2. (Or simply the Finder from more recent OS like Sonoma.)

You need to know which of the USB-C ports on your target Mac is the DFU port, and have a plain USB-C cable (not a Thunderbolt one.) You have power but no external devices hooked up to the target Mac.

The harder part is putting the target Mac into DFU mode. We hold Control and Option on the left, and Shift & Power on the right, for 10 seconds, then continue holding Power for another 8 seconds. I time these using the stopwatch function of my A-Watch, and have found those times critical. (If at first unsuccessful one tries again…)

It’s helpful to have on hand on the host computer a file called an IPSW for the OS you’re restoring to—these are readily available at Mr Macintosh (https://mrmacintosh.com/) – one drops this into the Configurator window and it gets installed.

The process isn’t long, four minutes odd for a Revive, which merely updates the firmware and OS, leaving the Macintosh–Data partition untouched. It’s worthwhile having a go at this some sunny Saturday afternoon…

As Dave says, it would be great if we could do this from a phone!

2 Likes

I returned to this thread to catch up. . . I’m getting ready to use Migration Assistant with a new M4 Mac Mini and an SD! clone of my 2018 Intel Mini running Ventura on an external SSD. (I may upgrade the Old Mini to Sonoma first.)

FWIW, the only time that I attempted to do the same thing using a Time Machine backup the migration failed to transfer the applications. I had to spend a couple of days reinstalling everything. I haven’t used Time Machine since then.

GV, just coming back in here: yep, I’d upgrade your 2018 Mini to Sonoma first, and—using SD! 4—make a bootable copy on your external SSD. Then run Migration Assistant on the target M4 Mini, using the SD! 4 SSD as your source. Opt to keep the named account. And perhaps, say a prayer…

I can’t be the only person this has happened to—running Migration Assistant like this to update a new M5 MBA, MA spent 5 hours doing… nothing. Tried again, same result.

I opted to boot from the SD! 4 SSD bootable copy, using the Apple Menu Startup Disk app in Recovery to set that. I then used SD! 4 from the SSD to make a bootable copy on the new Mac, and reset its Macintosh HD as startup.

Which worked! Saving the hours of hand reinstalling 60 odd apps. But just to feel a little more secure, I did a DFU Revive on the new MBA… which has been working perfectly now for weeks.

You see why I wanted to thank Dave so sincerely…

Thanks, Bill. I am running Sonoma on a MacBook Air M2 2023. Other than a 2011 iMac, it is the only one I use. The big question is “Do I have to do this to run SuperDuper?”

I usually just go merrily along and do my usual back ups with SuperDuper. (I used to be the Mac tech support for all my friends. Now none of us know anything! Thank God for all of you here on Tidbits!)

You do not. This is typically only something you have to worry about when you want to go restore to an EARLIER OS than you have on the Mac…which is rare.

Been using Migration Ass’t. since the G4 days. Interestingly enough, it’s only failure was when I migrated to my M4 Mini, fortunately there was a simple fix… it did not migrate my Music & Photos folders! A couple of Finder copies of those folders and I was all set (nothing unusual has happened since I did this is 12/2024).

Previously in my working life, I always used bootable backups/clones (pre AS). At work I was in production mode where every hour counted. Did it at home as well because I used to bring work home. Now I have little need to being back up in minutes. I still, however, and very disappointed at the fruit for leaving us in this situation, they could make it work, but choose not to.

Jane, as Dave says here, your SuperDuper backup is all you finally need to be secure.

In my own case, I prefer to duplicate backups using ChronoSync as well, since along with SSDs that makes neat backups to iCloud+, which at $NZ 5/month for external storage is a comfort.

(I don’t use Time Machine, despite being excited by it when it appeared in Leopard – seen too many glitches experienced by others. My ‘time’ backups are ChronoSync ones to two ancient hard drives.)

Yep, I’m neurotic – I’ve my staunchly careful SuperDuper SSD, two ChronoSync SSD, iCloud, and two hard drives. This comes I think from working before ‘Net use was widespread in a foreign language environment (Japan) across three cities – we never lost data…

Knowing how to get a Mac into DFU mode isn’t an essential – but it’s another comfort. A DFU Revive is an easy way of resolving poor behaviour.

I’d never needed it before an initial version of the ProtonBridge utility (providing IMAP) clobbered an M1 MacBook – but I was very glad I’d practised DFU updates when that happened…

Finally, when an expert with the depth of Howard Oakley at Eclectic Light says he doesn’t understand something re a feature of Apple system programming – which is not uncommon – the rest of us will get stumped from time to time. All part of the interest of things I’m afraid…. You’re not alone! :face_holding_back_tears:

1 Like

:clap: :folded_hands: :collision: Right on, @janesprando !

1 Like

For anybody interested, here is a blog post from the developer of Carbon Copy Cloner about why Apple changed the ASR tool (spoiler: it was a security decision):

1 Like

It’s not why Apple changed asr. It’s why they’ve changed the boot process on Apple silicon Macs…and bootable backups are not deprecated.

2 Likes

A part of that says “I think it should be directed towards any developers that have misled their users into believing that ASR and “bootable backups” had any place in a backup/recovery strategy post-Big Sur.”. Well, obviously that was not entirely accurate. And thank god we have David Nanian to provide an exact opposite experience.

As I have stated numerous times, at least for myself, SuperDuper! has always been able to create bootable backups, and they are definitely reliable.

Except when it couldn’t.

1 Like

Certainly true, Mike. But the backups were still valid; even if they didn’t boot, they could be restored.

Even Apple’s own tools are sometimes broken by Apple’s own updates. And then they fix them. So it goes.

2 Likes

Thanks for the link. Until reading that I had believed the CCC policy decision was based on pragmatism due to the problems at that time. I hadn’t appreciated that Apple had actually also stated the security aspect, which further explains the change.
In view of the apparent reduction in the problems in recent years I wonder if Apple have had a change of heart, or at least decided to find ways of mitigating the security risk.

TL;DR I had to boot from my bootable SuperDuper clone today and very glad I had it. A non-bootable clone would not have provided the information I needed. Here’s the story.

———————
I attempted to install a large software package yesterday (anaconda/python). I was dismayed to find that it overwrote my login profiles (.cshrc), created and/or overwrote other hidden (i.e., “dot”) files and directories. Plus, I believe it overwrote some user-installed libraries with its own versions. Uninstalling it left a lot of cruft and debris and the wrong versions of libraries. Attempting to pick and choose which files to restore was an impossible task.

So I did a restore from the bootable clone. First, I copied all new files[1] since the last backup from the internal drive to the external backup drive. Next, I booted into the clone. Once booted, I tested all my software that had been adversely affected by the botched uninstall and determined they all worked correctly. This would not be possible if the clone was not bootable.

I then did a restore from the clone to the internal drive. And now everything works fine. A Migration Assistant would have copied much more. The SD restore only copied that which was necessary.

———

[1] Well, almost all. I missed a few.

1 Like

Glad you got sorted. Erase All Content And Settings, followed by migration from a backup prior to the bad install would have done it too. In very similar situations I have rolled back to a local (ie boot volume) snapshot made before the bad install…as quick as a boot to Recovery and a a restart.

https://eclecticlight.co/2026/05/07/how-to-make-and-roll-back-to-a-snapshot/comment-page-1/#comments

3 Likes

I was in this same situation a couple months ago (installed some package that put crap everywhere). Seems to me that booting from the backup only made this harder than it had to be and take longer than it should. I just fired up CCC and the task history from my latest backup showed what had been installed. I created a restore task and restored the previous backup from before the install. Looking at that restore event right now in CCC’s history, it took just 23 seconds to put everything back to how it had been. Takes longer than that just to change the startup disk! I followed this video from CCC’s YouTube channel, it was exactly the same situation (well, I went to a backup version, not the most recent backup): https://www.youtube.com/watch?v=FNi-H0QBjK8 (about half-way through is the part that applied to me).

Didn’t need a bootable backup, didn’t need to reinstall the system, didn’t need to use Migration Assistant. I couldn’t have done it without backup versions, either. That’s what I don’t get about SuperDuper – it doesn’t retain versions, you’re supposed to use Time Machine for that? I run my backups hourly, what if your backup runs before you realize you want to undo something? CCC’s versioning has saved my bacon numerous times.

Just curious but I assume you only have to run the “Make Bootable Copy” once, the first time and after that you can run a simple “Smart Update” to synch internal and backup drives. Or am I mistaken?

Yes, that is correct. But just in case, I typically always use the “Make Bootable” script, as I prefer things to be “squeaky clean”. It actually does not take long at all. But via Smart Update, it is faster.