ASR Failover replicated VM stuck in target region

HIMANSHU MITTAL 0

Hi team,
My primary region is eastus and secondry is westus.
I was doing test failover and then i reverted it back to East ( source ) region. Whole infrastructure is running fine. Although I'm facing an issue regarding the replicated VM. This VM is in target region westus (ideally it should be in source region eastus ) and also its not deleted from VM's list. It should have been deleted itself after failover commit. This VM is pointing to west region in our recovery plan. So when I'm trying to re-protect it ( Ideally it should be from east to west ) it is trying to re-protect it into west region. Can you guys give any insights here? One of the article suggest -> disable replication -> delete the VM on west region -> enable replication from source ( eastus ).

SadiqhAhmed-MSFT 46,291 Reputation points Microsoft Employee

2024-10-29T16:47:29.85+00:00
@HIMANSHU MITTAL Thank you for contacting us!

If the VM in the West region is not automatically deleted after the failover commit, you may need to manually delete it.

Check recovery plan associated with the VM to ensure it’s configured correctly. You might need to remove or update the VM reference pointing to the West region.

In the Azure portal, go to the Recovery Services vault where your replicated VMs are listed. Locate the VM that was previously replicated and stop the replication. This will effectively remove it from the West region.

Once the VM is deleted and replication is stopped, you can set up replication again:

Select the VM from the East region that you want to protect.

Go to Site Recovery and initiate the replication process to the West region again.

Make sure you choose the correct target region during this process.

After re-protecting the VM, verify that it appears in the VM list and that it is correctly configured to replicate from East to West.

Check the status of the replication in the Azure portal to ensure everything is functioning properly.

Doc reference: https://learn.microsoft.com/en-us/azure/site-recovery/azure-to-azure-tutorial-failback#reprotect-vms

Hope this helps. Please reply if you have any questions or need further assistance.
HIMANSHU MITTAL 0 Reputation points

2024-10-29T17:11:43.9233333+00:00

Hi @SadiqhAhmed-MSFT
Thanks for the reply. I'll follow these steps. There is one more question
If i re-enable replication, while the synchronized period my original VM will be stopped?
If yes how much time approximately does it take for the synchronization?
Also if there is already a cache storage for the replication that i'll reuse will it make the synchronization faster?

Thanks
SadiqhAhmed-MSFT 46,291 Reputation points Microsoft Employee

2024-10-31T16:02:19.03+00:00

@HIMANSHU MITTAL When you re-enable replication for a VM, the initial replication process will start, which involves copying the data from the source VM to the target VM. During this process, the source VM will continue to run normally, and there will be no impact on its availability.

Once the initial replication is complete, the VM will enter the synchronized state, where changes made to the source VM are replicated to the target VM in near real-time. During this period, there will be no impact on the source VM's availability, and it will continue to run normally.

The time it takes for the initial replication to complete depends on various factors, such as the size of the VM, the amount of data to be replicated, and the network bandwidth between the source and target regions. Typically, the initial replication can take several hours to complete, but this can vary depending on the specific scenario.

If there is already a cache storage for the replication that you'll reuse, it can make the synchronization faster. The cache storage is used to store the changes made to the source VM before they are replicated to the target VM. By reusing the cache storage, you can avoid copying the data again, which can save time and reduce the network bandwidth usage.

However, it's important to note that the cache storage has a limited capacity, and if it's full, the replication process can be impacted. Therefore, you should ensure that the cache storage has enough capacity to store the changes made to the source VM during the synchronization period.
HIMANSHU MITTAL 0 Reputation points

2024-11-05T14:17:40.3466667+00:00

Hi @SadiqhAhmed-MSFT
Here is the issue i'm facing right now.
I did failover from east to west. After that i committed the changes and re-protected the VM. Now my replicated item is in west. Its trying to synchronizing the changes. First it took more then 12 hour for synchronizing changes. Now its gone into configuring the replica state from more then 24 hours. I'm not able to start my VM in east region because of this. On the top of that there is no progress bar or something that can indicate how long it will take to configure the replica.

I want to do rollback ( failover from west to east ) but that is also not possible because for that replicated item should be in protected state.

I don't think this is a good approach to hold you VM on stop state for such a long time. Is there anything I'm doing wrong here?
SadiqhAhmed-MSFT 46,291 Reputation points Microsoft Employee

2024-11-05T16:45:18.3566667+00:00

@HIMANSHU MITTAL The long synchronization time you're observing (more than 12 hours and now stuck at 24 hours) suggests that the replication process is encountering an issue. This could be due to network latency, insufficient resources, or a problem in the replication process itself. Check if there are any storage or network issues in the West region that could be affecting the sync.

If the VM is stuck in the "Configuring Replica State" phase, this could indicate that there’s a delay or issue in how the replication is being handled or committed.

Try restarting the Azure Site Recovery service. This can help resolve any issues with the service.

Note that failing over the VM from the target region to the source region will result in data loss, as any changes made to the VM in the target region will not be replicated back to the source region. Therefore, you should ensure that you have a backup of the VM and its associated resources before failing over the VM.

Also, before failing over the VM, ensure that the recovery plan is configured correctly and the VM is pointing to the correct region.

Share via

ASR Failover replicated VM stuck in target region

Your answer