Just about every organization that takes recovery seriously has some kind of disaster recovery (DR) plan in place. It should be detailed, spelling out what needs to be recovered, in what circumstances, how, in what order, and how quickly it all needs to happen. To many, it seems like disaster recovery testing should be redundant. Is it?
At the end of the day, a plan is just theory; it is a well-educated best guess of what needs to happen should there be a material loss of operations. Not play that last sentence backwards – should a “material loss of operations” be addressed with a “well-educated best guess”? Obviously not. We’re talking about the viability of your organization here!
What’s needed is an actual test of the DR plan – a simulation of a loss of data, application, system, workload, or location that requires you recovering all related parts of the business and ensuring there’s an ability to actually operate in that recovery environment.
Now, you might have an extremely detailed plan and, like most organizations, have little time to actually run a simulation test, but let’s cover 3 reasons why and actual DR test is necessary.
Three Reasons You Should DR Test
- It’s More Complex Than You Think – DR is about business resiliency, and yet, IT tends to think about things in technical terms. In other words, IT is likely thinking about the tactical steps to get that data base server back up and running, whereas what’s needed is to resume the part of operations in which that server plays a role. DR testing allows IT to see the results (or the lack thereof) of its’ efforts; once the database server is restored… then what? Is it time to high five each other, or actually see if the business could operate using that recovered server? DR testing provides the answer.
- DR Won’t Happen Like You Plan – Computers, applications, and data tend to act the same way every time. IT leans on this truth (perhaps a little too much), expecting a certain outcome. But, as we all know, that is most definitely not always the case. There will be exceptions, one-off issue, related workarounds, forgotten dependencies, etc. when executing the DR process. DR testing exposes those so they can be incorporated into the actual plan.
- Almost No One is Really Testing – According to industry reports, an average of 28% of organizations do no testing at all. And of the various types of testing, the overwhelming majority either simply review the plan (“Yep… looks right to me” isn’t a testing strategy) or do a tabletop walkthrough (which still sits firmly in the “in theory” category). It’s only through a DR simulation that you’ll be able to truly know if what you have planned will work.
DR testing is like the chef sipping on the soup to see if it tastes right, the mechanic giving your newly fixed car a test drive, or you laying down on a mattress before you buy. You’ve got to test your DR plan – really test it. If you’re not doing DR testing, it’s time to schedule your first simulation test. By doing a practical DR test, you ensure the plans and claims your DR strategy includes will function as desired at a time when you can’t afford to be wrong.
Get Started With Disaster Recovery Testing
Disaster recovery testing can make the difference between a successful recovery and an unfortunate loss. If you have a DR plan in place and have not recently tested it, we can help! Contact a CyberFortress representative today and get started on your DR testing today.
