The challenges of disaster recovery as a service

Backing up your data and running your systems in the cloud is attractive -- but likely to fail if you don't treat it like a physical warm-site backup

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.

Those measures alone usually suffice when your offices have been rendered unusable, so your employees are working from home, but by no means is it the only disaster that could require use of your DRaaS. Much more isolated disasters such as catastrophic storage failures and water leaks could easily destroy your on-premises server infrastructure while leaving the rest of your premises usable. In these cases, you have to devise a way for your server infrastructure to function in the cloud while your employees remain on-site.

This becomes a much more complicated problem to solve. You effectively need to plan for your entire server environment, along with the network segments it lives on, to be transplanted from your data center to the cloud -- all while leaving the rest of your on-premises environment untouched. There are several ways to do this, but it typically involves Layer 3 segmentation of the on-premises network along with a site-to-site VPN configuration that will involve the cooperation of your DRaaS provider.

1 2 Page 1
Page 1 of 2
How to choose a low-code development platform