Forum Discussion

LouisT's avatar
LouisT
Tin Contributor
Dec 20, 2025

Understanding Storage Account replication downtime

I have a Storage account that's used as a CDN to host a  lot of generally small files which occupy about 2GB. This is a small but critical part of our application which is used heavily by our app but which has no redundancy (it currently only has LRS replication).

 

It's hosted in UK South and while Storage Accounts are very reliable, I'm concerned that if there's ever a regional outage there's nothing I'd be able to do.

The requirements therefore are:

  • Convert it from LRS to GZRS i.e. actively replicating from UK South to UK West.
  • No app changes required to detect when the primary goes down and to switch to the secondary-this needs to be transparent.
  • No or low downtime when the change is made.
  • We need to be able to write to the secondary after failover. As a software company anything that limits our ability to push code changes is not acceptable, so RA-GZRS is off the table.

 

After doing a bit of reading, I found the following warning in the docs:

If you choose to perform a manual migration, downtime is required but you have more control over the timing of the migration process.

https://learn.microsoft.com/en-us/azure/storage/common/redundancy-migration?tabs=portal#downtime-requirements

 

This is typically light on detail and leaves some critical questions unanswered:

  1. Is there any way of estimating how long the downtime will be so I can appropriately set expectations of management and customers when scheduling the maintenance window needed?
  2. It specifically mentions manual migrations i.e. making the change through the Azure Portal, would making the change through IAC e.g. Bicep or Terraform be any different?

Any input from anyone who's made any similar changes will also be appreciated.

 

Edit: I've just checked and found that UK West still doesn't have Availability Zone support, is my best option for reducing the risk of this single point of failure to set the replication to GRS?
https://learn.microsoft.com/en-us/azure/reliability/regions-list#azure-regions-list-1

Data + Storage

3 Replies

  • Jamony's avatar
    Jamony
    MCT
    Jun 26, 2026

    The "online conversion" guidance is in the storage redundancy migration article. In the portal, this is the Redundancy blade on the storage account; with CLI/PowerShell there are also migration/update paths depending on the current and target redundancy options. Whether LRS to GZRS is available directly depends on account type, region support, features such as archive tier/NFS, and current account state.

     

    For the DR requirements, there are two important distinctions:

     

    1. Converting redundancy should normally be planned separately from failover testing.

    2. Regional failover is not completely invisible. During failover, Azure updates DNS so the secondary becomes the new primary endpoint. After completion, clients can write to the new primary, but there is a temporary outage during the operation. Planned failover for GZRS/RA-GZRS is typically around an hour; unplanned failover can involve data loss because replication is asynchronous.

     

    If the application truly cannot tolerate downtime or failover windows, storage-account geo-redundancy alone is not enough. You would need an app-level multi-region design, potentially with separate storage accounts and routing logic/CDN failover.

     

    Useful docs:

    https://learn.microsoft.com/azure/storage/common/redundancy-migration

    https://learn.microsoft.com/azure/storage/common/storage-disaster-recovery-guidance

    https://learn.microsoft.com/azure/storage/common/storage-failover-customer-managed-planned

  • LouisT's avatar
    LouisT
    Tin Contributor
    Dec 23, 2025

    Thanks for the tip, can you please link me to any information around how to do an online conversion? I've not been able to find anything in the Microsoft documentation which mentions this.

  • Kidd_Ip's avatar
    Kidd_Ip
    MVP
    Dec 22, 2025

    For Azure Storage, transitioning from Locally Redundant Storage (LRS) to another redundancy option can be achieved through two approaches: online conversion or manual migration. Online conversion, when supported, allows the change to be completed without service interruption. In contrast, manual migration requires a planned downtime, though it provides greater control over the timing of the process. According to Microsoft official guidance, downtime is unavoidable for manual migrations, while certain conversion paths can be executed seamlessly. The availability of online conversion depends on both the storage account type and the target redundancy configuration. Microsoft provides detailed documentation on the redundancy models say LRS, Zone‑Redundant Storage (ZRS), Geo‑Redundant Storage (GRS), Read‑Access GRS (RA‑GRS), Geo‑Zone‑Redundant Storage (GZRS), and Read‑Access GZRS (RA‑GZRS) along with their respective trade‑offs:

     

    Change how a storage account is replicated - Azure Storage | Microsoft Learn