Active active sync

For an on-premises physical server → Azure active DR scenario, Azure Site Recovery (ASR) maintains a continuously replicated copy of the physical server in Azure. The physical server remains the production system in the on-premises datacenter. ASR initially replicates the server's disks to Azure and then continuously replicates subsequent disk changes. For a physical server, the ASR Mobility service is installed on the source server to enable this replication.

In normal operation, users continue to access the on-premises server. The Azure side is the recovery environment rather than a second active copy of the server. ASR maintains the replicated data and the information required to create the Azure VM when recovery is needed. You also configure the Azure target environment, including the target region, resource group, virtual network, storage, and other recovery settings.

If the on-premises server or datacenter fails, you initiate an ASR failover. ASR uses the replicated disks to create/start an Azure VM representing the physical server. The workload then runs in Azure, and users are redirected to the Azure environment through the appropriate network connectivity, DNS, routing, or application configuration. The amount of data potentially lost depends on the replication state at the time of the failure, so ASR provides recovery-point objectives rather than guaranteeing zero data loss.

You can also perform a test failover before an actual disaster. This creates a test instance in Azure, normally using an isolated network, so you can verify that the server boots and the application works without affecting the production server or normal replication.

When the on-premises environment is available again, you don't simply turn the physical server back on and switch users to it. You first establish replication back toward the on-premises environment, synchronize the changes that occurred while the workload was running in Azure, and then perform a planned failover back to the on-premises server. This gives you a controlled failover → operate in Azure → failback process.

There is also a separate migration use case. If your ultimate objective is to move the physical server permanently to Azure, ASR can be used to replicate the physical server, test the Azure VM, and then perform a planned migration. In that case, the Azure VM becomes the permanent production system rather than remaining a DR target.

So the basic architecture is:

Normal operation: On-premises physical server → production Azure → continuously replicated recovery copy

Datacenter failure: On-premises server fails → ASR failover → Azure VM becomes production

Datacenter restored: Azure VM → reverse replication → on-premises → planned failback → on-premises becomes production

The key point is that “active DR” here does not normally mean two simultaneously active servers serving the same workload. It means Azure is continuously maintained as a current recovery environment that can be activated when the primary on-premises server becomes unavailable.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin