| Disaster Recovery, AAARRRRGGGGHHH | | Print | |
| Written by Gareth Eagar | |
| Tuesday, 08 August 2006 | |
|
The reaction of most people to being told that they need to develop a disaster recovery plan for their organisation is not one of excitement, joy and general well being. A lot of people consider it a waste of time that could be better spent dealing with issues in production, working on new projects, and so on. While you need to prepare the many different aspects of your organisation to continue in a disaster, this article focuses on planning for recovery of your IT systems. Of course just making sure that your IT systems can be recovered is not enough - you also need to develop your business continuity plan [ie, you need to keep the rest of the business going so look at facilities, telecoms, people, emergency communication methods, secure storage of paper records, etc]. Unfortunately the reality is that Disaster Recovery testing is important. If you haven’t tested recovery of your systems recently (that means within at least the last 6 months) you will have no idea of whether you could really recover your environment when things turn ugly nor how long it will take to do. There is a lot involved in preparing for DR, long before you even get to your DR site and start rebuilding systems. Frist you need to work with the business to determine the priority of systems, their recovery point objective (RPO) which is how much data you could afford to loose and their recovery time objective (RTO), which is how long the business can tolerate the system being unavailable for. Then you need to ensure that you’re backing up the right things and develop an idea of the strategy that you’re going to use to recover the systems. Perhaps you need to investigate some high availability solutions (if you have a near zero RPO or RTO) and figure out where you’re going to do the recovery (on your own equipment at your own off-site location or using syndicated equipment from a commercial disaster recovery site). You can then attempt your first test. And in the first test, it’s all about figuring out which strategy is going to work for rebuilding the systems and making sure that you document how you go about it. Don’t expect the first recovery to go to well either - in my experience most first tests have so many problems that they can’t be considered successfull if your objective is to have your IT environment up and running. However, if you start getting some documentation together and you figure out the major problems and put plans in place to overcome them, then in my opinion that was a successful first test. You’re made progress! Once back at the production site, you need to rectify things in the production environment that caused you problems, publish your first draft of the recovery documentation and then set a process in place to integrate change control with your disaster recovery plan (ie, for every change you need to consider it’s impact on your DR plan and modify the plan where necessary). You also need to make sure that your recovery documentation and your system backups are stored securely off-site so that they can be easily accessed if the worst case scenario happens and your production environment is totally destoyed. Once the first test is completed, start planning for the next test. You must keep testing and improving your recovery plan and also need to keep re-evaluating your strategy (including recovery time and recovery point objectives for each system, your testing and recovery strategy and the high level objectives of your recovery plan. Of course just making sure that your IT systems can be recovered is not enough - you need to also develop your business continuity plan [ie, you need to keep the rest of the business going so look at facilities, telecoms, people, emergency communication methods, secure storage of paper records, etc]. This article has covered some of the aspects of getitng a disaster recovery plan going from a very high level - there is a lot more detail that needs to be worked out. Look at the other articles on this site and our links to other resources and get going right now, immediately, don't delay - the sooner you start preparing for the worst, the better your chances of surviving a disaster. [Copyright 2006, Gareth Eagar] |
|
| Last Updated ( Tuesday, 05 December 2006 ) |
| < Prev |
|---|





