For Azure users, the Site Recovery DRaaS tool provides reliable and accessible disaster recovery. Testing and good management are critical to get the most out of the service.
Azure Site Recovery is an ever-evolving disaster recovery tool. Rather than add a new third-party tool to a disaster recovery strategy, Azure customers can use the built-in service to protect and restore native Azure workloads.
Site Recovery, Azure's disaster recovery as a service (DRaaS) offering, can fail into cloud for both VMware and Hyper-V on-premises environments.
Depending on an organization's requirements, Azure DRaaS makes good quality DR within reach without the added need for new hardware and infrastructure. The advantages of Azure DRaaS go beyond reducing hardware costs, but there are some common issues to watch.
Azure DRaaS best practices
As a DRaaS option, Site Recovery can help organizations cover business-critical applications in the event of a disaster, between different Azure regions if needed.
By default, Azure DRaaS keeps 24 hours of history with multiple checkpoints. It is possible to extend the duration up to 72 hours. However, the cost of doing this can be prohibitive. Not only is there a cost per snapshot, but there is also a cost per disk. If the VM is busy in terms of disk I/O it can become very expensive very quickly.
Azure is an effective tool, but it still requires management. DR teams must periodically test to ensure it works as expected and pay attention to any warnings or errors it generates.
Azure can do both backup and DR, but understanding the different associated requirements is critical to getting the most out of Azure DRaaS as a DR tool. A good DR tool focuses on rapid recovery, business continuity and availability. Organizations use data backup tools if they need a backup copy when something fails, alongside long-term availability of historic data.
Azure is not inexpensive, but DR admins can avoid added costs by separating it from a general backup plan. Every added VM has a cost. Admins can avoid this when they follow DR best practices; tier apps and ensure that the critical ones have the appropriate recovery measures.
Common Azure issues
Azure DRaaS is not infallible, so there are some common roadblocks users must watch out for.
One common issue is using fixed IP addresses in Azure. In a properly configured Azure environment, everything external should preferably be done by DNS, not directly by assigned IP.
Failing over to a secondary site may change the IP address in use. The organization should configure best practices so that in the event of a failover the business can update the DNS within a few minutes of the interruption striking. At the same time, if new IPs are allocated at all, HTTPS certificates will no longer work until renewal.
The best way to know it works is to test it, so ensure that DR teams are aware of this potential issue.
Proper testing also reduces the chance of firewall issues at the worst possible point in time. While connectivity within Azure may work as expected, dependencies such as VPN links and third-party communications may be affected when a disaster hits. These are the types of nontechnical issues an organization can experience when it does not properly test procedures and tools.
A somewhat common issue is the assumption that everything just works. Azure is an effective tool, but it still requires management. DR teams must periodically test to ensure it works as expected and pay attention to any warnings or errors it generates. The last thing any systems administrator wants is for a real crisis to occur with the DR capabilities unavailable.
Don't miss out on everything Azure is capable of. As Microsoft continues to add new features and functionality, it pays for users to stay ahead of these changes and get the most out of Azure disaster recovery.
