Azure Site Recovery now protects physical servers and VMware too, without migrating to the cloud

Many organisations still run equipment that never made the move to the cloud. A physical server in a server room driving one specific package, a VMware cluster that has been depreciated over the past years, or a system that, for contractual or technical reasons, simply has to stay on site. For those machines, a properly worked out disaster recovery plan used to be cumbersome: setting up a separate DR site, configuring expensive replication software, or starting a migration project nobody really wanted.

On 14 October, Microsoft announced that Azure Site Recovery is generally available for Windows machines connected through Azure Arc, covering both VMware virtual machines and physical servers. That is more than a technical footnote. It means equipment that stays on premises can still get a cloud-based failover plan, through the same management layer you likely already use for other systems.

What exactly changed on 14 October

Azure Site Recovery has existed for years and replicates virtual machines to Azure, so that a failure at the original location lets you fail over to a copy in the cloud. Until recently, support for machines outside Azure was limited and usually handled through a separate configuration path. The new release ties that protection directly to Azure Arc: once a physical server or VMware machine is registered as an Arc resource, you can add Site Recovery protection to it the same way you would for an Azure VM.

The result is a shorter line between management and recovery. You see the machine in the same Azure portal where you already track it for inventory, patch status and policy, and you can attach a replication plan from that same screen.

The role of Azure Arc in this story

Azure Arc projects resources running outside Azure, on premises, with another provider, or in another data centre, as a managed object inside Azure. You get inventory, policy and monitoring without the machine itself moving anywhere. Many organisations already use Arc for governance over their physical server estate, often without a concrete recovery plan behind it yet.

With this update, that same Arc connection becomes the basis for disaster recovery too. There is no second agent or separate platform to learn: the machine you already manage through Arc can, with a few extra steps, also be replicated to an Azure region of your choice. For IT teams already using Arc for management, the step to recovery is therefore a small one.

Which organisations this matters to

This mainly affects organisations that deliberately did not move everything to the cloud. Think of a branch office with a local file server that has to stay on site for latency reasons, a production environment with equipment tied to specific hardware, or a sector where regulation requires certain data to physically stay in the Netherlands on dedicated infrastructure. Organisations that recently invested in physical servers and cannot yet justify a full cloud migration financially benefit here too.

For this group, disaster recovery was often the item that kept being postponed. Setting up a second physical site on your own costs time and money out of proportion to the risk, so the topic kept getting pushed to next year. A cloud-based recovery point that connects to infrastructure you already manage through Arc lowers that threshold considerably.

What implementation looks like in practice

The steps largely follow the existing Arc path. First you install the Arc agent on the physical server or VMware machine so it shows up as a managed resource in Azure. Then you enable Site Recovery for that resource and choose a target region in Azure. Next you build a recovery plan: which machines belong together, in which order they need to start up, and which network configuration applies in the failover environment.

Costs are generally lower than a physical second site, because during normal operation you mainly pay for storage of the replicated data, and only pay for full compute during an actual or tested failover. That last point matters: a recovery plan that has never been tested is, in practice, not a recovery plan. Schedule a failover test once or twice a year, outside office hours, and treat it with the same seriousness as a real outage.

What this does not solve

Initial replication of a physical server with a lot of data takes time and bandwidth, especially if the internet connection at that location was never sized for this purpose. Account for that in planning, and talk to your internet provider if larger volumes of data are involved. Support also currently applies to Windows machines; for on-premises Linux systems, a different approach is still needed.

Site Recovery is also not a substitute for a solid backup strategy. It protects against a location going down, not against an accidental deletion or ransomware that has already settled into the environment before you fail over. The two should work together: backup for restoring data at a specific point in time, Site Recovery for keeping the service running when the location itself fails.

For organisations already using Azure Arc to manage their physical or VMware environment, this is a logical next step: closing the last gap in the recovery plan, without needing a migration project to do it. Want to know whether your server environment qualifies, or need help setting up and testing a recovery plan? Zarioh is happy to think through a cloud strategy that fits the infrastructure you already have.