Note to Buffalo: Hire a Proofreader

A client of the Ur-Guru's just bought a Buffalo DriveStation Duo USB drive. Kudos to him for taking care of backups, but when he installed the software, he found something a bit less than reassuring in the dialog boxes:

In case you didn't catch it (I didn't, the first time), the RAID setup utility is asking the user to restart WiDNows instead of WiNDows. This is doubtless a typo, and while it probably doesn't indicate anything about the RAID software, it's not encouraging.

Badly written user interfaces and documentation suggest that the manufacturer is cutting corners and the product may not be reliable. If you're using free software downloaded from a small start-up site, that may not be such a big deal, but Buffalo Technology is a major corporation and the DriveStation Duo is not a cheap piece of equipment.

Hiring one editor/proofreader to polish the documentation is probably more cost-efficient than employing only programmers with fluent English, but however you choose to do it, make sure your software is literate.

Technorati Tags: DriveStation Duo,Buffalo Technology

Visual Guide to RAID

The Ur-Guru mailed me a copy of this image, which I've cut into chunks to fit onto the blog. It's a visual demonstration of the different RAID configurations, using water coolers. You can get the original photo on Zachary Tirell's Flickr Page.

Some People Are Just Rude

I received an e-mail message this morning with the return address "thomas.l.ray@gmail.com on behalf of Rick [firetowerlist@hotmail.com]"

It wasn't complimentary, but I hardly consider myself or what I write here above criticism, so that's not a problem in and of itself. The message was in response to my January 14, 2005 Backup Reminder, and because it does contain some valid points, I wanted to reprint it here.

From your blog, "The Geek Girls say that a differential backup copies the files which have changed since the last full backup and that an incremental backup copies the files which have changed since the last backup of any kind. (Are you confused yet? I am.)"

What's to be confused about? It works exactly the way they say.

-You make a full backup on Monday
-On Tuesday, you change 1 file and back it up only. That's Differential
-On Wednesday, you change 1 more file. Now, if you back it up and the one from yesterday, the only changes made since the last full backup, then that is Differential. If you only back it up and not the one from Tuesday, then that is Incremental.

That's actually the clearest explanation I've heard of the distinction between differential and incremental backups.

Since when is a RAID system even similar to LIVE BACKUP? ("LIVE BACKUP is a term I found on a database backup site, and it refers to a continuous backup process, where backups are made as the files are changed. This is similar to what happens in a RAID system") BACKUP backups data. RAID provides data recovery ability, not a backup.

I understand RAID much better now than I did in January of '05 (which isn't saying that much, as the Ur-Guru is now trying to explain parity bits to me after reading this post) and I agree that while some configurations of RAID duplicate your data as its created—and some people rely on that instead of instituting real backup systems—what RAID is really designed to protect against is disk failure, not the corruption or loss of data. If you delete a file on one disk, it will get deleted on the other disks in the array. If the file is corrupted, the corruption will be duplicated. So it's not really a backup.

Yet the similarity between RAID and "live backup" or "continous data protection" (as most people seem to call it these days) should be obvious: the duplication happens when the data is changed, continuously, in the background where you don't notice it.

That's the useful part of the message. It's followed by the snide part:

If you don't know these simple basic facts and prefer to wing it by just using your own terminology ("Personally, I like the term "Differential Backup," and that's what I use to describe the way my own file backups work."), then you have no business in the IT field. You're an embarassment to the rest of us that do know our business and take it seriously.

Don't bother replying (especially since this is a null address used for spammers). Either get out of the field or learn your craft properly.

Well, Thomas, or Rick, or whatever your name is, you might be relieved to know that I'm not in the IT business. I do provide some general-purpose consulting to home office computer users, based on having more experience than they do and being able to call on the Ur-Guru to answer questions I can't. But I don't claim to be a real IT professional, and I don't want to be an IT professional.

I'm a writer. I'm writing a column, which I research to the best of my ability given the constraints on publishing it and the fact that I'm not getting paid for it. I correct mistakes when I'm made aware of them, but I don't have every past post memorized, so unless I get new information shortly after publishing something or people point out errors, they may stay in the blog.

There are countless other people out there who know more about technology, and specifically about backups, archives, and data protection, than I do. None of them seem to want to write a weekly e-zine/blog exclusively devoted to the subject. And persistence usually wins out over genius.

The point of the Backup Reminder is to get people to back up their data. If they need to hire a real professional, and not me, to get that set up for them—all the better. But those who do hire me can at least be assured that I won't treat them with contempt just because they don't know as much as I do about something.

Dead Servers and RAID vulnerabilities

This is a follow-up to last Friday's Backup Reminder. The Ur-Guru pointed out to me that the dead-server, dead-backups double whammy couldn't have happened the way I described it, because "You can't be running a functional bootable system with RAID1 mirroring if the second disk(s) are dead and not functioning. Every write operation is done twice for RAID1. Guess what happens if one of the two (or every 2nd mirror disk) is dead and doesn't respond?"

Which shows you what I know about RAID.

The Ur-Guru advised editing my original post so I wouldn't look so ignorant, but the truth is that when it comes to RAID and other advanced computing issues, I am ignorant. In case I haven't mentioned it lately, I am not a Real Geek. (Well, yes, I am a geek, but not a computer geek. I'm a classicist by training, and we're plenty geeky, but mostly involving things that happened a couple of thousand years ago.)

So instead I'm posting a correction.

I still don't know what the exact details of this particular ongoing drama are (except that the company may have lost 3 years' worth of transactions and other data), but as I thought back on what the business owner told me, it seemed to me that it wasn't that half the array had been dead for months, but that they'd had to replace one of the disks a few months ago and now the second disk had gone and the RAID mirror hadn't been mirroring.

The Ur-Guru (never short of opinions) responded to my conjecture with one of his own:

They had a functional RAID1 setup.
The mirror disk failed.
They replaced the mirror disk.
They had a cheapo (probably onboard) RAID controller that does not do an automatic rebuild so the replaced mirror disk never got mirrored properly (it was just a clean disk in there with no data).
Then the real disk failed.
Then they hoped the mirror would save them, but the mirror was never a mirror after the replacement.

A serious controller would've asked whether to rebuild the mirror or not, or would have been set to do it automatically. Once the disk was replaced with a different one that is the common thing it does. The cheap onboard controllers require more manual interference and... due to user error they never really had a mirror. I think that is the story.

I don't know whether that's the story in this particular case, but it's certainly something that could happen and something that any readers who do have RAID arrays should be aware of. To reinforce that point, another Real Geek friend chipped in with

Most RAID controllers that I have used won't let the machine boot if both drives aren't working okay, so I don't know what's up with your client's system. I dislike RAID, because only about half the time is it a drive failure that causes you grief. The other half, a virus erases some files, or you delete something by mistake, and the RAID controller obediently makes the same change to your mirrored drive. It gives you a false sense of security, and costs too much for the benefit you do receive.

The point about copying viruses or other errors is a very, very important one to remember. A properly configured mirror will protect you against hardware failure, but not against other threats to your data. RAID is not a replacement for backups.

(And I have no idea what was wrong with the backup system that was supposed to be copying the data on the moribund drive and why there was nothing, or nothing useful, on the tapes.)

Apparently, either none of my other readers noticed it was impossible for one disk in an array to be dead without affecting the others, or no one else actually read the reminder, because no one else said anything.

Which then leads me to wonder whether I shouldn't just have kept my mouth shut in the first place.

FileSlinger™ Backup Reminder 8-6-04: RAID and Redundancy

Dear FileSlinger clients, colleagues, and friends:

Last week I got to go on a tour of a data center—a place designed to house huge arrays of servers securely.

I went on this tour because I wanted to know more about how ASPextra.net, the data center's largest client, works. The concept of an ASP (Application Service Provider) interested me when I first heard of it. When you use an ASP, instead of buying all the extra hardware and software and installing and maintaining it yourself—and then having to worry about things like synchronizing your home, laptop, and office e-mail and other data—you 'rent' all those things from an Application Service Provider. This is not necessarily inexpensive, but can potentially pay off over time for small businesses and particularly for people who travel a lot. (To find out more about ASPs in general, see the excellent article by How Stuff Works.)

But before I started recommending ASPextra.net (that's their web address as well as their name) to clients, I wanted to find out whether they were really providing the kind of security and ease of use that they claimed. And, naturally, I was hunting for information on the subject of backups.

So there we were down at ColoServe in San Francisco. In addition to needing to hand over my driver's license in exhange for a pass to get in, I certainly saw plenty of evidence of physical security: the computers are in locked cabinets in locked rooms, the building has its own generator to provide power in case of rolling blackouts and an advanced fire control system, not to mention the air conditioning that comes up through grids in the floor to keep disks from overheating.

Why is air conditioning part of server safety? An overheated disk or processor is more likely to fail—if your computer gets too hot, it will crash. Don't ignore cooling fan error signals, and make sure you dust the vent at the back (or bottom, with most laptops) of your machine frequently.

Then there's security in the sense of having a network connection that's always on: the "pipes" bringing data to the entire West Coast runs directly underneath the data center, meaning that for anything to interrupt internet service to ASPextra's servers, it would have to be something that would take down the net for the whole state. There were redunant network cables on all the machines, so in case one failed, information would keep flowing.

We also got a demonstration of how the ASPextra spam and virus filtering system works to keep most viruses and spam from ever reaching their clients' computers. It all looked pretty solid.

But backups, I said. How did they handle backing up their clients' data (and software)?

The answer was "Actually, we typically use a RAID system on the client servers with dual or sometimes quad internal HDs. If the client wants a dedicated backup server, that is no problem, but that does cost extra."

I've heard the term RAID a million times, but I had to go look it up in the Webopedia to be sure what that meant. RAID stands for Redundant Array of Independent Disks. There's that word "redundancy" again. While it's something you want to avoid in your writing, redundancy is something you want to achieve when it comes to your data. It's like carrying a spare tire.

In a RAID, if one disk fails, another can replace it, thanks to "disk mirroring"—in this case not quite the same thing as the disk imaging done by programs like Norton Ghost, because the duplicate information is written simultaneously, all the time. (Incidentally, buying your own RAID would run you anywhere from about $2500 to $20,000, according to a C|NET search.)

Asked what the failure rate of the disks was, our guide said that only one disk had failed in 15 months. For drives in constant use, that's an impressively low failure rate. The Ur-Guru (who was on the tour with me) has had many more disks than that fail in the past two years—probably due to inadequate cooling.

If you consider an ASP, make sure they can provide all of that. In the meantime, keep your computers cool and keep backing up your data.

Until next week,
Sallie