I’ve been using Super Duper for years but am uncertain whether to ‘jump ship’. They have a posting dated 11/14/20 detailing the difficulty the new OS presents in making bootable back ups.
I’m retired and mostly not under the backup pressured I had when running our wholesale plant nursery. (Do you have time to do all of last weeks records and inventory files over if this drive fails?). So, Time Machine will probably do for replacing a tax SS or such for now.
Any advice on what a reasonable wait for Super Duper to upgrade might be. I’m concerned that they might also be ready to retire.
FWIW, CarbonCopyCloner also has this issue, but only for M1/Apple Silicon Macs.
As I understand it, there’s nothing that either app can do until Apple fixes the underlying issue.
However, if you have an Intel-based Mac, CCC can make bootable backups.
See their article Bootable Backups on macOS Big Sur for more information.
As it turns out I do have a new Air with the chip.
I guess that when Apple fixes the issue it will be widely reported. Until then…
I own both SD and CarbonCopyCloner…and the latter is a superior product overall, fully supported by more than the author but a team, has better features, and makes bootable backups. It’s intended for much more than just duplicating a volume…backing up specific folders is way easier to setup and manage. SD has shown little interest in expanding the products useful capabilities IMO…so although I own it I haven’t launched it in at least a year because CCC works and is easier to use with better capabilities.
I’ve been using Super Duper for decades. I’m waiting to move to Big Sur until this issue has been resolved. I’ve always found that Dave Nanian is very responsive to any questions I have had. (support@shirt-pocket.com) But, I haven’t bothered for this issue as it is clearly a major system issue as the post you refer to notes, and I can be patient because my machines are working fine on older OS’s.
2 Likes
I also own both popular cloners. SD is a bit cheaper and somewhat easier to use, but CCC has more functionality and is more transparent regarding issues. At one time, I found that SD better met my needs, but after having an issue where SD couldn’t complete a backup (and working directly with Dave Nanian on trying to find a solution), I switched to CCC for running both my routine and special backups.
CCC does create backups of the data portion of the Big Sur startup disk, but has some difficulty with the the system portion due to changes in Apple’s routines. There is a discussion of CCC and BigSur issues here.
I am a bit fan of Dave Nanian and I appreciate that he has (I think) never charged an upgrade fee for anyone who ever bought a copy of SuperDuper as he treats the entire run of the product as if it’s just a continuous process.
That said, I think the strain is showing as Apple has gotten absolutely baroque on having a streamlined operation to keep a simple, single-path product alive. I was unable to get SuperDuper to work reliably with any of our Big Sur installations using the latest available releases, and wound up at long last buying a CCC license, which worked just fine for the data portion.
3 Likes
I’m new to CarbonCopyCloner so I have question. I’ve backing up my whole drive which is easy. I would like to do a seperate backup of just the Parallels (ios 10.14.6 and the files installed under it). I’m unsure how to do that. Could you advise?
Thanks.
I do not recommend a separate backup for the Parallels Desktop for Mac application itself. It is only necessary to back up the VM files as they are locally created. If necessary, re-installing Parallels is quick and easy and a restored VM opened in the Finder automatically appears in the Control Center.
To use CCC for backup of user VM files:
- Create a new CCC backup task.
- Click on the SOURCE box and select ‘Choose a Folder’ from the dropdown menu.
- Navigate to and select the folder containing the Parallels VM File(s). By default this is ~/Parallels, the Parallels folder in your home directory.
- Select a destination location for the backup on a volume on a different physical drive.
- Select SafetyNet Off.
- Other options, such as email or schedule are your choice.
- Save the new task.
- Run the new task only when all VMs are paused or stopped. One could accomplish this by including a Shell Script in ADVANCED OPTIONS, but that is a separate discussion.
1 Like
I’m a big fan of SuperDuper. It makes doing the one simple thing I want (just a clean clone, no versioning, no shenanigans) as easy and reliable as possible, and it even does so entirely for free if you’re willing to sacrifice a little bit of convenience. SD is essentially what Disk Utility cloning used to be before Apple botched it to the point where it became unusable.
I have no desire to move to CCC so I’m hoping Dave will soon have Big Sur cloning figured out. As long as I’m not planning any major migration or updates I can be without cloning. I have two independent backup strategies (TM to a set of rotating disks in different locations along with “cloud” backups at work) that I can still use for the time being.
1 Like
Guess I’ll cool my heels for a couple more weeks and then go to CCC. Super Duper has been great.
Thanks all, for the counsel.
Baroque is a very kind description. Convoluted is better.
The latest from Dave Nanian (SuperDuper developer).
3 Likes
I am downloading as we speak, Thank you for posting that link. Most appreciated.
Dave notes: “As I indicated above, M1 Macs can’t readily boot from external drives . There are things you can do, if you have an external Thunderbolt 3 drive (USB-C isn’t sufficient), but even that won’t work if the internal drive is dead. Unless things change, bootable backups are basically a thing of the past on M1-based Macs.”
I think that’s a bit of an oversimplification. The truth is more nuanced than that, and if you want to understand it fully, I recommend reading Howard Oakley’s excellent blog post detailing boot and recovery on M1 Macs.
The short version is that part of the internal storage is sectioned off and essentially used as firmware, which contains the boot manager. This is instead of the EFI firmware on Intel Macs. So, in the same way that if the EFI firmware on an Intel Mac was hosed, if the internal storage on an M1 Mac is completely broken somehow, you can’t boot the Mac because it doesn’t have any firmware to bootstrap from, run a boot manager, etc. But assuming that you don’t have a complete failure of the internal storage, you can boot from an external drive on an M1 Mac, as I understand it.
Obviously, a complete failure of the internal storage can happen. (It happened to my current 2013-era MacBook Air, and I was grateful to be able to swap it out!) How likely this is on the integrated M1 Macs is currently an unknown.
1 Like
A good analysis. Hopefully it will prove to work out the same way.
Intel (and older) Macs never had (as far as I can remember) BootRom failures, which would definitely brick the system.
Originally, these were ROM chips, which wouldn’t fail unless they got physically damaged (e.g. corrosion on the pins or power surges). When they moved to flash, there became a possibility of a corrupt image bricking the computer (and I seem to remember one such update happening several years ago), but overall, the BootROM would remain very stable because it is only possible to write to its flash storage during a firmware upgrade. The SSD used for storage is a separate chip, so an SSD failure can’t corrupt the BootROM.
With the M1, the thing that changes is that (as far as I know) the ISC container (equivalent to the Intel BootROM) is stored on the same flash chips that are used to implement the file system. It would seem to me that this might increase the possibility that that partition could become corrupted, making recovery difficult or impossible.
My thought is that we’ve seen plenty of instances of SSDs where its controller firmware has failed in a way that makes the entire device unusable. If this should happen to the M1’s internal storage, everything there will go off-line, including the ISC container, which is needed for booting external media.
The critical factor here, I suppose, is going to be what failure modes Apple has implemented in the M1’s flash storage controller. If they can ensure that any controller failure will have a worst-case result of the SSD becoming read-only, then it will be possible to boot external volumes when the internal SSD fails. If, however, it can fail in a way that makes internal storage completely inaccessible, then there may not be a way to recover.
Personally, I think Apple should have stuck with the older model. Use a separate flash chip to store the ISC container. And don’t access it with the normal SSD controller circuitry. This shouldn’t be difficult to do - provide a separate mechanism for overwriting that flash chip, in much the same way BootROM upgrades used to be done, or the way microcontroller flash images are upgraded - by erasing and overwriting the entire flash chip with an image. ISC upgrades may take longer, but since they shouldn’t happen very often, most users won’t care. And then a failure of the SSD controller circuitry will only take out the recovery and system containers, which won’t prevent booting from external media.
I’m pretty sure Apple is of the opinion that they have been successful in running things this way on iPhone/iPad for years so they feel confident enough to go that route on M1 Macs.
If your actual SSD memory or its controller is hosed, you need to swap the board. Same on the M1 Mac (in fact that was already the case on my 2013 MBP). If OTOH you brick the “ROM”/firmware, you need to go into DFU mode and start from scratch. Same with the M1 Mac (iSC) in which case you’d need Configurator 2 to set up it from scratch.
I’m not a huge fan of this approach and I don’t see anything fundamentally wrong with the previous firmware/SSD split, but I can absolutely see how there’s real-world evidence Apple knows how to make this work in everyday life.
1 Like
Keep in mind that the M1 Macs are operating in a similar way to how iPhones and iPads work in this regard. I’ve not heard of controller failure or the BootROM being on the same chip as the ‘normal’ storage causing any widespread (or even narrow spread) issues for iDevices. In fact iPads, which are probably more similar in use to a laptop than the iPhone, are known to be robust and reliable over many years. So I don’t think these changes will have any effects on boot reliability, even over the long term.
In my opinion, the fact that the internal SSD is soldered to the motherboard has a far greater impact on the long term viability of an individual Mac, particularly the laptops. As I said above, the internal drive in.my 2013 MacBook Air failed a couple of years ago. I was able to replace it with a higher capacity one, giving the MacBook Air a new lease of life (and I’m still using it). With a modern one, that would have effectively been the end of the computer. But integrated SSDs happened before the ARM Macs, so it’s not a limitation due to the new architecture.
I definitely agree with this. And I think fundamentally therefore, it boils down to this: a) could Apple make such high-performance internal storage with this tight integration with Apple Silicon, if they relied on using an industry-standard interconnect and b) could Apple still make portable Macs as svelte and solid if they had to account for a socketed/swappable SSD?
If the answer to both of those questions were yes I’d be complaining. But I have a pretty strong feeling at least one of the questions has to be answered with no (at least partially). So if indeed soldered memory is the price we have to pay for these ultra-compact high-power Macs with the level of integration Apple is showing off, I’m personally OK with that. Of course, the iMac and Mac mini could be a different story.
2 Likes