There’s a fine story by Jacob Gsoedl over at SearchDisasterRecovery.com called, “Disaster recovery in the cloud explained” that makes for good reading.
Gsoedl provides a good overview of matters. I would like amplify one topic that I think deserves more emphasis than Gsoedl provides – testing.
As one of our customers recently put it to me, “You don’t actually have a DR plan if you haven’t tested it.” Meaning, you can spend all the time and money you want on a DR solution, but if you don’t test it, then you won’t really know if it works until you experience a disaster. And that’s a lousy time to learn for the first time what gremlins there are in your failover, runbook and failback procedures.
This same customer explained that when he tested his nScaled Disaster Recovery service, it turned out that one of their key applications, a piece of proprietary software, had IP addresses hard coded into it, causing it to fail during failover when new IPs were assigned. The test revealed the issues, they fixed it, re-tested, and now this customer has peace of mind that, in case of a disaster, this crucial app will keep working.
Not only do something like half of all US businesses have no DR plan or solution in place today, but a lot of the ones that do have DR have never adequately tested their DR, which is the same as not having it.
So why don’t companies test their DR? The reason we’ve heard most often is that it’s not only time consuming for the IT staff, but it also interrupts day to day IT operations and end users. This doesn’t have to be the case. nScaled’s approach is to offer our DR customers two VLANs as part of their hybrid cloud DR service. One is the production VLAN they would use in an actual failover, the other is a Test VLAN that they use to test the DR solution. The Test VLAN doesn’t interfere with operations, so testing becomes much easier, so it gets done.