Blob storage account Disaster Recovery: customer initiated Blob Storage Account Failover time optmization

Question

Hi, we are doing DR failover testing on our blob storage account in RA-GZRS (e.g. westus2/west central us).

We were wondering if is there any way to optimize time needed for a "Customer managed blob Storage Account Failover" completed, excluding time to renable geo-redundant setup, in other words how to reduce blob storage account read/write access outage time in disaster recovery.

In the related microsoft learn reference articles it looks like not reported details about that, just “The time it takes to failover after initiation can vary though typically less than one hour.”

It would be interesting dip in details about how much time takes on average an account failover updates the secondary endpoint to become the primary endpoint for our storage account (e.g. minimum time required to converting to locally redundant storage (LRS) in the new primary region, if depending on blob container data files number and size, on region, ... ) to make possible predictions and/or improve the time.

Is there a reference table to evaluate possible timing cases depending on blob container data files number and size ?

Answer 1

Hello COLASANTO, FRANCESCA,

Thank you for posting your query here!

When a failover is initiated, the secondary endpoint becomes the primary endpoint for your storage account. After the failover is complete, the original secondary region becomes the new primary, and all storage service endpoints for blobs, tables, queues, and files are redirected to the new primary region. The storage account continues to be replicated three times locally within the original secondary region (the new primary). https://learn.microsoft.com/en-us/azure/storage/common/storage-failover-customer-managed-unplanned?tabs=grs-ra-grs

The time it takes for a “Customer managed blob Storage Account Failover” can indeed vary, and it’s typically less than one hour. However, the exact time can depend on several factors.

Data Size and Number of Blobs: The number and size of blobs in your storage account can impact the time it takes to failover. However, there isn’t a specific reference table available that provides timing cases depending on blob container data files number and size. The process of failover involves updating the DNS entries for your storage account service endpoints such that the endpoints for the secondary region become the new primary endpoints for your storage account. This process is not directly dependent on the number or size of blobs but more on the system’s ability to update the DNS entries.

Redundancy Option: The redundancy option you choose for your account (e.g., GRS, GZRS, RA-GZRS) can also impact failover times. For instance, with RA-GZRS, applications configured for read access to the secondary region and designed for high availability can continue to read from the secondary endpoint if there’s an outage in the primary region.

Conversion to LRS: After a failover, the storage account is configured as Locally Redundant Storage (LRS) in the new primary region. To optimize the time needed for a failover, you might consider designing your applications for high availability, and planning for storage account failover. Also, monitoring the Last Sync Time property can provide an estimate of the extent of data loss that you will experience after the failover is completed. https://learn.microsoft.com/en-us/azure/storage/common/storage-disaster-recovery-guidance

Do let us know if you have any further queries. I’m happy to assist you further.

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.