One of the biggest problems that plague a DR plan is atrophy. DR plans get set up, tweaked and perfected for some audit or compliance officer and then go untouched for years until the next audit, and then days or weeks are spent updating. Unless, of course, a disaster occurs. The only way to properly care for your backup and disaster recovery solution is to have updating the plan as part of every configuration workflow.
A server is built, set up, configured, the backups get configured, the server is moved to production, and the DR plan is updated, or a server is moved out of production, backups get archived, the server is decommissioned, and the DR plan is updated. If it’s handled in this manner, then the actual work of the DR plan is very minimal at any given time, and it’s always up to date.
Keeping the plan up to date is obviously very important, but if the plan is stored on the systems that just got destroyed, then it won’t do you any good in a disaster. Additionally, the passwords to access and control all of these systems need to be available as well because, remember, Active Directory may be down, so you need to be able to get into the server with local credentials. The Directory Services Restore Mode password can be huge in this case.
So where DO you keep the DR plans? Well, this is actually a good usage of cloud storage assuming you keep security in mind. Since the proverbial keys to the kingdom are being stored with these passwords and restoration methods make sure that the cloud provider is reputable and complies with security requirements. Obviously, it needs to be extremely well known within IT how to get to these plans and passwords, or once again, the effort to make the plans was pointless.
Where does all of this leave us? Well, in case you haven’t noticed, we’ve focused on everything about the DR plan except for the actual technologies employed. This was by design. There are dozens and dozens of technologies to meet any kind of RPO and RTO that you require, and there are a LOT of considerations that need to be taken into account when deciding on these technologies. All too often IT professionals latch onto the shiny new technology for solving a problem they may or may not have and forget to keep everything in context. That’s where we can come in, with our relationships with and knowledge of best of breed solutions and practices.
Hopefully this series helped frame the overall thought process one should take when it comes to approaching disaster recovery.
Check out last week’s installment on management buy-in, or click around the entire series:
- What is a Disaster?
- How to Construct a Proper Disaster Recovery Plan
- Technical Documentation
- End Users