Intention vs. Reality vis-à-vis Network Backups

In Brief

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…

Network Backups

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.

Image Unreliability

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.

Trying to Improve Things

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.

What Really Happened

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.

Mea Culpa

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”¹), and kind of nice!

Some Warnings

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!