I’ve recommended SuperDuper to a few folks looking at Mac Backup solutions based on this survey so I figured it was time I implemented it myself. I’m sorry to report results are poor.
For some reason SuperDuper gets confused when copying some files. I think there’s probably a race condition with transient files. It reports I/O errors on files that no longer exist when I look at them, and I/O errors on files that I can copy by hand, with cp, and with ditto just fine. It’s not open source, so it’s hard to say exactly why that happens.
Now, that, in and of itself, wouldn’t be a huge problem – I see the same kind of thing with rsync, and any other backup tool (but perhaps not with ZFS snapshots – but that’s another article). However, SuperDuper stops the backup process when it hits a few of these errors, leaving a potentially not-backed up disk, for a few file copy errors.
Since I was planning to purchase SuperDuper, I sent the developer a note about it. His built-in reporting tool is very smart about integrating with AppleMail and used the Keychain appropriately – a nice touch. He wrote back with a link to a blog article he wrote about this issue as a response, and assured me that not to worry, most of the files were backed up anyway.
His point is that if there’s an I/O error, then you have a disk problem and need to get that looked at. Now, he has a point – if there’s a real disk error his tool isn’t going to fix it. But, in this case, there’s no apparent disk error, so the behavior of SuperDuper is incorrect. Even if there were a disk error, I’d be trying to use a disk backup tool to recover the data. Sure, if you have $2K, send it off to DriveSavers – they’ll do a better job, but most people don’t.
But besides that, his assertion that most of the files were copied anyway was incorrect, by SuperDuper’s own reporting (and a visual inspection of the target disk image) – in my case, SuperDuper stopped after 553,643 of 1,987,938 files. So, not so complete.
Clearly, for my usage, SuperDuper wasn’t copying most of the files, and was stopping on false I/O errors. This makes for an unusable backup tool.
So, I wrote back to the developer, explaining what I had seen and asking if he could include an option to allow the user to decide whether continuing after I/O errors was the right thing to do (most tools – rsync, dd, etc. all have such an option).
This is the entirety of his response:
From: support@shirt-pocket.com
Subject: Re:(Case 38299) SuperDuper!: Error during copy – copy stops due to I/O errors
Date: April 10, 2007 18:51:38 EDT
To: bill@bfccomputing .comI’m sorry this is a problem for you, Bill, but I wish you the best in finding a good alternative.
Dave Nanian
Shirt Pocket
Clearly, he feels so strongly that his behavior is the correct one that he’s willing to forgo many sales to not give the user a choice in the matter. I respect his conviction while strenuously disagreeing with his conclusion. So, if I’ve recommended SuperDuper to you previously, please consider that recommendation rescinded and accept my apologies for not testing it thoroughly enough first. I’ll try to e-mail a link here to everybody I can recall.
Now, that leaves the problem of what to use for Mac backup software. I have some Enterprise clients using a version of rsync I patched up. I’ve done some ditto backups locally. But all of those things have problems, and none are currently the right answer. rsync is probably the one with a chance, since it’s open source, but the patch sets to date are inadequate. If the entire problem with copyfile() is fixed in Leopard (perhaps via ZFS) then rsync can start working. I’ll be testing that once I’m confident I have a good backup of my laptop (a Catch-22, no?). Otherwise, it’s probably going to be time to start up a SourceForge project to get interested collaborators together to come up with a working solution.