9:17 - Barbara is off to a meeting in Atlanta. She's gone until tomorrow evening, so I have to take care of Mom and the dogs. Fortunately, I've already got my menus planned. Barbara left a huge bag of potato chips, which should hold us until she gets back. There may also be some TV dinners in the freezer if we want a change of pace. I suppose if I want to leave the house I could drive over to McDonalds and pick up dinner one night.

Here's a good reminder about how important it is to archive your data (as opposed to just backing it up). I shudder when I hear some people describe their "backup" strategies. One guy I know bought a tape drive that came with one tape. He didn't see the point to spending any more money on tapes, so he backs up to the same tape every time. Better than nothing, I suppose, but not much.

Quite a few people I know depend on mirrored data drives or periodic copies to another hard drive or to another system on the network. Even people who try to do the right thing often end up using a four-tape rotation or some other method that provides little or no historical data. And even those who do use a tape rotation scheme that provides months of historical data seldom recognize that tape is a very poor technology for archiving data (as opposed to backing it up).

Around here, we're not just belt-and-suspenders when it comes to backing up and archiving data. We use two or three belts and several pairs of suspenders. That's easier for us than for most people, of course, because we have tape drives and CD burners all over the place. But even if you don't have such an embarrassment of riches, there are a lot of things you can do to protect your data. Off the top of my head, here are the steps I recommend:

1. Segregate your data from everything else. Microsoft applications in particular make that hard, but with a little work you can still manage to do it. If all of your data is located in one place, it's a lot easier to keep it backed up than if it's distributed all over your hard drive (or over multiple hard drives or multiple machines). We have nearly all of our main working data stored in the /usr directory on theodore, our primary file server.

2. Segregate your archive data from your working data. Nearly everyone has older data that is infrequently accessed and even less frequently changed. In our case, that's stuff like older book manuscripts, Quicken/TurboTax data for prior years, thousands of old digital camera images, email from prior years, and so on. We almost never need that data, but if we do need it we want to be assured that it'll be available. Separating this archive data from current data makes it a lot quicker to do frequent backups of the current stuff. The old stuff needs to be backed up, too, but not very often. We keep our archive data on-line for ease of access, but the truth is that we could probably spool it out to off-line storage without much inconvenience.

3. Segregate archive data that doesn't need to be backed up from archived data that does. The key issue here is to determine which data would be difficult or impossible to recreate. For example, when Red Hat Linux 7.3 was released, I immediately downloaded all three ISOs and stored them in a folder outside my normal archive hierarchy. I wanted to keep them even after I burned CDs from them, but there's no point to having them clutter up the archive directory. If I somehow lose them, I can simply download them again. (Actually, Red Hat sent me boxed product, so I don't need those at all). Same deal with things like MP3's I've ripped from CD. Those get backed up in the sense of being replicated to hard drives on other systems, but if I somehow lost all of them I could recreate them easily enough. There's no point to storing them in a location that will be backed up to tape or archived to optical media.

4. Move stuff from your current working data directory to your archive directory on a schedule. There's an important distinction between current working data--which needs to be backed up frequently and have the backups easily accessible--and archive data, which needs to be backed up much less frequently and for which the backups need not be quickly accessible. If you move data from working to archive whenever the mood strikes, you destroy that distinction. Unless you then do a full backup of both your working and archive directories, you'll never be entirely sure whether all your data is backed up properly or where it might be among your backup tapes or discs. The key issue is that your archive data is normally in effect read-only, and you needn't do a new back up of data that hasn't changed. When you move data from your current directory to your archive directory, you're essentially converting the archive directory from read-only to read-write, and that means you need to do another backup of the archive directory. By restricting movements of data from current to archive, it's easy to keep track of what's where and what hasn't been backed up. Every month or every quarter or whenever you schedule that move, you immediately follow the move by doing a full backup of your archive directory. After that backup completes, you again start treating your archive directory as read-only.

Once you have your data segregated properly, you can start to think about the best way to back up and archive it. Obviously, a lot depends on both your budget and how much data you have squirreled away. Some people can backup their entire data sets, working and archive, onto one CD-R. If that's true for you, that makes life easy, although I still recommend segregating your working and archive data, because that won't be true forever and it's well to get into the proper habits. In our case, our /usr working data directory currently totals 11,463 files, 550 directories, and about 1.26 GB, so backing up to CD-R would require two discs. Our archive directory is even worse, at 22,683 files (many of them zipped archives), 1,771 directories, and about 16.3 GB.

For us, as for many people, there's no single technology that is ideal both for backing up and for archiving. Tape has advantages that make it ideal for backing up--high capacity, high speed, high short-term reliability, and low media cost per GB stored. Where tape falls down is in long-term reliability. I have archive tapes that I pulled a year ago, two years ago, and more. Chances are that if I tried to restore those tapes today, they'd restore properly, but then again they might not.

Magnetic media in general and tape in particular are poor choices for long-term storage. As Jerry Pournelle once famously observed, all the little ones and zeroes tend over time to average out to 1/2's. In glass houses, the mainframe operators address this problem by doing periodic refreshes, which amount to restoring the backup from tape and then re-writing it back to tape. Although it's obviously possible to do the same in a PC environment, and that may in fact be the only practical solution if you have massive amounts of data to be archived, most people will find it easier to use optical discs as an archive medium.

In addition to the obvious advantage--data written to optical discs don't "age out" as is the case with magnetic media--optical discs have another more subtle advantage in that they are standardized. Tape drives sell in relatively small numbers, and the technology changes rather quickly, making it problematic or impossible to read years-old tapes on current drives, at least for PC-oriented tape technologies. DDS and other server-oriented tape technologies do much better at maintaining backward compatibility. Conversely, optical discs are based on long-lasting standards like CD and DVD, and so can be read even by drives that are two or more generations more recent than the drive used to write the disc.

For example, I have tapes written several years ago in various drives. Even assuming that the tapes remain readable, which they probably aren't, I'd have a real problem if I needed to recover data from them. Even if the tape in question was standards-based and physically fits one of my current tape drives, the drive probably won't recognize it. That's particularly likely if I used a QIC drive. You might think that current QIC/Travan drives have at least read compatibility with earlier QIC standards, but you'd be wrong. Oh, they'll read tapes written by drives a generation or two previous to their own, but that's about the limit.

But if the tape drive that wrote them is still sitting on the shelf, I'm in luck, right? Not necessarily. Even if I still have the drive and it still works, my current backup software probably doesn't support it. And if it did, it probably wouldn't understand the format in which the data was written. The only solution is to find and install the original backup software, if I can find it and if it's readable. Even if it is, chances are that it won't run under Windows 2000 or any other operating system I currently have running. I might have to track down a copy of Windows 95 or even Windows for Workgroups, build a system, install the old OS and tape software, and finally restore the data. I've actually done that more than once, and in each case some of the files on the old tape failed to restore.

So tape is a very poor choice for archiving data.

Optical discs, on the other hand, are an excellent choice for archiving. Assuming that you take reasonable care in storing them, they should be readable for at least ten years after they're made, and probably much longer. With optical discs, media stability isn't likely to be the limiting factor. Instead, as with tape, the problem is likely to be finding a drive capable of reading the disc. With CD-R discs, that's not likely to become a problem for many years. Nearly any current DVD-ROM drive can read CD-R discs, and the same is almost certain to be true of future DVD-ROM drives, as well as for whatever technology eventually replaces DVD. There are simply too many CD discs out there for any later technology not be read-compatible with CD.

Unfortunately, the same may not be true of DVD writers, which haven't yet become standardized. Certainly, many current DVD-ROM drives can read DVD-RW and DVD+RW discs, and some can read DVD-RAM discs. But it's not entirely clear to me where writable DVD is heading, and until that becomes clear I'm not comfortable depending on writable DVD as an archive medium. For backup, yes, writable DVD in general and DVD-RAM in particular is a reasonable backup medium. But not for archiving, or at least not yet.

So that leaves CD-R and CD-RW as the only reasonable choices for archiving PC data. Fortunately, if your needs are modest, current CD writers are also a reasonable choice for backing up. If you're on a tight budget and your working data will fit on one or two CD-R discs, I recommend buying a fast Plextor PlexWriter CD burner, one that writes at 16X to 40X and rewrites at 10X or 12X. Get yourself a spindle of 100 CD-R discs and use them to burn archive copies of your archive directory. Also get a bunch of 10X or 12X CD-RW discs and use those to burn backup copies of your main working data. CD-RW discs are cheap enough that it's no hardship to buy 10 or more, which is enough to implement a grandfather-father-son rotation, which provides plenty of redundancy, granularity, and history for your working data.

10:18 - I'm reading all this stuff about UnitedLinux, and I still don't get it. I understand that in Linux Land it's a matter of Red Hat and the Seven Dwarfs, but I don't understand how four of those dwarfs getting together accomplishes anything. Are they merging their companies? If so, why? In what sense is a merged company better off or stronger? If not, what's the point? Will all four companies be selling the same distribution under different names (or the same name)?

I assume that the real motivation for this action is that they expect third-party software companies will be more likely to produce a version compatible with UnitedLinux than they would be to produce individual version(s) for any or all of those four companies. Even assuming that turns out to be true, which I don't think is a given, what good does it do them? Third-party software companies are still going to focus their efforts on Red Hat first, because that's where corporate money is. Corporations will likely continue to favor Red Hat because it comes closer to commercial software than any other distribution, and corporations are comfortable with the familiar commercial software mechanisms.

I freely admit that I don't understand the Linux economy, so I'm probably missing something here, but I don't understand what. Surely UnitedLinux doesn't really believe they can replace Red Hat as the de facto standard? Or perhaps they do. If so, I think they're in for a disappointment.

9:05 - Barbara is going to be surprised when she gets home tonight. When she was cooking dinner Wednesday night, we noticed that the cook top didn't fully turn off when she turned off the burner. The pilot light flickered dimly. We twiddled the switch a bit, but couldn't get the pilot light to turn out completely. So I went downstairs and turned off the breaker, which killed both the cook top and the oven. Knowing my propensity to procrastinate, Barbara said yesterday before she left for her meeting that it'd probably be weeks or months before she had a functioning cook top or oven again.

My first thought was to replace the switch and/or burner myself, but when I opened the cabinet under the cook top and examined the bottom of the unit I found that it was sealed. That meant that fixing the unit myself would involve pulling it out of the counter, disassembling it, finding the correct parts, installing them, reassembling, and re-installing. That was more trouble than I wanted to go to.

Also, as my British readers sometimes point out, for most things the US uses wimpy 120VAC rather than the manly 240VAC used in Britain. But that's not true for things like ranges, for which we in the US also use 240VAC. I'm not afraid of 240, as long as the device is disconnected at the breaker, but I figured it probably made more sense to allow someone else to do the repairs.

My next cunning plan was to swap cook tops between the upstairs kitchen and the downstairs kitchen. We have a cook top in the downstairs kitchen that's seen very little use, and none at all for the last several years. I could just about have handled swapping the 3-wire connections. Alas, the cook top upstairs is a 36" unit and the one downstairs is 30". So much for that plan.

So I hit the Amana web site and found a list of authorized service companies. One was near us, so I called them yesterday morning. They're supposed to be sending a guy out today. So, with any luck, Barbara will arrive home to find that she has a functioning cook top and oven.

FrontPage has turned strange on me. In the past, when I opened FrontPage, it always automatically opened the last web I'd been working on. It no longer does that, despite the fact that I have the "Open last Web automatically when FrontPage starts" checkbox enabled in Tools -- Options. I tried everything I could think of to make it work again as expected. I disabled the box and then re-enabled it. I looked for a setting in the registry. Nothing works. FrontPage insists on starting now with no web active. The good news is that I actually prefer it to work this way. I should have cleared that checkbox long ago.

Bad news this morning. Just as I was getting ready to publish this, the phone rang. It was Barbara's friend Mary from the library. She was calling to tell Barbara that their friend Linda Hyde Tannenbaum, who'd undergone a heart transplant last week, had died during the night. Linda was a special person, and we'll all miss her.

11:25 - Here it is the first of the month, and I nearly forgot to run Pournelle's web access reports for him. I'm no longer on pair Networks, so I no longer have to run my own web reports manually. Greg Lincoln and Brian Bilbrey have set things up for me so that data is saved and rolled and reports are run automatically. I just happened to look at my own report this morning, which reminded me that I hadn't done Pournelle's for him.

And there's some interesting stuff going on on Pournelle's back-channel mailing list. Eric Pobirs posted a message with some observations about USB 2.0 versus FireWire and a link to this story about incompatibilities between the 845/850/850E northbridges and the new USB 2.0 ICH4 southbridge. I sent the following response:

Your subject line had me really worried for a moment.

Of course, Intel is shipping RAMBUS motherboards with USB 2.0, but they're using a separate embedded NEC USB 2.0 chipset, which presumably is happy at 1.8V. I wasn't aware of the voltage differential problems between the 845/850/850E northbridges and the ICH4 southbridge. Thanks for pointing that out. I recently read that at least one Taiwanese motherboard maker (I forget which one) has announced an 850E/ICH4 board, which makes me wonder if they'll change their plans or simply ship a motherboard that's likely to be unreliable and short-lived.

I don't think Intel will give up on RAMBUS entirely, particularly with their shift to the 533 MHz FSB. RAMBUS is just too good a match for the bandwidth of the P4. (But see http://www.theinquirer.net/31050220.htm for some interesting benchmarks). My guess is that we'll see an 850E2 chipset around September/October that is designed and certified to work with ICH4. (Jerry, I think this issue is good grist for your column; if we weren't aware of this, then certainly the vast majority of your readers aren't either).

I also agree with you that FireWire isn't going to go away. It appears that Apple has at last gotten real about licensing, but I think it's too late for them to do much about the tidal wave of USB 2.0. Still, I see FireWire remaining as a niche product indefinitely, although it's going to lose its mass-market base to USB 2.0 as older equipment (computers and cameras) ages out and newer stuff has the USB 2.0 interface. I've always thought that FireWire was analogous to SCSI, on many levels, and USB to ATA. Just as ATA dominates SCSI in consumer space, I think USB 2.0 will dominate FireWire.

The skies are clear and gorgeous this morning, so I was hoping that we could take the scopes up to Pilot Mountain tonight. When I checked the Clear Sky Clock, though, it said that tonight is going to be pretty bad for observing. Heavy clouds until 10:00 or 11:00 p.m. and rotten transparency and seeing until the early hours of tomorrow. So I guess we won't bother.

9:35 - Barbara is leaving around noon to travel to Charlotte for the funeral of her friend Linda Hyde Tannenbaum. Several years ago, Linda was head of the Clemmons branch library at the same time Barbara was a branch head, so they saw each other often. Barbara's friend Mary, who is currently Head of Branches for the library system, arranged shared travel arrangements, so a group of eight librarians are going to drive down to Charlotte in two cars.

This has not been a good year. Linda's funeral will be the third Barbara has attended in the last few months. Harold, one of her favorite uncles, died a few months ago. Ann, whom Barbara regarded as a second mother, died a month or so ago. And now her friend Linda, who was only 53.

I'll stay at home to take care of Mom and dogs and do the laundry and other tasks.