The Basics of Outsourcing Disaster Recovery
Several flavors of DR-as-a-Service exist. One might fit your needs, but be aware: They don’t take all the work off of your hands.
Resilience is a crucial point for enterprise administrators today, and figures released by Forrester Research show that 42 percent of companies are outsourcing disaster recovery (DR) services in some fashion. But all DR-as-a-service (DRaaS) solutions are not the same, and navigating the various options and offerings can be daunting.
Determining what your enterprise needs in a solution is the first step. Everything from the infrastructure requirements of in-house applications to uptime expectations are likely to come into play. Christian Teeft, CTO of Latisys, said customers often don’t know where to begin, so his team sits down with them and “starts unpacking their requirements and tailoring our DR offering to their needs.”
One flavor of DRaaS focuses on infrastructure. It typically comes into play when you have one data center and need a second one—either in the cloud or at a provider’s physical location—that can function during a disaster. “That’s the most common and traditional option for outsourcing disaster recovery,” Souvik Choudhury, vice president of product management at SunGard Availability Services, said. In this scenario, enterprises are responsible for bringing their applications up in the event of a failover.
The second variation is a more turnkey approach. The enterprise makes a call and the DR provider makes sure the applications get up and running. “The work is all done by the DR provider’s staff, and the infrastructure is also provider by the DR provider,” Choudhury explained.
How do you decide which strategy is right for you? Rod Mathews, general manager of storage at Barracuda Networks, said one factor to consider is what sort of application or asset you’re likely to need to fail over in the event of a disaster. “If it’s your transaction processing system and you’re a large bank, that’s going to have one set of criteria. If it’s your external website, it will have a different set of criteria,” he explained. How close that resource is to your core business will help to determine how quickly—and through what process—your DRaaS needs to function.
Some tasks are still on you
No matter which strategy you choose, there are a few things DRaaS can’t do. One is ensuring the solution works as expected. “The most important thing is testing the environment to make sure you can actually fail over, that the applications actually work the way you intend them to work, and that they actually provide the level of service you need in order to continue to operate your business,” Mathews said. It’s an area often overlooked (either by accident or by design) by enterprise customers, because the process can be time-consuming and disruptive. “If people haven’t done this before, they might have the expectation that when they failover, everything is going to be exactly the same,” Mathews said. “And that is generally not going to be the case.”
Some DRaaS providers provide customers with a nudge in the right direction when it comes to testing their chosen solution. “DR providers themselves may have specific testing requirements or testing disciplines they will force on the customers,” Choudhury said. This helps enterprises conduct the right testing to ensure everything works as expected and provides the opportunity to resolve glitches before a real disaster occurs.
Choudhury said another ongoing issue administrators and CIOs will need to address is the need for a “clear understanding of the key business processes running in the data center and how they map down to the application and infrastructure layer.” This may include resources and dependencies, such as 800 numbers or externally-supported portals. How they will be coordinated in the event of a failover is typically outside a DRaaS provider’s sphere, so be sure your team is ready to manage them as necessary.
Enterprises with lean internal resources may want consider how much support they’ll need in terms of recurring communication and coordination. Latisys, for example, works with clients on a quarterly basis to carry out testing and post-failover evaluations. “The reason we do that is because systems are live, and we want to make sure the sequencing is always the same,” Teeft explained. If a change has occurred and a website that used to be the first asset to failover should now be bumped in favor of a crucial database, the enterprise will need to coordinate that change with the provider proactively.
Remember, too, that someone within the enterprise will need to trigger the failover process when disaster strikes. “If there is an event, we’ll reach out to the customer,” Teeft said. “It’s their call at what point they want to fail the systems over.” There’s typically automation behind the scenes to make the failover happen, but rarely is there automatic failover capability. This is because a disaster may, in fact, be short-lived, and the enterprise would prefer their website go down for a brief period rather than initiate a full-scale failover. “I think that’s really important, because it’s their business that’s on the line,” Teeft said. A DRaaS provider facilitates the resources needed to failover, but it’s the client’s responsibility to make the business decision on when it’s appropriate to do so.
