Recently I’ve been working on various disaster recovery (DR) projects, most of them having VMware Site Recovery Manager involved. Although SRM can be an important part of a DR project, Site Recovery Manager isn’t Disaster Recovery.
SRM is tool which features some great DR automation, DR testing and auditing features, but it all starts with determining the exact requirements for Disaster Recovery & Business Continuity for your organization. These requirements define what DR scenario best fits the situation.
You might want to use SRM, but an active/failover site configuration can also be good option depending on the exact requirements. Also take a vSphere Metro Storage Cluster (vMSC) configuration in account; this is another option which lets you streched you storage solution over two or more datacenters. Don’t forget some applications offer high availability/disaster recovery options right out-of-the-box. The question is how to determine what scenario will suit your organization…
6 steps to a successful Disaster Recovery plan
In my presentation about Disaster Recovery at the Dutch VMUG Event 2012 I presented 6 steps which can help in organizing your thoughts about DR:
- Business Continuity Policy – What Business Continuity (BC) policy is valid for your organization? Are there any law and regulation requirements? What goals does your organization want to achieve regarding BC?
- Business Impact Analysis – What critical functions are present in your organization? Identify critical processes and resources and their interrelations. Determine Maximum Tolerable Downtime (MTD), Recovery Point Objective (RPO) and Recovery Time Objective (RTO) for IT services and applications.
- Develop a recovery strategy – Discuss a global DR scenario for your environment. Which technologies do you want to have in place? What geographical separation is required? How is data availability at the failover site guaranteed?
- Develop a Disaster Recovery plan – Get the necessary procedures in place, which recovery solutions are you using and which roles and tasks should be defined within the organization.
- Test your DR plan – Don’t forget! Writing your BC/DR plan is a first step, you should definitely test it to verify everything is working as designed. Make improvements to your plan based on the testing results. You should test your plan at least once a year, but maybe more often.
- Maintain your plan – And the last step? Well, when your BC/DR plan is ready and you everything in place, you shouldn’t forget to maintain the plan. You organization might change and thus the critical processes which are part of the BC/DR plan. An application might be upgraded or a new IT service in your organization should be part of the plan. Bottom line…your plan is a ‘living’ plan and should be maintained.
Don’t forget to also think about preventive controls to mitigate the risk of a disaster. E.g. UPSes or emergency power system can reduce the risk of power outage.
As you can see technology, wether it is SRM, vMSC or something else, is just supportive to BC/DR. In an ideal world (and yes, I know…the reality is sometimes different) BC/DR should be iniated by the business with technology supporting the whole thing.
I hope this will help you to think about BC/DR. I would be happy to discuss any questions you might have regarding DR, you contact me by e-mail at viktor at viktorious.nl.
Wrote an article about this topic. As an addition maybe this can help people to get on the road…
Hi Roy! Sounds good, I will certainly take a look at your PDF (didn’t know you published this….)