Azure Site Recovery Video Series

Our education customers across the country put forth a significant effort to ensure their environments are resilient, highly available, and protected from data loss. They most commonly achieve this using backup software combined with offsite tape storage, or replication of their backups to Azure for long term storage. Often, however, I hear stories of organizations that experience dramatic and unexpected failures because of water leaks, fires, or other unexpected circumstances. These events often require more than a backup because they’ve lost significant physical equipment, or for some other reason, cannot bring their environments online even though they have backups.

Azure Site Recovery provides a true disaster recovery solution that lets these organizations bring up their replicated workloads in Azure or in their own secondary site. Azure Site Recovery can protect physical servers, Hyper-V virtual machines, VMWare virtual machines, Amazon EC2 instances, and several other workloads. Replication is fully configurable across 30 second, 5 minute, and 15 minute recovery point objectives.

The following video series describes the various use cases and walks through the process of configuring Site Recovery, replicating workloads, and testing recovery, which allows organizations to iteratively test recovery until they have a plan that is orchestrated to bring up the environment exactly the way they would want to do in a true disaster.

Comments (2)
  1. Nightwolf_82 says:

    Hi Eric,

    First of all thank you very much for this series of videos. They are really helpful. I have a question however, which I hope you will clarify for me.

    In your diagram you have on-premises site and site on Azure. Once failover occurs and one-premises site startup in Azure, how subnet (VNet – Infrastructure) communicate with subnet (VNet – Recovery)?

    I would be immensely grateful if you could explain this part.



    1. Hi Alexander,

      Thanks for your question.

      The diagram of networking assumes a few things:

      1) The VNet-Infrastructure is actively being used by an organization with an established VPN or ExpressRoute connection.
      2) The VNet-Recovery is isolated to itself and is used for testing failover OR used to failover workloads during a whole datacenter failover.

      A few things to consider:

      1) Most disasters are micro rather than macro disasters.
      2) In a micro disaster, you wouldn’t be able to use the VNet-Recovery, because you couldn’t route between two networks of the same address space.
      3) In a micro disaster, you would bring up the failed services (maybe a rack of servers flooded by water), into the VNet-Infrastructure, which would be live and actively routed back to your on-premises datacenter. You would simply adjust DNS (or hopefully it would be automatic with DDNS) and you would recover from a micro-disaster quickly.
      4) In a macro disaster, you have presumably lost your entire datacenter and need to recover everything. In this case, why not just use the same address space?
      5) In a macro disaster, with workloads running in both VNet-Infrastructure (the previous workloads migrated to Azure), and VNet-Recovery (the failed over workloads), you could then connect these two networks with VNet Peering in Azure.

      VNet Peering:

      I hope this helps.


Comments are closed.

Skip to main content