Why you should — and shouldn’t — harness Azure for disaster recovery

Using Azure for your disaster recovery can offer your business real benefits – eradicating costly DR sites, only paying for compute resource when you spin up virtual machines in Azure (usually during recovery or for testing), unlimited scalability of your DR in line with your production system, and the reliability and security that comes with Microsoft. Azure’s single most powerful feature is that it can help companies to reduce the cost of their DR, whilst maintaining maximum performance (think fast recovery times, near-zero data loss). A large proportion of the cost that comes with DR is data storage cost and the cost associated with having compute resource on standby that is rarely used – just in case the time comes that you have a business-critical IT failure. You need to have systems available on standby for when the inevitable happens, but the cost of the hardware, software and maintaining a DR system in line with your production system means that dedicated DR sites are rarely viable for companies. But imagine if you can pay for the compute resource only when you need it, stripping away the cost of hardware and software as a capex and turning it into a pay-as-you-use opex model. This then enables you to balance the risk with the cost – which is ideal for most companies exploring disaster recovery – you only want to pay for it when you need it right?

Well this is what Azure is allowing companies to do – pay for the compute resource when they failover and spin up VMs. In effect, Azure is a large syndication programme that enables companies to share the compute resource on an industrial scale all over the world.

Sounds great right? But what are the downsides to Azure that the marketing messages fail to tell you about? Well, in our experience – being an Azure DR service provider – it’s the challenge of making it work for you. Azure is not to be embraced lightly, and it requires a lot of though, knowledge and experience to make it work effectively.

Here’s why:

1. Using Azure for your DR platform means taking your production system and making it compatible with Azure

The work involved here shouldn’t be underestimated. It’s likely to be difficult and lengthy (just take a look at some of the very long guides on this), and until you embark on the process you won’t be able to plan how long it will take. Even the guides won’t be a foolproof tool to enabling successful compatability; the configuration of servers, applications and networking will be unique to you so in a sense you’ll be going at it alone. Any Azure accounts that you have already may have implications on your DR project, and there may be differences in migration pathways depending on which data centre you opt for (remember – with Azure there are endless global options here). In a nutshell, be prepare for a project that will have you delving into the unknown.

2. In order to get onto Azure you’ll need to audit your production infrastructure and identify all actions and changes required for Azure compatibility

All Azure adjustments, file adjustments and Azure set-up needs to be carried out – in addition to set-up of the DR replication technology that you choose to replicate your production systems to Azure. This takes knowledge of various different technologies, and how they work together, not to mention the time factor. It’s likely to take longer than you had planned for.

3. As with most non-fixed prices, cost will start to creep up

For example, you’re likely to need to invest in Microsoft System Center Virtual Machine Manager (SCVMM) at the outset. Then, every time you run a DR test you’ll need to create a VM in Azure prior to initiating a failover, which starts to cost money. The more you test, the better your resilience, but the higher the cost. And the longer you stay in Azure, the more cost you will incur. Zerto 5.5 continuous replication technology offers the benefit of orchestrated failback, which means getting out of Azure is simple. However with other replication technologies you may find that you end up in Azure for longer than required, and of course you’ll get charged for as long as you are using Azure. Finally, it can be easy for storage costs to soar with Azure if not kept under tight control. And how do you balance cost with risk?

If you decide that Azure is worth pursuing as a disaster recovery solution then there are further functionality considerations and decisions to make. Which replication technology should you opt for? What RPOs and RTOs are achievable and what happens when an outage occurs with Azure?

When it comes to replication technologies it is important to understand their features and limitations. Azure Site Recovery (ASR) is specific to Azure, as opposed to others that will work with Amazon Web Services (AWS) as well as other private cloud environments. ASR works with Hyper-V, VMWare and physical servers, enabling it to replicate hybrid environments as opposed to just virtualised ones.

ASR can, however, be difficult from a user perspective. For example, in complex environments, automation runbooks are available for configuration tasks such as opening specific ports for remote desktop access or for Web access, but these require user experience of PowerShell. The fact that configuration is required means that ASR isn’t capable of immediate failover, nor is failover fully orchestrated.

ASR can also add complications to your production environment. For example, it is known to impact VMWare performance. Failback with ASR involves a migration project which can prevent businesses from failover thereby extending recovery times. When it comes down to it, DR testing with ASR can be difficult and therefore often not carried out. This can lead to many businesses using ASR without adequate protection against downtime – certainly not reaping the benefits of Azure.

Zerto 5.5 enables not only fully orchestrated failover, but now also fully orchestrates failback, meaning that your DR solution will be available much faster, and the costs are kept low as companies can very easily revert back to their productions systems . This allows businesses to utilize their DR systems much more freely; without having to consider the additional resource requirements of invoking their DR. A DR solution can now act as a second set of production systems or as a highly efficient testing platform. It also promotes faster recovery of business-critical systems. Zerto however, cannot replicate physical servers, so an alternative method of replication must be sought for physical servers in those companies who operate hybrid environments.

For the time being it would seem that larger companies are exploring the benefits of Azure due to its infinite capacity and cost savings (these can also be harnessed by smaller companies). As a cautionary note – obtaining help from a DR provider that knows how to get your DR Azure-ready could be a worthwhile investment in order to avoid the stressful and lengthy implementation experience of going it alone.