Real disaster recovery

The traditional model for the disaster recovery business is beginning to look a bit like a cosy piece of childhood animated television. Have you nipped in to the office to find a smoking ruin, attended by Pew, Pew, Barney, McGrew and co? Have no fear, jump in your square-wheeled plasticene Morris Minor and wobble off to your out-of-town Disaster Recovery centre, where cheery factotums will whip the covers off your ready-to-roll duplicated network, and everyone can pop along and pick up where they left off...

Except that this business model for the DR services sector is being rapidly outmoded by three factors: bitter experience, the stealthy arrival of Thin Client Computing, and a discomfiting spread in the types of disaster we might reasonably be facing.

The technical stuff is easiest to contemplate; possibly Bill Gates' most useful thought is the observation that technology's impact is overestimated in the short term, and underestimated in the longer term - and thin client computing is definitely a case in point.

Very large corporates are increasingly using Terminal Services, Citrix, or the other alternatives to keep their Desktop PCs rolling along for minimal costs and putting all their horsepower into computing centres which can be anywhere with a big enough pipeline leading to it.

Reaching those computing centres from a high-profile city-centre target building is no harder or easier than doing it from a web-caf, a spare university campus Computer Science lecture theatre, or (in one case I saw recently) from the sun-deck of a liner in the middle of the South China Sea. Why bother with a contract for expensive duplicated set of servers and workstations when in fact your whole environment is sitting in a few racks in a sleepy town off the M42, and can be run from a pile of MacMinis anywhere in the first world?

One answer to this came to a client of mine last year, when their giant distributed computing centre turned out to be within a couple of miles of the bomb factory of the 7/7 London bombers. Nobody's perfect.

Heads in the sand

The non-technical issues are rather harder to feel like you should be planning for, sitting peacefully in an IT department office. Bitter experience is easy to encounter, but quite difficult to turn into a usable plan. Like every other Londoner I have my tales of struggling to go anywhere or do anything on July 7, 2005 - but when I translate that into the complete impossibility of actually reaching a disaster recovery site, or indeed of even reaching the people who needed to be sent to the disaster site to get them moving, I am often ignored.

It's as if the traditional "one fire" disaster recovery model is enshrined in the procedural bibles of corporates and smaller businesses across the land, and nothing can shake it loose; having a disaster which takes away the ability to travel for a couple of days is just too bizarre to contemplate - let's just think about the old and comfortable disasters, and not the stuff that's really happening.

If a few days of travel chaos and half-day of cell phone lockdown give you the willies and make you want to hide the DR procedures file, have a look at some of the material on planning for Bird Flu. How's about six weeks of complete blanket travel ban? No deliveries, no meetings, no nipping back in late at night to reboot anything, and major companies planning how to shuffle the organogram in response to losing 20 per cent of their staff - not to the hottest competitor but to the grim reaper instead.

Planning for this Disaster isn't about taking a wobbly guess on the reload quality of your tape restores at a disaster recovery specialist site, it's about being confident that your systems can run for six weeks without a break, and that your site is proof against looters not traditional fare for disaster recovery meetings (or documentation, for that matter).

Every eventuality

Then there's the nightmare stuff. Nuclear weapons, "dirty bombs", bio-weapons - anything that could cause a large chunk of an entire economy to fall right over. It seems a fair bet that old school disaster recovery suite providers, who take on their books large numbers of clients each on the "small fire" model, are going to be swamped when the dark day dawns.

Those small guys with an old server in the back of the wood-shed and a stack of DVDs under the stairs could well get the chance to jump ahead, while the bigger and less flexibly-planned operations wave useless contracts and stand in a queue with no sensible prospect of resolution.

Seems to me that the mistake of not preparing for the widest variety of disasters could well be represent a new category itself.