By now, just about everyone is familiar with cloud-based backup services. Whether you're using simple file-based software tools or more complex image-based appliances, these services ship your data into secure cloud storage where it can be accessed at a moment's notice.
If you encounter a minor disaster (such as corrupted data), you simply download the affected files to your premises and get back to business. If you have a more severe sitewide disaster, you might need to source replacements to your on-premise server gear before you can do the restore. In both cases, online backup is in many ways similar to a traditional tape backup rotation that includes offsite tape storage -- except without the hassle of tapes.
Disaster recover as a service, or DRaaS, takes this concept a step further. Instead of just storing backups offsite where they can be restored to your premises, DRaaS offerings are coupled with cloud-based computing horsepower so that you can fire up your environment in the cloud as virtual machines, not just restore its data. DRaaS offers both offsite backup and a cloud-based warm site.
However, like constructing your own warm site, the use of DRaaS requires a significant amount of planning and preparation to use effectively in an actual disaster -- often requiring substantial changes to your on-premises network infrastructure. All too often, prospective DRaaS customers are wooed into a false sense of security by the capability to restore and run in the cloud, only to find that in an actual disaster their cloud-recovered environment is almost impossible to use effectively.
The fundamental requirements to having DRaaS actually work
The first challenge of using DRaaS effectively is to make sure you can actually reach your recovered infrastructure in the cloud. After all, just because your DRaaS provider can start your machines as VMs doesn't mean you or your users can get into them. Typically, you need to implement some kind of server-based virtual computing (such as Citrix or Terminal Services), which your on-premises network might not have already. Additionally, you'll need to make sure your DRaaS provider can configure the necessary firewall rules in its infrastructure so that you can access the resource and its Internet access capacity is sufficient for your users.
You'll also need to plan for any external network services you offer to be moved to your cloud-based environment. That could include simple things like ensuring your SMTP mail flow can be redirected to your disaster-recovery environment, but it may well also encompass more complex issues such as ensuring your DRaaS provider can implement a DMZ segment for any of your servers or other sites in a multisite WAN can reach the DRaaS environment.
The seemingly little details that can cause DRaaS to fail
Even once you've solved all those problems, you're still not quite done. Sometimes, the simplest items can bite you if you haven't thought through how you'll deal with them. For example, ensuring that users running from your cloud-based disaster-recovery environment can print doesn't seem like a big deal -- and many times it isn't -- but it's not a problem you'll want to find yourself solving in the midst of a disaster. In other cases, more complex problems such as how to allow a Windows-based server environment hosted by your DRaaS provider to reach a mainframe environment that might be hosted by a different disaster-recovery provider can be more difficult nuts to crack.
No matter what you do, never assume that a DRaaS or DRaaS-like functionality delivered by an online backup product will be useful unless you're able to thoroughly and regularly test it. A good rule of thumb is that the less frequently you test a backup or disaster-recovery methodology, the less likely it is to work the way you expect it to when needed. Furthermore, it's almost certain not to work if you never test it. Be especially wary of DRaaS offerings that do not include (or even mandate) regular testing.
Many organizations that desire warm-site functionality will find it cheaper and easier to use DRaaS than to design and build their own warm-site data centers. However, just because someone else is handling the work of ensuring your data is replicated off-site and can be recovered does not free you from the preparation, planning, and testing that would normally accompany a warm-site buildout.
This article, "The challenges of disaster recovery as a service," originally appeared at InfoWorld.com. Read more of Matt Prigge's Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.