Integrate. Automate. Maximize operations for bottom-line results.

Is Your Disaster Recovery Plan a Disaster?

Usage keys and passwords are needed

by Lou Washington - Cincom Systems

Disaster Recovery is a hot topic in the post 9-11 world. It seems that nearly everyday some one has dreamt up something else that threatens to kill us, make us sick, bankrupt us or otherwise destroy the civilized world.

Frankly, I’m flat out terrified!  Well, maybe that’s bit strong  ... I am a little concerned.

Think about it, in the few short years following the Y2K non-event, we have seen more frequent and more violent meteorological events like Katrina. We have witnessed a variety of geological catastrophes like the Tsunami of late 2004 and the ongoing spate of earthquakes that flatten major metropolitan centers. The terrorist attacks of September 11, 2001 are a whole new category of disaster for us to worry about. Hackers seem to be every bit as resourceful as the people charged with protecting our systems from malicious code. Now we have the biological disaster of plague poised to attack us in the form of Bird Flu.

So let’s just summarize this. 

• Global warming is going to continue to spawn more and larger and ever-more violent storms.

• Long dormant tectonic plates are finally starting to move around thus threatening areas not associated with seismic activity such as the New Madrid Fault in southeast Missouri. Even the Bay Area is considered long over due for a massively destructive seismic event.

• People all over the planet are adopting terrorist strategies to further their causes and the counterculture of the hacker is growing ever more popular.

• Even the lowly parakeet in grand-ma’s parlor has been acting strange recently.

In light of this growing threat level, one would expect to find disaster prevention and recovery to be a very hot product today. These services are marketed under a variety of names including business continuity or business availability services.  It is, indeed, a very robust sector of the IT marketplace.

I really have to wonder how many of these services are effective in mitigating the effects of a real disaster versus providing the pleasant feeling of false security one gets from putting forth a minimal effort?

There are a couple of things that I find a bit troubling about the whole business of marketing disaster recovery services.

My first concern is industry capacity. I think the industry is generally pretty successful when dealing with the local or perhaps even regional disaster event.

Looking back on 9/11, I can remember that most of our affected customers were contacting us for usage keys and the like within 24 to 48 hours. Those few with redundant hot-sites never even burped. These companies were primarily involved with the finance sector in some way or another.

While a day or two might seem like great turnaround time for some businesses, I think there would be many types of industries, like the financial sector, where even 24 hours would be totally unacceptable.

The financial industry lives and dies by the value of money over time. Manufacturers can’t sell what they can’t fabricate; so lost production essentially equals lost sales. Service-based businesses face the same challenge - time equals money, and lost time equals money lost forever.

In the new world of large footprint disasters, meaning aggressive mutating bio-threats, mass destruction weapons in terrorist hands, mega storms and seismic events, the stakes are much higher. Will the industry providers be able to meet the challenge of 10 or 15 customers simultaneously needing their services versus three or four customers needing their services?  What happens if some nasty bug puts an entire country - or even an entire continent - in bed for a couple of weeks? 

Will these guys be able to handle 100 or 200 companies expecting to be back online within say, 24 hours?  If resources are limited, who gets priority?  Who has to wait?

My second concern is the seriousness with which companies approach the whole notion of business continuity following a disaster.

Most companies should have documented disaster recovery plans. These include contracts with off-site or remote facilities that are staffed and equipped with a full complement of hardware, software and current data. These services assure us that our needs will be met when the worst happens. Part of this service should include periodic disaster recovery drills to assure that these services are capable of getting companies back in business expeditiously.

There is one very widespread practice that I am well acquainted with that suggests to me that these drills may not be an accurate indicator of potential success. This involves the process of running pre-announced disaster recovery testing. Let me explain my concerns.

I have high cholesterol. High enough and persistent enough that I take stuff for it and my doc routinely has my blood tested for current cholesterol readings. I know when the tests are going to be taken. Several weeks prior to the test, I start eating lots of oatmeal and salmon. I tell my wife, I’m cramming for my cholesterol test.

She is amused by this and always asks me if my life policy is paid up. I always tell her that the drugs are doing the real work and the diet is really just sort of a thing to make the doc feel like he’s involved in my care.

What does this have to do with disaster recovery testing?  There is a similar practice that I see on an almost daily basis.

Like most software vendors, we ship most of our software products with some sort of onboard license management software. This does two things. First, it facilitates configuring the product to match the end user environment and license. Second, it protects the software from illegal usage and illicit copying. 

Typically, if the customer is going to move the product to a machine other than the one named in the license, a new password is required. In the event of a disaster, either real or in the context of a test, the customer will require a password in order to execute the product on the machine replacing the licensed machine.

Virtually all customers affected by this will request a password for disaster recovery tests weeks in advance of the “scheduled” disaster test. Think about that for a minute. The test is supposed to emulate the conditions present during a real declared disaster. The customer is collecting the usage keys and passwords before the disaster is declared. Do companies employ seers now?

While this is a great strategy for passing a disaster recovery test, it is a lousy strategy for surviving a genuine disaster.

Obtaining usage keys for all licensed products should be part of the disaster recovery procedure, not the planning process. As such, this portion of the plan should be tested just like the rest of it. You need to know how your vendors might respond on the weekend versus the weeknight, midweek versus the weekend or during a holiday break.

You’re not going to know three weeks in advance of a hurricane that your datacenter is going to be inundated, that some wacko from the wilds of Idaho is going to do a number on your web-based applications or that your northeast regional offices, along with everyone else’s, will be shut down due to illness for half of next month.

Don’t you think that obtaining usage keys and passwords should be part of any drill designed to emulate these catastrophic events?  Nothing will work without usage keys. None of the affected systems will come online and even if they do, it will probably be in some sort of inhibited mode.

These are very serious issues to discuss with your internal disaster recovery team and those who you are dealing with as service providers.

Good Luck!

Big Lou Washington 

About Lou Washington 

Birthplace : Columbia, Missouri

High school : Hickman (home of the mighty Kewpies!!!) Other famous Hickman alumni include Sam Walton and Ken Lay

Military : The US Navy

College : Graduated in 1975 from the University of Missouri (home of the mighty Tigers!!!) Other famous Mizzou alumni include not only Walton and Lay but also Brad Pitt and Sheryl Crow

Professional Life: I started my career in information management from the somewhat misunderstood field of Records Management. Following four years of working for the University of Missouri System's Office of Records Management, I joined Tab Products Co in 1980. Shortly thereafter I became interested in the software business, PCs and how those systems would shape the enterprise of the future. We were transferred to Tab's then corporate HQ in Palo Alto, CA. I was the first Product Manager for Tab's Tracker systems software products which utilized a PC based bar-coding system to track the movements of everything from files to capital assets. I believe it was the earliest example of workflow automation available on the market. I was also peripherally involved in Tab's Laser Optics division which brought to market one of the earliest business systems employing CD-ROM and WORM technology as an information storage media.

In 1990 I returned to Cincinnati and joined Cincom Systems where I began to learn about and work with mainframe oriented products and systems. In those days there was a real "split" between the mainframe forces and the desktop proponents. I always found this to be amusing since both had so many positive things to offer an enterprise. I could never understand why anyone would offer one at the exclusion of the other.

My present role at Cincom involves a number of things including product security, pricing, finance packaging and industry research.

My wife, Barbara, and I reside in Park Hills, KY. I am a member of Blessed Sacrament Church and I am active in a local car club, Cincinnati Cruisers. We are a group of PT Cruiser owners who enjoy tricking out our cruisers and driving around annoying people who have to drive boring cars. I am the webmaster for the Cruisers and I invite everyone to visit www.cincyptcruisers.com and check out our awesome rides! Barbara and I both enjoy photography, travel and our two four legged canine children, Chloe and Cookie.