In the previous blogs in this series, we talked about how the emergence of cloud has changed the approach to Disaster Recovery. in today's IT world. These changes have ranged all the way through the DR process, from the Business Impact Analysis, to the Disaster Recovery Plan, and to the Infrastructure. Today, I want to focus on probably the most overlooked portion of a successful DR Strategy. Disaster Recovery Testing.
What is Disaster Recovery Testing?
Sounds simple right? Pull the plug, execute the failover, work on restore. It works just like the last time. So why are we doing this again? Well, as Lee Corso says every Saturday morning in the fall..."Not so fast!" Testing is much more than a simple test of the process and tools. It's really about the process and the people.
Successful Elements to Disaster Recovery Testing
First, start with the idea of an actual disaster. You don't typically PLAN for the disaster, and you certainly don't schedule a disaster. So why would you schedule your DR Test? Trusting the execution of the plan to a select few individuals in IT is a dangerous proposition. In an actual disaster, it's possible that those individuals will not be available. So this starts with a testing process that takes this into account. I have one client in particular that abides by this. Sure, they do schedule the test, but...certain people who may assume they have a role in the testing might be told at the last minute, you are not available. This is where the documented plan we talked about in Part 2 becomes so important. Several people in the organization should have access and some level of familiarity with this plan, so that when they are forced to execute, they at least have a roadmap.
Pull the Plug
I have another client that says to me everytime we deploy a new solution, "The first thing I will do before we go live, is pull the plug". What he is talking about are the access connections from ISP, to Firewall, to Switch, to Server, to Storage etc. He wants to make sure of two things; 1) Redundant Connectivity for High Availability, and 2) Ability to recover from an outage. So in a test, don't just simulate the failover and restore, actually pull some plugs.
Disaster Recovery Testing in the Cloud
Much like we talked about in our infrastructure section, DR in the cloud offers you the ability to only pay for infrastructure when you need it. For example, during a test. Additionally, many of the solutions today offer some automation for the test that will actually speed up the testing process to minimize the spend for DR resources in the cloud during the actual test. Anthony Spiteri from Veeam does a great job of explaining how Veeam CloudConnect provides this in his blog. Ultimately, automation is a good thing. However, like I said in the first section, don't count on things going smoothly, and even though you have your data, safely tucked away in the cloud somewhere, really work on the variables that may arise in an actual event during your test.