In this TechTalk video, storage expert Jon Toigo detailed best practices when dealing with virtualization and disaster recovery planning. The two technologies can work together, but users need to know what they're protecting and devise the right approach.
There are three requirements DR plans need to cover: how to recover data, rehost applications and re-instantiate networks, said Toigo, CEO and managing principal of Toigo Partners International and chairman of the Data Management Institute. Without a plan, your organization does not have true disaster recovery.
What does your organization need to recover? Toigo runs through possibilities within a virtualized environment. Be especially wary of hypervisors, he warned, as they can complicate disaster recovery.
If you go the route of disaster recovery as a service (DRaaS), or DR in the cloud, vendor selection is crucial. "There are a few companies that actually have been steeped in DR for a very long time, and they know the game," said Toigo, who cited Sungard as an example.
But other vendors that offer DRaaS "have no pedigree in disaster recovery at all," Toigo said. "I worry sometimes that people are signing up for DR as a service contracts and they don't even know where the facility is that they're going to. ... If you get stepped on with a big elephant footprint and it kills the building across the street too and that's where your cloud is, you're kind of out of luck."
Everyone must do their due diligence when implementing a virtualization and disaster recovery strategy. "[Users] need to go out to these new services, inspect their facilities [and] understand what their real competencies are," he noted. "You've got to do all the same stuff you would have done if it was a hardened facility that you were subscribing to as a hot site, or if it was a secondary facility you were building for yourself."
Toigo also discussed ways a business can start disaster recovery planning and testing. As long as you're doing some planning and testing, he said, you're on the right track.
Transcript - Virtualization and disaster recovery: Plan your strategy
Editor's note: The following is a transcript of a video clip from Jon Toigo's TechTalk discussion with Paul Crocetti, a site editor in TechTarget's Storage Media Group. The transcript has been edited for clarity.
What are the most important elements of a disaster recovery plan for a virtualized environment?
Jon Toigo: Disaster recovery plans have always been driven by three requirements. You have to recover your data, you have to rehost your applications and you have to re-instantiate your networks. However you do that, it needs to map to the recovery objectives associated with an application. If that application must be recovered without any loss of data in four minutes or four hours or four days, you need to know that. So when you're doing planning, the first and most important task is the upfront analysis.
Applications and data are a bunch of anonymous ones and zeros. They have no criticality. You have to associate them with a business process. The business process determines the importance and relevance of the support infrastructure, and the supporting applications and data. If we aren't clear on that, we're backing up boxes. And that's not a solution, that's not disaster recovery. In fact, that's kind of harebrained. You have to know the bigger picture.
Without doing the formal DR planning activity, you're never going to know what the criticality is. You may not even correctly identify interdependencies between different applications. You may think you can recover a given virtual machine (VM) and that will work out just fine. Except what you're forgetting is that some of the inputs required for the applications running in that VM are on that VM and others. You have to decide if you need to recover those, too.
At the same time, is just recovering the VM enough? Or do you also need to capture a bunch of data around it, the configuration details for the server, the operating system? It depends on the kind of virtualization you're using. There's a whole lot of additional data and a whole lot of additional software that you're probably going to have to capture and re-instantiate somewhere, which you completely miss if you're just doing what your hypervisor vendor tells you.
Finally, a hypervisor is supposed to be the big win for everybody in DR. It's supposed to simplify everything. Except if you look at the current data, even if the analysts are right, about 69% to 73% of our applications are totally virtualized -- that leaves us with 25% of our applications that aren't. Those 25% are high-performance transaction processing systems, the ones that nobody virtualizes because they don't want to slow them down. They are the moneymakers for the company. Where's the hypervisor-based solution for them? You've just increased the number of DR targets you've got.
For every hypervisor you've got now, every hypervisor vendor wants to create his own proprietary stack of software and hardware underneath his hypervisor. Every single one of those is an isolated island of data, and every single one of them is going to need some disaster recovery plan. You have not made it simpler; you've made it more difficult.
You want to do [virtualization and disaster recovery]? That's cool -- just be real about what the impact is, and make sure you're protecting yourself. Because these hypervisors are powered by Jenga -- one app crashes, [and] they all come down.
What are some tips for businesses starting DR planning and testing for the first time?
Toigo: There's absolutely no wrong way to do it. Don't believe anybody who says they're the guru of DR. Disaster recovery has no gurus. It's a straightforward application of common sense. It doesn't require a college degree. It requires somebody who can think systemically through a series of problems.
And write it down so you can test it. Then you can erase it and rewrite it to fix whatever is wrong. It is not rocket science. Oh, wait, it is kind of like rocket science.
But just by taking the initiative, you're already further ahead of the game than you think. Your mind is already prepared for the possibility. Now you need to sort through the list of options for recovering the different environments, and make sure you can reach the priorities for restore that are required and test on an ongoing basis, because nothing stands still. The business changes; the technology changes. So you have to consistently keep it up-to-date with the way reality looks at any given time. There's no wrong way to do this, except not to do it.