Welcome to Part 3 of my blog series on considerations for DR. In this series I answer the questions I’m commonly asked by our customers and partners. I’ve saved the best for last…
Q: How can I ensure my DR strategy will work?
A: Plan, Plan, Plan, Test, Test, Test, Validate!
Possibly the most important aspect of disaster recovery is what has to be done before any implementation is carried out. Plan and then plan some more. Analyse what data you need where, what classification of data do you need, and how are you going to achieve the goals set by the business to mitigate against the risks associated with disasters. Don’t forget that there are varying levels of disaster—from a service outage to data deletion, and all the way up to a full site failure. All of these aspects need to planned for and the correct solutions applied, all without breaking the bank!
Careful considerations should be made around planning based on the business needs. It’s the business need that will form part of the technologies that need to be sought to allow business continuity throughout the period of recovery from disaster.
So now we’ve planned what to do in a disaster, what happens when you have successfully run you DR plan? For me, Disaster Recovery is two words, plan for the disaster and then plan for the recovery. It always amazes me how many people plan what they are going to do when disaster happens but forget to plan what to do after that. What happens on day 2 or day 3 or day 4? you get the idea! Then, when you want to go back to your production site and systems...? Oh no plan for that? hmmm…
You could almost view ‘Disaster Recovery’ as a hint to what you need to plan for, plan for the disaster and plan for the recovery.
The next steps will be looking at returning back to your production environment. Again, judicious planning is needed. We now have a similar set of challenges that were planned for in the original disaster. We still have to return the service applications back to an operational state in the production environment. But again, let's not forget the datasets behind those applications. If the original DR plan was successful, great, give yourself a pat on the back. But now all the datasets have changed while running in the DR environment. Can you replicate the changed data back?
If you virtualised, are your VMs up to date? Can you reverse your SAN replication? Can you deliver back the service and the up-to-date datasets back to the business just as smoothly as your disaster plan?
Just as important as planning and implementation is testing that your plan works. Make sure you build in adequate resources that allow you to regularly test both your disaster and recovery plans. This is an essential part of a DR solution, if it’s done properly. Why not regularly switch between your production site and your DR site? This will soon find any holes in your plans! Don’t forget the smaller areas of disaster either; always test your data protection with data restores. Make sure you can restore good consistent datasets across all the different classifications of data you have—static, and business vital and mission critical—and don’t forget to validate the data. Once restored, use the data: open it in its respective application and ensure it’s usable again.
Well, there we are: Some things to think about around disaster recovery. Hope you enjoyed this series. If you have any questions, please feel free to contact me at… firstname.lastname@example.org or follow me on twitter @AdrianMoir