Disaster recovery planning is a pain point for many organizations. Here's one IT disaster recovery (DR) planner's wish list for 2011.
1. More than anything, I'd like to have a set of reasonable recovery expectations on the part of business managers. They want all of their applications recoverable quickly, and with no data loss, but they don't want to pay for it. So they fudge the figures, tell their bosses that their systems are critical because their jobs are critical. And then they tell me that they can get along without them for a week because they don't have the budget for recoverability.
2. I'd really like to have some data storage estimates that are more than guesswork. I don't know how much data I have, how much space it takes up and how often it changes. So I allocate storage for the maximum I think I'm going to need for online backups, then bump that up by 20% for unusable white space and hope I don't need to go back for the budget for a few years. But with 35% year over year data growth, there's twice as much of it in fewer than three years. Please give me a way to figure out how big my storage arrays have to be.
3. I could really use a disaster recovery network. The truth is I'm sending tons of data over the same network that the business functions use and there's always contention. So either I reduce my data replication intervals so that they're small, but there are a lot of packets. Or, I make the intervals longer, sending fewer but bigger packets so I don't risk not meeting my data loss objectives. In the meantime, every network slowdown is blamed on me. If I had a network I could call my own, I'd know the true cost of recovery for highly critical data, and users would have to find someone else to blame for lousy response time.
4. I'd also like a good book, like maybe Virtualization for Dummies. I admit that I'm the dummy. I keep hearing about how virtualization is going to solve all my disaster recovery problems, but all I see in front of me are critical platforms that cannot be virtualized. That's because of applications that cannot be migrated because of the complexity of source code, application operating environments not suitable for virtualization, high-performance transactional queries that obviate current virtualization capabilities, and so on. And, even if some of the applications can be virtualized, they're part of bigger applications that run on platforms that can't. So I'm stuck right back where I was.
5. I could use something to put up on my wall, like an organization chart that makes sense for IT disaster recovery. I moved away from commercial recovery services years ago, and my boss was very pleased that he didn't have to write those big checks any more. But he doesn't realize that my internal disaster recovery center is just like a commercial service, except I have to staff and operate it. I run hundreds of application recovery tests every year, set up applications in an active-active recovery mode and find ways to reduce cost by repurposing servers when they aren't needed for disaster recovery. IT recovery implies a specialized set of procedures in a data center and needs specialized people to perform them. So a management structure that's tied to the realities of recovery would help me a lot. Could you help me make sense of the deployment of personnel, reporting lines, disaster recovery metrics and my staff's performance expectations? A little respect for what we do would be really nice, too.
6. And while I'm asking about people, could I have a few more? My role and that of my DR staff seems so simple to some people. In their eyes, all I do is keep the machines well oiled, test them now and again and wait for a disaster to happen. They don't see all the work that goes into managing the consistency of production and disaster recovery equipment, infrastructure and applications. They don't understand the amount of staff time that's required to collect and report on key metrics that measure my current recovery risk position relative to established benchmarks. Above all, they don't know how much work it takes to help each new application development team determine their real disaster recovery requirements in technology terms. That's why I can provide the environment for them to test recoverability and exercise it on the day they might need it. Is a little headcount too much to ask for?
7. I would really like to have some business continuity (BC) standards that stick. Not those loosey-goosey ones that everyone likes but no one follows. I'm talking about a common platform for servers, storage, operating systems, network interfaces and the whole kit. With BC standards, I'll always have a recovery environment that looks the same as the one in production without having to search for every discrepancy and inconsistency. Also, I won't get the blame when tests fail. It will go to those folks who insist on the technology they like instead of something solid that I can build better recoverability -- and give the users better systems, too.
8. For this last request, it will be okay if you don't give it to me this year, as long as you promise that I can have it soon. I want a cloud. For years now, I've heard how the cloud will solve all my problems. I've been promised disaster recovery-as-a-service as soon as they can iron out a few bugs. It just seems to me that cloud they keep talking about is just so much hot air and mist. I really like the idea of built in data replication, site independence and on-demand testing. But every time I think the cloud is just about to arrive, it gets scattered by the strong winds of cost and the problems of serving a widely dispersed user population.
So please be good to me, Santa. I've heard that all you ever give disaster recovery planners is lumps of coal. I know; I've taken my coal over the years. But I've been good this year. If you can't give me everything on my list, maybe you could manage just one?
About this author: Steven Ross is an Executive Principal of Risk Masters Inc. and holds certification as a Master Business Continuity Professional (MBCP). He is a specialist in Business Continuity Management, Crisis Management and IT Disaster Recovery Planning. He is editor of the multi-volume series, "e-Commerce Security," and author of several of the books in the series, including "e-Commerce Security: Business Continuity Planning."