Users often ask me for drive recommendations, and while I provide general suggestions for FireWire drives in the SuperDuper! User’s Guide, I haven’t suggested any Network Accessible Storage (NAS) devices, mostly because I haven’t been entirely happy with the ones I’ve tested.

In general, most NAS units are Linux-based, with a drive that’s formated as ext3, which allow a large sparse image to be stored on the drive. This works well with SuperDuper!, and lets us properly preserve permissions and metadata with full fidelity. Some, like the LaCie “mini” Ethernet drive, are shipped as FAT32, and need to be reformatted as ext3 (or HFS+, or NTFS) before they can be used.

I’ve tested the Buffalo Linkstation and Gigastation, the LaCie mini ethernet drive, the Linksys NLUS2, and a number of others, and while they all work reasonably well when configured properly, none have been recommendation-worthy.

The units I’ve tried in the past have all had very old AFP (Apple’s network protocol) support, old enough to not support files larger then 2GB or so (even though their file system could handle larger), mostly because they’re all based on an old version of Netatalk. SMB can be used instead, and that does work, but you have to know to do it… and most users don’t. This means their backups would fail in various weird ways.

On top of that, these NAS units are pretty insanely slow. Even the Gigastation, using Gigabit Ethernet, did an initial backup running at less than 1MB/s. This improved once the first copy was done, but it’s painful the first time through.

So… nothing to recommend.

Until now.

Over the last week or so, I’ve been doing extensive testing with the Terabyte version of Infrant’s ReadyNAS NV, and I’m very impressed: impressed enough to give it a big thumbs up.

The ReadyNAS linked above is a 4-drive X-RAID unit (which has four 250GB drives set up for fault tolerance and speed, using Seagate’s Nearline SATA drives which—like Maxtor’s MaxLine III drives—are designed to have a longer life and more heat tolerance than regular drives) in an attractive case, with GigE capability. Like its competitors, the ReadyNAS runs Linux, but unlike the others they’re fanatical about keeping things up to date, and support the most recent Netatalk, which properly handles large files.

On top of that, they’ve spent a lot of time optimizing the unit, and it actually delivers very good performance—I got about 5MB/s on a full copy-- far better than the others, even over AFP. (More AFP-specific optimizations are promised for the future, too.)

But the goodness doesn’t stop there. Infrant knows that their OS can do more than just serve up shared storage, and they’ve gone ahead and created a nice port of Slim Devices‘ SlimServer, which runs on the ReadyNAS and can serve music around the house, through real Squeezeboxen or the Softsqueeze player. (In fact, Slim Devices is offering a bundle of a terabyte ReadyNAS NV and two wireless Squeezeboxen for $1499.) Infrant also supports UPnP streaming, etc, so it’s likely to work with the solution you already have.

And since they have good AFP support, you can point iTunes to its media share, and rip directly to it. Nice!

The ReadyNAS is not inexpensive (although the 250GB, easily expanded one isn’t too bad), and you might wonder whether you should just get a Mac mini with a FireWire drive instead. While you certainly could do that, the RAID capabilities built into the ReadyNAS are invaluable when you’re dealing with critical data. Infrant has clearly designed their unit to be rugged and reliable, and that’s obviously important. A failing/failed drive can be hot swapped for a new one, so your data remains safe even in the event of that inevitability.

The only real downside of the Infrant—other than the expense—is that it’s got a fan. Heat is the enemy of hard disks, so it’s important for the fan to be there, and they’ve made it temperature sensitive so it only runs as fast as it needs to. But, it’s not silent (although it’s not that bad), so if that’s an issue, this isn’t the unit for you.

Otherwise, a very enthusiastic recommendation: Infrant has done some really great work here.

Have at it, everyone!

Next week, we’ll be releasing v2.1.2 of SuperDuper with various improvements, including Growl support. I think you’re all going to like it.

We’d been investigating various methods of notifying users of successful and failed copies for some time, especially for users who are backing up headless or remote systems, and decided to leverage Growl’s well-tested and mature functionality rather than roll our own. It’s a nice package, and I’m glad it’s out there.

There’s a ton of flexibility built into Growl: you can show status visually with various types of floating panels and pop-ups, mail to any account, and even forward notifications to other machines on your network.

Putting this into SuperDuper! initially seemed pretty easy, but we ran into some unusual problems with our AppleScript-based “schedule driver” that I thought might prove interesting.

Obviously, we couldn’t require Growl—a 3rd party application—to be present on a user’s system. The idea here is to use Growl if present, not mandate it. But, our schedule driver—which can be extended by the user—is compiled “on-the-fly” when a schedule is created or modified.

But, while AppleScript has various techniques for dealing with a missing application or dictionary when running a compiled script, it really, really, really wants it to be present during compilation. So, a statement like

tell  application  “GrowlHelperApp”

notify   with name   “Scheduled Copy Succeeded”   title   “SuperDuper! Copy Succeeded”   description   “Copy was successful.”   application name   “SuperDuper!”

end   tell

won’t work if GrowlHelperApp isn’t present on the User’s System. Drat.

AppleScript does, however, have something called “raw event syntax”. Basically, you pre-compile your statement, hand-compiling it into Apple Events. Thus:

tell  application  “GrowlHelperApp”

«event notifygr»  given  «class name»:"Scheduled Copy Succeeded”,  «class titl»:"SuperDuper! Copy Succeeded”,  «class desc»:"Copy was successful.”,  «class appl»:"SuperDuper!" 

end  tell

But, this won’t work either: even though there’s nothing in the tell block that needs the dictionary, the tell itself will try to reference GrowlHelperApp, and fail. And if GrowlHelperApp is there, your AppleEvents will be magically transformed into AppleScript when you compile!

So, there’s no choice here—you have to have a tell block, or the events don’t go to the right application. But you can’t “tell” an application and have the compilation succeed if the user doesn’t have Growl installed! Or can you…

Fortunately, a little evil goes a long way in AppleScript. By using a string variable, rather than a string literal, we can prevent the compiler from loading the dictionary at compile time—and since we’re using raw event syntax, there’s no error. Thus:

set  growlAppName  to  “GrowlHelperApp”

tell  application  growlAppName

«event notifygr»  given  «class name»:"Scheduled Copy Succeeded”,  «class titl»:"SuperDuper! Copy Succeeded”,  «class desc»:"Copy was successful.”,  «class appl»:"SuperDuper!”

end  tell

Bingo! This actually allowed compilation… and worked fine when tested in a simple script. But, in the real one, it didn’t work. Instead, I got the following runtime error:

Finder got an error: application “GrowlHelperApp” doesn’t understand the «event notifygr» message.

Now, of course, it does understand the message, because it worked in the simple case!

It took a while for me to figure it out, but the difference, was that in the real script, the Growl notification was in a nested tell block. And, even though the “nearest tell” is for GrowlHelperApp, for some reason this was seen as Finder’s GrowlHelperApp, rather than mine. (You’d think they’d be the same, but not so much.)

The solution, after much gnashing of teeth, was to explicitly reference the script’s main execution context, with:

set  growlAppName  to  “GrowlHelperApp”

tell  my  application  growlAppName

«event notifygr»  given  «class name»:"Scheduled Copy Succeeded”,  «class titl»:"SuperDuper! Copy Succeeded”,  «class desc»:"Copy was successful.”,  «class appl»:"SuperDuper!”

end  tell

I’m telling you, AppleScript has the unique ability to make me feel like the stupidest developer on the face of the earth. Kudos to you, AppleScript!

Anyway, expect this early this week…

It looks like Michael Barrish of Luminous has something important to say:

I love SuperDuper and I don’t care who knows.

Awww. So cute!

(Thanks for the public display of affection, Michael!)

James Wiebe, of WiebeTech, has written a terrific white paper that exhaustively analyzes the reliability of external enclosures, detailing the factors that contribute to failures.

As we’ve known for some time here at Shirt Pocket, large capacity external drives that use multiple physical drives in a single enclosure to boost their performance and capacity are much less reliable than single drive units.

As far as I’m concerned, anyone who relies upon hard drives for storage, backup or otherwise, should read and understand this paper.

Thanks for writing it, James!

Despite being down and mostly out with a cold/flu, I’ll be appearing on The Tech Night Owl LIVE tonight, May 4th, talking about SuperDuper!, netTunes, launchTunes, and desperately trying to not cough up a chunk of lung.

You can tune into the broadcast from 6:00 to 8:00 PM Pacific, 9:00 to 11:00 PM Eastern, at http://www.techbroadcasting.com. An archive of the show will be available for downloading and listening within four hours after the original broadcast.

You can also access the show’s Podcast feed, available at: http://www.techbroadcasting.com/nightowl.xml.

Trying to set a record for number of posts in a day or two here at Shirt Pocket Watch… some more praise today, and a five-star review (w00t!) from the fine folks at Macworld:

Whether you use it to make one-off clones for IT work or to make scheduled, bootable copies of your Mac’s hard drive for backup purposes, SuperDuper is the best clone-based backup utility I’ve seen—and the backup utility to which I trust my own data. Its clear interface, outstanding feature set, informative documentation, and—most importantly—fail-safe performance have made it an indispensable part of my Mac toolbox.

Dan Frakes writing in Mac Gems. Thanks, Dan!

Looks like SuperDuper! 1.5.5 was nominated for a 2006 Editor’s Choice award by Macworld UK in the “Storage” category. Cool, and congratulations to the other nominees, too!

Maurits, of plasticsfuture, has posted an exhaustive, two part review of backup programs on Mac OS X. The first part focuses on the general issue of backing up files on OSX, and the second contains an extensive analysis of more backup programs than I’ve seen covered in one place—freeware, shareware and commercial.

In my blog, I tend to talk about the usability aspects of SuperDuper!, because that’s where I focus my efforts. I can only do that because Bruce and I have very high standards for the rest of SuperDuper!, and Bruce’s copy engine is second to none. In fact, in this review of 16 tools, SuperDuper! was the only tool that worked correctly:

The surprising conclusion is that almost all Macintosh backup or cloning programs do not fulfil (sic) their primary purpose, i.e., they are not able to restore files with all associated metadata. This is despite the fact that many of the tools are advertised as “safe”, “accurate”, “bug-free”, etc. The tools that fail are harmful because they generate a false sense of security. Even more exasperating is that many of these tools cost (significant amounts of) money. The only laudable exception is the great SuperDuper application, which performs flawlessly. (Emphasis mine.)

Many thanks to the pseudonymous Maurits for putting this whole thing together: it couldn’t have been easy to do.

Today, I spent some time testing out the soon to be released update to netTunes along with Salling Clicker’s “Clicker Network”. My setup here is different that most, no doubt, but here’s what was involved:

1. Music server running iTunes
2. Various AirPorts running a WDS network bridging all over the house
3. My main PowerMac, which I’m logged into, running the netTunes client, controlling my Mac mini, which is connected to my stereo
4. iChat, set to show my current track
5. My phone, running the Clicker Client, connected via Bluetooth to the PowerMac, but bridged over Clicker network to the Mac mini
6. The Mac mini, which has no local music, using shared playlists to connect back to the music server
7. Two Intel Macs connecting to the Mac mini’s netTunes server
8. And, finally, the netTunes server, running on the Mac mini

OK, so—sitting in front of my PowerMac, I could see what I was playing on the Mac mini, because netTunes was showing me the iTunes running over there. And I could control it from that or the two Intel Macs also viewing the same thing.

Clicker—even though it was connected to my PowerMac, was showing me what was playing on the Mac mini, since it was using Clicker Network… and it updated properly when I made changes with netTunes.

My iChat status was showing the track I was playing on the mini, even though I was on the PowerMac, because netTunes is smart enough to act like iTunes and send out the proper notifications to make that happen.

And—no matter what I used to interact with the music—Clicker, netTunes, whatever—everything just worked exactly the way you’d expect.

I’m telling you, my smug sense of self-satisfaction was probably detectable from space.