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.
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.