To keep my data synchronized, there's the option of high-cost automated remote copy over TCP. I selected the low-cost very-remote copy over USB, in which I load all changed data onto my 1GB Memory Stick, walk it down the backyard and copy it. The frequency is a bit haphazard but on average it will happen daily (weekly for sure).

Discussing the required physical environment, I skilfully justified a new, similarly powered computer (with a bigger screen) for the DR site, as it could be a backup of the production system, as well as the development and testing environment, meaning a lot of stuff I have in the guest bedroom could be moved to the DR site. Despite what I told the software vendors, it could also handle peak processing when the main system was overloaded. Unwisely I continued on, saying if the DR site was to be a production overflow area, it would need dual cooling units (an air conditioner and a fridge), full broadband network access plus facilities for personnel, such as bathroom, kitchen, wide screen TV and billiard table in a separate room.

I feel the Boss rather over-developed this idea when she ­identified an upcoming peak in demand for housing, as her mother was coming to live with us for a while. Rather than put her in the soon-to-be-emptied guest bedroom, she suggested we accommodate her properly in the new, self-contained, multi-roomed DR building. With a choice of having my mother-in-law either in my house or in my shed, I felt like George W Bush - between Iraq and a hard place.

Fail-over Failings

I recognize the only benefit of having a DR site is that it is ready when a disaster occurs, so I got to work developing procedures and tests for fail-over. I hadn't realized that this is where the hard work really starts.

My first attempt at a complete set of procedures were shown up as inadequate, as it included plans to use the cordless phone to call the support people. My daughter pointed out that as the phone base was in the house (or disaster zone), maybe I shouldn't count on it. Version 2 was better received, once I changed the designated storage location of the procedures from the office to the DR site.

It took much longer to come up with the first of my test scenarios than I expected, so I decided to trial run that one before writing up any others. I'd overlooked one essential factor - personnel involvement. My household workmates were very resistant to me turning off all the power and making them stand outside at 6pm one winter's night. Matters weren't helped when I left the house keys inside thus locking us out in the cold, and took a further downturn when I revealed the keys for the DR shed were also in the house. Fortunately my wife had planned for this disaster, and placed a redundant set of keys with the neighbours. She has since taken to referring to our most likely disaster scenario as a Bruce.

I abandoned any further full-scale testing.

Finally I completed my research into our DR options, reviewed the risk profile, examined the financial consideration, analyzed the results and carefully considered the work I still had to do. I concluded that any disaster was extremely unlikely, so a DR implementation would not be cost effective, and filed my findings in the bottom drawer.

As I sit now on a lilo in a borrowed tent in the neighbour's backyard, typing these final paragraphs on my PDA, my extensive DR report has lost some relevancy. The fire we had last night didn't pause to read it as it burnt my report, along with my house, so was not aware a fire had almost no chance of occurring.

Bruce Kirkham is a veteran IT satirist and professional speaker specializing in leading edge technologies and scepticism, who views the IT industry not so much as "dot com" as "dot comedy"