Skip to content

Understanding Azure Site Recovery

Microsoft AzureAzure Site Recovery provides offline copies of your virtual servers replicated to Microsoft every 15 minutes. Since 2008, the technology has existed to replicate virtual servers from a physical network across the Internet to another facility a few miles or many hours away. While disaster recovery became somewhat easier to implement, there were still four major problems:

  1. Duplication of hardware costs and software licensing.
  2. Significant monthly fees for disaster recovery facilities and Internet bandwidth.
  3. Maintenance and monitoring of disaster recovery systems are often lacking or non-existent.
  4. Failover testing to the disaster recovery site and back to headquarters was time-consuming and costly.

Azure Site Recovery Example

In the event of a real disaster, you also have to ask:

Would the staff leave their families or be capable of getting to the disaster recovery site safely?

What happens if the disaster recovery site is also destroyed and where is our data/system then replicated?

How would we recover if the Information Technology people didn’t survive or weren’t available?

Azure Site Recovery is just one component of our Orbit® Cloud Computing services. By leveraging Microsoft hyper-scale infrastructure and security with our Delta® methodology, we’ve changed the approach to modern disaster recovery. Anywhere people can access the Internet, they can securely access systems without risking their lives getting to a facility that may not be functional. For nominal cost, data is replicated to another datacenter in a different region or around the globe. If we aren’t available, processes are documented with customer’s having co-administrator access and the added ability to call on Microsoft directly.

Here is how site recovery works:

  • Site-to-site Virtual Private Network: You must use a router or firewall capable of supporting Dynamic Domain Name Services (DDNS) and establish a secure connection to Microsoft.
  • Cloud configuration: A remote network, storage, and recovery groups of servers to start in a logical order are setup and documented. Once enabled on required Windows Server 2012 R2, the first replication of servers is the longest but only small and quick incremental changes are necessary from that point forward.
  • Failover sandbox:  One of the best features is the ability to bring replicated servers online for testing without affecting your production environment. During testing, customers do incur a flat cost per machine for runtime. However, afterwards the failover machines are simply shutdown and the monthly cost returns to a nominal amount per replicated offline server.
  • Disaster failover: In a true emergency, an actual failover of servers are brought online and accessed through pre-defined Remote Desktop Connection. Following a disaster with reconstruction of the facility and new equipment, a VPN may be reestablished to headquarters and the cloud environment replicated on-site.
 Many customers struggle with simply purchasing Azure, much less documenting and retaining a staff trained in the multi-disciplines depicted above. This post has been provided as a business advisory to arm prospective customers with questions to ask and problems to avoid when considering disaster recovery. We welcome any comments below and please contact us for further information.

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Leave a Reply

Discover more from Matrixforce Pulse

Subscribe now to keep reading and get access to the full archive.

Continue reading