Hi iqbwl,
Welcome to Microsoft Q&A Platform. Thank you for posting your query here!
Ensure that the source VM (VMWare host2) can communicate with the Azure storage account. Check for any network issues that might be causing the disconnection.
When you do your failover, the replicated data already exists in the secondary and this is what is converted to LRS. When you go to convert from LRS to GRS to go back the other way, the data needs to be re-replicated which can take some time and depends on a number of factors that are called out in the doc here: The time and cost of failing over.
These factors include:
- The number and size of the objects in the storage account. Replicating many small objects can take longer than replicating fewer and larger objects.
- The available resources for background replication, such as CPU, memory, disk, and WAN capacity. Live traffic takes priority over geo replication.
- The number of snapshots per blob, if applicable.
- The data partitioning strategy, if your storage account contains tables. The replication process can't scale beyond the number of partition keys that you use.
Unplanned failover replicates a true disaster simulation where the primary region would be impacted or potentially lost, as a result, the data is the primary region is deleted and the account becomes LRS (since the geo-paired region is "unavailable"). When you re-enable GRS/RA-GRS there is a full data copy being replicated back to the previous primary region (since it is now deleted).
Planned failover would be a great option for you in the future if you have concerns with the timeline to re-enable GRS.
Hope this information helps. Let me know in the comments if you have any questions.
Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.