When you think about putting together a disaster recovery (DR) test plan, thoughts almost always go to which servers need to be included, what user accounts are involved, what applications will be impacted, and more.
But then there are all the very specific details that are needed to ensure the success of a recovery. For example, you may change a recovered server’s IP address and, in order to take advantage of the service it runs, a second recovered server may need that new IP address updated in its’ configuration. It’s these little details that can make or break a DR test. And yet, many DR testing plans stick to the high-level steps to craft a DR testing script.
So, why should you include detailed specifics into your DR testing?
There are three reasons why you need to make certain your DR testing plan includes every last relevant little detail:
- No Workload is an Island – For any given system, application, service, or platform you host to support operations, there are going to be a number of factors the success of a recovery test (and therefore, an actual recovery) is contingent upon. This includes service and system dependencies; specific network, OS, and network configurations; and security/firewall settings, among others. Including tasks that address all these details in as part of the testing script is necessary for success.
- No Organization is Either – Many applications require a partner, contractor, supply chain, etc. on the other end to be successful. So, when you test “your half” of the DR, as it were, if you don’t include details on how to test your applications connectivity and compatibility with any other organization it talks to, you can’t be certain recovery will be successful. Including these kinds of details to be testing need to be included and, somehow, addressed.
- Things Change – The state of IT is never static. Updates, upgrades, new applications, new integrations, custom code, and more all make the test details used 6 months ago less than viable. Keeping DR testing details updated is necessary as changes are made to the environment. The less frequent the testing, the more updates are necessary.
DR tests can’t exclude all the specifics that make up your environment. Without those details being both included and replicated during testing, you’re going to find yourself sitting on the failing end of what should have been a relatively easy DR test.