Where I humiliate myself in public: release notes, backup deep-dives, and various and sundry other things that strike my fancy.
John Gruber (of Daring Fireball fame) has been using SuperDuper since at least 2004, not long after its initial release. He’s written kindly about it over the years, and has just issued his verdict on SuperDuper 4:
SuperDuper feels like impossibly good software. Read his post announcing version 4 to start, then catch up on the rest of the blog to get a feeling for how much work he’s put into SuperDuper 4. Just extraordinary.
…
I recommend SuperDuper 4 wholeheartedly.
Thanks, John!
You probably don’t need to read this. Unless you want to.
So, how do you solve the problem of testing a product like SuperDuper?
As you might expect, it’s pretty difficult. Of course, you can pin individual cases of UI and copy behavior (there are over 2,000 individual tests against the SuperDuper code base, which is about 250K lines of Swift, Objective-C and C): those are run every time I make a change to the code base…to protect against regression of things that are known.
But this type of testing only gets you so far. I can model various situations that I’m trying to cover, but models just simulate reality (even if the cases are real).
Real backups are more complicated, and quirkier.
They’re often to different drive types. Those drives may be formatted in different ways, have their own layouts, failure modes, fragmentation levels, and connections.
So, not only do I run a few systems of different eras as test harnesses with various drives attached (simultaneously running Time Machine, too), my main development system (currently a first generation Mac studio) has a huge number of different drives attached.
These include (but are not limited to—I also have thumb-drives set up for specific tests, and assorted other SSDs and HDDs):
Note that some of these drives are connected to an Anker TB5 dock, to make sure that’s covered, too; some are connected to an Apple Studio Display, to get a hub in there; many are daisy chained, so I deal with that, too.
Yeah, that’s a lot of drives (and a significant investment), and doesn’t count the separate Mac systems with their own external storage that are running tests all the time.
Those drives don’t do a lot on their own, of course: SuperDuper is configured to run copies against them, of various types, all day long (and all night).
If there are any failures, I’m notified immediately and can analyze the logs to determine the cause, how it was handled (since failures can happen to users), and whether it was my issue or a problem with hardware.
In addition, while all of the copies are checked separately for accuracy and under-copying, a number of tests also check for idempotency, to ensure there’s no thrashing or incorrect/over copying, and then there are a series of timed tests that make sure there hasn’t been a performance regression.
And on top of that, there are the aforementioned 2,000 automated tests in the full SuperDuper 4 test suite, with more manual tests as well (which I need to figure out how to automate one of these days).
But even with all that, I can’t truly replicate every situation that can occur in the field. And even with all that I can screw up and miss things.
That’s where other testers come in. As I’ve mentioned previously, there were a large number of external testers during SuperDuper 4’s development, rolled in over time to ensure a series of “fresh testers” (and test cases) were always encountering the code.
When outside users run into a problem, I have to figure out what happened beyond just “Hey, Dave, last night’s copy failed”. So SuperDuper does extensive logging (if you want to be driven mad, feel free to look at the ocean of logging with log show in Terminal): when a user submits an issue, it includes both SuperDuper’s visible log, and a filtered-for-relevance couple of seconds before and after the failure from the system log, so that I have enough information to analyze the error.
When appropriate, verified problems turn into another test case, to make sure they’re both fixed and won’t break again. And then a test build is sent to the user to ensure the situation is covered in its original setting.
Bugs in the field are pretty rare things (and are often the result of configuration differences that I haven’t created in-house). But given a report, it’s nice to be able to fix them…and prevent them from happening again.
In the end, there’s no magic, and there are no shortcuts: copy testing is done by making (and comparing) tons and tons of copies, small and large, under both “random” and “known” situations; UI testing is done by pinning behavior and ensuring things react as expected.
Combine that with (hopefully) proper design, extensive experience, and careful implementation, and you end up with SuperDuper 4 which, despite a number of small updates post-release, is (thankfully) proving to be very reliable in the field…the goal of any design, development, and testing process.
You need only look at Apple’s installer, sitting at “one minute left” for an hour, to understand that time estimates of I/O-based operations are very hard.
They seem like they’d be easy, though, don’t they?1 You just take the size, figure out how fast things are going, and do some math, and bingo-bango-bongo, there you go! Perfect estimate!
Similarly, you take something like the Blackmagic Disk Speed Test and look at its read/write speed and think “geez, there’s the speed, what’s the problem”?
I mean, sure: if you were writing a single file (or some big files), to a blank destination, on a consistent connection. Bytes stream at a constant rate, and it really is just a matter of a few quick observations and a little math.
But, no. It’s not that simple. I tried the best I could to get things as right as possible, and the estimates are still, sometimes, wrong.
Sometimes very wrong.
Let me walk you through the general (albeit highly simplified) approach:
Sounds familiar, right? Well, it goes further than that:
Even with all that, sometimes it’ll be wrong.
I just don’t know, until I get there, whether something is going to need to be copied. If it doesn’t, and it’s large, the estimate will be too long. If it does, and the OS is slow to copy that particular file, or that size of file, it’ll be too short.
You get the idea. Hopefully.
For years, I resisted putting in anything like this. It’s just too hard to give an accurate number. But as I shaped the algorithms I’m using in SD4, I figured I could get close, most of the time, in most situations, and it would be worthwhile.
And I think it is. Usually. Sometimes it’s wrong…but it gets better the more you copy that particular content.
It’ll never be perfect, though (although I get very close for replication, which was very tricky, given Apple’s replicator gives virtually no information about what it’s doing, and certainly no speed or even size info), and I try to indicate that with lots of hedging and “weasel words” like approximately and about and estimate to tell you that, well, an estimate is an estimate. It’s an inexact science.
So, if the estimate I’m presenting annoys you, you may want to consider taking the Car Talk “engine check light” approach: put a piece of black electrical tape over it.
Or just close the window. The copy will continue in the background and finish when it finishes.
Problem solved!
Or so everyone tells me when they complain about them. ↩︎
Applications, especially browsers, make extensive use of caches: folders that are full of zillions1 of files that make re-accessing data, especially network data, faster after the first time.
They’re typically considered disposable, temporary, and transient, since the content can be re-downloaded (or regenerated) later.
Given the sheer quantity of this stuff, you’d think I’d configure SuperDuper’s copy rules to skip it. It’d certainly make some kinds of copies faster, and the copy itself smaller.
Case closed!
But…I don’t, even though it would be easy. And there are a couple of reasons for that.
First: if you’ve got a bootable backup, it’s more likely to perform the way you want in the event you need to get to work ASAP if the cached information is retained. You don’t have to rebuild/redownload the info: once booted, things are available just like they were on the original drive.
Second: in the event of a disaster, I want to maximize the likelihood that you’ll be able to recover your data.
If you’ve had some sort of disaster, or hardware failure, or you’re doing data reconstruction, the data you need may be both where it was originally, and in a cache somewhere else on the drive.2
Copying the caches may take a little extra time and space, but if it proves useful in the event of a problem, it’s well worth it.
(And if you disagree, you can, of course, create rules that exclude anything you’d like.)3
A zillion is, of course, one-one-hundreth of a bazillion. ↩︎
I’ve considered copying /tmp (/private/tmp) for similar reasons…but do copy individual application temporary folders. ↩︎
The rule pattern ** can be useful here. For example, /Users/*/Library/**/Caches will exclude any folder named Caches in any User folder under Library, regardless of depth. ⌥ Option lets you edit the rule to enter an arbitrary pattern.
Be careful, though: use Preview to check the effect of your rule. And I suggest including “Backup - all files”, so you start with the built-in SuperDuper rule. ↩︎
This is a sort of technical post. If you’re not interested in the details of what’s happening during a backup, what files can and can’t be copied, when, and why they’re harder to do properly than you might think, feel free to skip.
Recent versions of xOS (that is, macOS, iOS, iPadOS, etc) have Data Protection Classes from A to D that get assigned to files and folders.
Some files have Class A protection: where an application has specifically marked files that it thinks should not be accessible to anyone without authorization.
Class B protection means a file cannot be accessed by anything unless it’s open. That is, even if a device is locked, the file can be created and written, but once closed, Class B is treated like Class C.
Note: Since Class B files are created when Class A keys are not available, they’re encrypted on a per-file basis, in addition to normal FileVault encryption.1
Class C are files that are inaccessible after reboot until you log in. Once you’ve logged in, they remain available, even if the Mac is locked.
Finally, there’s Class D: no protection. Curiously, this is not allowed under macOS. ¯\_(ツ)_/¯
The thing is, though, is that these files and folders are inaccessible unless the user is logged in, and the screen is unlocked. A few seconds after the screen locks (or you log out), the keys are purged, and they cannot be read.
And there’s no “easy” way to find out what files are what.2
From a privacy/security standpoint, this is obviously good. Someone who gets into your computer cannot access those files unless the drive has been unlocked. On a phone, that means a locked phone has data that’s inaccessible, even via the USB port.
From a backup perspective, though, this is…troublesome.
Troublesome because people tend to schedule copies for when they’re not at their Mac. And if they’re not at the Mac, the screen is almost always locked.
That means the files any application considers to be worth protection cannot be accessed when a backup usually happens.
By anything. Even a backup program with “root” access.3
Certainly if important files are marked as Class A, and those files are never backed up, that would be quite bad. And even Class C files are unavailable if you haven’t logged in yet…a broader class of files that could get missed until the next time you back up with the screen unlocked.
Which, given the way people schedule backups, may never happen.
Fortunately, SuperDuper handles this with relative ease.
You may have noticed that if you had an overnight backup, when you unlock your screen, a copy starts to run. It’s typically quite brief, thanks to ⚡️Turbo Smart Update, but it might surprise you anyway.
If you look at SuperDuper when this is happening, you’ll see a little pill in the job that says it’s a “Follow-Up” (or, hopefully, ⚡️Turbo Follow-Up).
So what happened?
During your overnight copy, SuperDuper kept track of the files that it couldn’t access due to their protection class. And now that it can access them, it’s making sure they get backed up.
These are the kinds of details that are involved in putting together a backup program you can count on. There are a million little details, things that’ll catch you out if you’re not extremely careful.
It’s not so much that a file might be written with the wrong bytes, or that you’d have bit-rot…that’s incredibly rare, and the hardware is designed to deal with it to a great extent. But missing files?
That’s not something you should have to worry about. But I do…which is why SuperDuper handles it, without any fuss. You don’t even have to think about it.
And now you never have to think about it again.
I’m guessing (when things aren’t open source, it’s very hard to investigate this kind of stuff), but I think that when you have too many of these types of “individually encrypted” files on an APFS drive, the replicator barfs with an obscure E2BIG error, even if the screen is unlocked. And there’s no real way to fix it. ↩︎
For the curious, the protection class is available via fcntl(fd, F_GETPROTECTIONCLASS), set via fcntl(fd, F_SETPROTECTIONCLASS, class) and open_dprotected_np(...); when set on folders, everything in the folder inherits the class (similar to an inherited ACL). ↩︎
If you’ve ever tried to make a bootable copy and received a Resource Busy error, I think this is because the replicator has run into APFS structures that are holding Class A protected files when the screen is locked. Since it can’t replicate those blocks (they’re locked and the key has been thrown away), and the copy would be structurally invalid without them, it fails the copy. With a very obscure error.
To try to deal with this, if you schedule an Erase, then copy bootable backup, and the screen is locked when the time comes for it to start, SuperDuper postpones the replication until you log in. And when a replication is running, we use an assertion to keep the Mac awake, with the screen on. ↩︎
SuperDuper v4.0.5 is now available. It fixes a failure to mount an intermediate volume when re-mounting an image.
Yes, that obscure.
I had thought I’d covered “every” image backup case (and there are a lot), including mounting the “intermediate” (host) volume, then mounting the image, then ejecting the ones that I mounted after the copy.
And I had. Yay.
Once. Boo!
Basically, the unmounting of the intermediate volume left things in a weird state that didn’t re-mount.
That’s it.
Although I’d sent this to a number of external sites, and results were positive, I clearly didn’t have full coverage over every case.
Well, I do now. Hopefully the pace of releases will slow a bit soon, but I’m trying to address what people need (or are encountering) as soon as I can. In the meantime
Download SuperDuper v4.0.5 (or, easier, update inside the app)
and enjoy!
SuperDuper! v4.0.4 is now available. It includes support for images and a bunch of little fixes and improvements. A reasonably full list is here.
tl;dr It’s good. You’ll like it. And if you don’t, well, I’m sure you’ll let me know…
In the Olden Days, SuperDuper made network backups to disk images, starting with sparse images, moving to sparse bundles, and then to ASIF images when they became available. We did that because NAS devices can’t effectively represent the source’s permissions, ownership, ACLs, etc: even with an Apple “sidecar”, it just wasn’t exact, and so, we went with a NAS-hosted “native” file system: a disk image.
This is, of course, what Time Machine also did, later: there just wasn’t a choice, if you wanted a faithful representation of the source.
There are, unfortunately, problems with this approach: network connection failures don’t just take out one file…they can destroy the entire image, or its directory structure, making the image unrecoverable.
You’ve seen this yourself, if you use Time Machine over a network connection: it’ll say “In order to improve reliability, we’ve started a new Time Machine backup”, when what it means is “your image has become damaged and we can’t recover any of its data”.
That’s bad. Very bad.
It was also indirect, so access to your files meant you had to open an image file, then look at its volume, etc. For the less experienced, this could be confusing.
So, when I set out to write SuperDuper 4, I decided that, instead of images, I’d support backups directly to the network device. That way, you can copy those important folders (say, your Documents or Photos) to the NAS, recognizing that all their metadata can’t be strictly maintained, and any failures would only take out one file, which could be re—copied by re-running.
Other computers on the network could see those photos, documents, files, and work with them directly rather than by opening a disk image.
Win-win. Or so I thought.
Alas, what “really” happened was that people just tried to copy their entire startup drive up to their NAS device. While it was possible that this could work, a lot of NASen were super sad about having millions of files written to them over SMB.
Whereby “super sad” I mean “would fail randomly with bizarre errors that didn’t make a lot of sense”.
Not to mention copying a zillion tiny files is very slow.
Not the experience I wanted to offer.
Aargh.
So, I opened a door to failure, basically. Not my intention, but that was the result.
In SuperDuper 4.0.4, I’ve brought back image backups, but better.
If you select a NAS volume or folder as a destination, SuperDuper warns you that it can’t be full fidelity, might be slow, and offers a single button that will back up to an image instead. You can password protect it if you want.
And all this can be done with one click. You don’t have to set anything but the name…and I automatically provide a sensible default.
It’s reasonably foolproof (he said, keeping in mind that “you can’t make anything foolproof because fools are so ingenious”1), and kind of nice!
As I’ve written over the years (you should read that if you haven’t), backups to network destinations should never be your “primary” backup. They’re slower, inherently unreliable, and not as easy to recover from.
That doesn’t mean you shouldn’t use them! They should just be a second line of defense.
And now, with SuperDuper 4.0.4, you can mount that defense again.
Download away, or use the internal updater, thanks for your patience, and for using SuperDuper!
ref. Rick Cook’s The Wizardry Compiled; Grave’s Law (“If you make something idiot-proof, the world will create a better idiot”); et al. ↩︎
As far as I can tell from the auto-generated subtitles, the folks at Bits und so like the new version of SuperDuper enough that they might start backing up again!
(Which they definitely should do!)
Andy Ihnatko of Ihnatko.com, Material, and MacBreak Weekly recommends SuperDuper 4 as his Pick of the Week—seconded by Leo Laporte and Christina Warren:
Thanks, folks!
For those whose time is so valuable that my blathering would be too costly, SuperDuper v4.0.3 is now available for your enjoyment.
There are a bunch of changes in this update, covered, as usual, in the release notes, but the one that you might notice immediately is that ⚡️Turbo Smart Update should happen more often, and start more quickly than before.
For those with a lot of volumes, there’s now a sort control for the source list: you can alphabetically by type, or purely alphabetically.
There’s now an option in the sort pop-up that adds a few sections to the source list. SOURCES is for, well, source volumes that have Jobs, as well as the startup drive, which is always at the top of the list.
Volumes that are used as the destinations of those Copy Jobs are under (you guessed it!) DESTINATIONS.
Volumes that aren’t either sources or destinations are in OTHER VOLUMES.
SuperDuper remembers whether or not the sections are expanded or collapsed across launches, so if you never want to see destinations in the list, you don’t have to. And any drives that aren’t involved at all are readily suppressed as well.
macOS is really bad at handling huge folders. When you ask for information about them, it can be very slow returning that info…and then you have to process what it gives back.
I can’t do much about the former, but I made some changes to the latter that should significantly improve performance.
After all files are copied, SuperDuper makes sure to correct all of the various folder modification times so they match the source. It was previously doing this silently, and now the step is called out, and accounted for in the time remaining.
I’ve always tried to make SuperDuper accessible—one of the reasons for the text is so that the actions could be described and not inferred by folks using screen readers—but the initial releases of SuperDuper 4 weren’t as VoiceOver friendly as I’d hoped.
I’ve made some progress on that in this release, and I’m not done. Apologies to those frustrated by the issues…know I’m working on it.
Drag and drop job reordering was broken in the last update, and it’s fixed in this one. Drag away.
Jobs can also be reordered with Cmd+Option+Up/Down.
Now, of course, via the internal updater, or by downloading and installing manually.
Enjoy!