Backup and DR in the cloud: Azure Site Recovery

Microsoft Azure influences how we consume Azure storage for both backup and disaster recovery (DR) purposes. We’ve touched on this in each of the last two posts of this three-part series. First, through a discussion on Azure Backup, followed by a deep dive into Azure connectors.

In this third part, we’ll take a closer look at the Microsoft Azure Site Recovery (ASR) technology. We’ll highlight a few reasons ASR is attractive and shed some light on this technology.

Since Microsoft already has numerous technical ASR deep dives, my plan here is to bring awareness to ASR’s and Azure’s DRaaS capabilities and benefits.

What is Azure Site Recovery?

Azure Site Recovery, recognized by Gartner as a leader in DRaaS based on completeness of vision and ability to execute in 2018, is software that’s designed to help ensure business continuity by keeping protected workloads running during outages or failures.

In near real-time, it replicates either physical or virtual workloads from a primary site to a secondary site. That secondary site could be another virtualized platform, or more commonly, the Azure cloud.

When disaster strikes, protected workloads fail over to that secondary site and are brought online.  When things are all clear, you can fail back to your primary location.

We see the most popular replication scenarios in the following order:

• On-premises VMware VMs and Hyper-V VMs (Win / Linux) to Azure.
• Azure to Azure
• Physical servers to Azure (Least popular as most organizations are highly virtualized today)

Azure Site Recovery has many attractive qualities

Azure Site Recovery is attractive for many organizations for four main reasons:

1. Cost – It’s designed to be very cost-effective by leveraging hyperscale resources across multiple locations. Capex costs for datacenter builds and equipment purchases to support a DR initiative have been tremendously reduced or eliminated. Microsoft is looking to democratize DR for the masses.
2. Ease of deployment – You can typically get the solution deployed in your environment in 30 minutes using the prebuilt Configuration Server OVF (VMware) available in the Azure portal. Major improvements have been made to remove the complexities of setting up DR, failing over and back. Additionally, integrating it with many of the Azure services makes DR into cloud as seamless as possible.
3. Ease of testing – ASR offers the ability to test and retest your business continuity by simulating an entire system failover without impacting your operations or jeopardizing regulatory backup compliance. What good is a recovery plan if you can’t validate it? By streamlining the testing process, more frequent and less painful testing can be achieved.
4. Ease of migration – Yes, that’s right! What if you fail over to the cloud and everything works as planned – do you really need to move it back? DRaaS can be a stepping stone to get familiar with running production workloads in the cloud. It’s not uncommon for customers to split their workloads into Azure in a multi-cloud or hybrid cloud fashion.

Things to remember when considering Azure Site Recovery

Before you get started, consider the following best practices:

1. Engage a partner who’s done this many times over. They can share their lessons learned and save you time, money, and mistakes.
2. Evaluate your applications and process to define your recovery point objective (RPO) and recovery time objective (RTO).
3. Assess your environment by leveraging your data to drive your outcomes. The right partner will help you collect the right data and determine what’s feasible based on the existing design constraints. For example, it’s not uncommon for a customer to lack the bandwidth to support the RPO needed based on the rate of change happening within its systems. Knowing what is available allows us to model what’s actually feasible so there are no surprises.
4. Make sure you understand the cost to maintain ASR and the necessary storage, as well as the cost to run in Azure (during a testing or real DR). For example, using premium storage vs. standard storage.
5. Implement clear roles and proper security using ASR built-in roles for role-based access control (RBAC).
6. Properly monitor your replication health and protected workloads.
7. Design your network to allow for non-invasive failover.
8. Document and test. Testing should be easy with a well-designed network and run book.

If you’re new to ASR and would like to learn more, contact your SHI account executive.