Three ways to protect your customer's on-premises data with Azure: Part 3 - Azure Site Recovery

Three ways to protect your customer’s on-premises data with Azure: Part 3 – Azure Site Recovery

In the previous two posts we looked at:

Azure Backup (using the MARS agent)
Azure Backup Server (free DPM server)

Those two solutions are markedly different from one another, but they both basically provide some kind of backup. The former does only file, folder & system state information–no application data is possible.The latter will do application data, including SQL, Exchange and virtual machines from Hyper-V or VMware, as well as bare metal restores of physical servers.

But the last solution we will talk about is really just targeted at true DR: replication of full servers into Azure (so you can run them as virtual machines in the cloud). This is typically only necessary when you have or expect a complete loss of the primary datacenter, with no local hardware to which you would restore for an extended period of outage.

For today, I want to review the basics of ASR architecture, and certain other considerations.

A closer look at ASR architecture

The other important thing to realize is that ASR is an incomplete solution if all you do is setup the vault and turn on replication. That is not a DR strategy. When sh*# hits the fan, what good do those servers in the cloud do you? In short, you need an infrastructure in place up there, so that you can actually use the failover feature and get users connected to the environment (usually via Remote Desktop Services and/or VPN).

Image credit: Alex Fields, ITProMentor.com

As you can see from the image above, an Azure provider / agent is still at work here, only this time it is configured on the Hyper-V host. Note: it is also possible to configure this solution with VMware, but you will need to elect another Windows system on the network for the task of pairing with your Azure Backup & Recovery vault.

What I would recommend to complete this solution is:

Azure Virtual Network – have one ready to go with subnets and everything you will need (this network is where VM’s would be restored into, in Azure)
Site-to-Site VPN – Even if it isn’t always on, know how you can get the tunnels up in advance, and test it
Domain Services – Maybe a small VM stays online up there to run AD/DNS services, replicating information from your on-premises environment (requires the always on S2S VPN)–this can make recovery a bit quicker and provides fault-tolerance for your core domain services
Remote Desktop – Have a server ready to go with this service, even if it is offline most of the time. Or, if you have this service on-premises and you are replicating it, know that you may have some DNS reconfiguration to do, in order to get clients reconnected to it after failover (do you have a static IP provisioned in Azure that you can use for this?)

That’s what I’d call out, as a minimum. If you are providing a different connectivity option, then just be sure it is actually tested/validated so that you can ensure a smooth recovery. And of course: plan for failback. You want to be able to failback to your on-prem servers eventually, unless you are using ASR as a one-way migration tool. Therefore, part of your DR plan should include a failover and failback test, so you know what your full recovery strategy looks like.

Pricing considerations

There will be a small per-instance fee to replicate a full virtual machine to Azure. In addition, you will also pay for storage space and other related costs, just like always with these vaults. Check out Azure pricing for more details.

Obviously the additional infrastructure we just discussed will come with a cost as well, so don’t forget to account for it. For most small businesses, the infrastructure solution I most often describe with a single small domain controller in the cloud, on a S2S Basic VPN-connected Virtual Network will clock in under USD $100.00/month pretty easily. And this just means your DR site is always-on and ready to go. It is optional of course, but recommended if your downtime tolerance is very low, and you need to support quicker Recovery Time Objectives.

Retention considerations

You can only retain recovery points for up to 72 hours on standard storage (and only 24 hours on premium storage). Therefore, the use case for this service is limited in scope to true immediate DR-type scenarios, and not backup.

Azure Site Recovery is only providing a current image of an entire system, and you would not refer to this image in order to say, restore a file or folder that someone accidentally deleted, or something like that. You would restore the entire VM, usually in an Azure network.

So implement this solution as part of a DR strategy–e.g. How can I get my systems back online quickly if everything is down in my datacenter? But I would still recommend a backup be used in conjunction with this solution.

Key takeaway: ASR is not meant to replace your backup. If you want to use ASR as one of your three “backups” in a 3-2-1 solution, then great! But don’t neglect the other two. (3-2-1 = Three backups, two of which are on different media, and one of which is offline).

Conclusions

This is still a pretty great DRaaS product: affordable and easy to setup. However, in most cases where I’ve run into this being implemented, the whole picture wasn’t really developed, meaning the recovery strategy and infrastructure, and testing the failover/failback process.

My old articles are a bit dated now, and there have been some changes since that time, but for the most part it is still good for the classic deployment model. You can see that series here:

Another way to deploy this solution is by using the Azure integrations for Windows Server Essentials. This will deploy into Azure Resource Manager (ARM). That series is located here:

Three ways to protect your customer’s on-premises data with Azure: Part 3 – Azure Site Recovery