LouisT engages the community on how to migrate an Azure Storage Account from LRS to GZRS while minimizing downtime and ensuring seamless failover, raising important questions on migration impact and infrastructure options.

Understanding Storage Account Replication Downtime

Author: LouisT

Scenario

  • Azure Storage Account (used as a CDN) with ~2 GB of small, critical files
  • Currently using LRS replication in UK South
  • Requirement: Upgrade redundancy without introducing application changes or significant downtime
  • Considering migration to GZRS (Geo-Zone-Redundant Storage) for active replication to UK West
  • Needs ability to write after a failover, so RA-GZRS is not an option

Core Questions Raised

  1. Estimating Downtime for Migration
    • Microsoft documentation confirms downtime is required for manual migration (docs link), but does not specify typical timeframes. Actual downtime depends on:
    • Storage account size and object count (here: 2GB, mostly small files—should be relatively quick)
    • Azure’s back-end replication and failover mechanisms
    • Any preparation steps or safety checks Azure imposes
    • Community consensus: The migration window is usually short for small datasets, but scheduling several hours is prudent to accommodate unpredictability or rollback. Azure Support may provide more precise estimates with a support request, especially for business-critical workloads.
  2. Effect of Migration Mechanism (Portal vs. IaC)
    • Whether migration is triggered via the Azure Portal, Bicep, or Terraform, the underlying process is the same—Azure performs maintenance actions behind the scenes
    • IaC may offer better auditing and repeatability, but does not avoid downtime or alter the underlying steps
    • Manual (Portal) migration offers interactive confirmation but no reduction in downtime

Additional Discovery

  • UK West currently does not support Availability Zones (regions list), limiting GZRS effectiveness for full zone redundancy
  • If true zone redundancy is needed and not available in the paired region, standard GRS (Geo-Redundant Storage) can still mitigate some risk—though automatic failover/writes to secondary remain challenging

Community Considerations

  • No transparent failover or write capabilities for GRS/RA-GZRS that would fully mimic GZRS
  • All migration types require a carefully scheduled maintenance window
  • Communication to management/customers should reflect some uncertainty; for 2GB, real downtime may be under an hour, but always add margin
  • For similar scenarios, some users reported total downtime ranging from a few minutes to 1–2 hours, but unknown factors (number of blobs, storage account config, Azure backend load) can impact this

Actionable Steps

  1. Open a Microsoft Support Ticket with your specifics for a tailored downtime estimate (recommended for business-critical workloads)
  2. Prepare: Cleanup, snapshot, or backup content before migration
  3. Schedule maintenance window with buffer (e.g., 2-3 hours)
  4. Notify users and management with possible downtime window
  5. Monitor migration progress using Azure Portal or CLI
  6. Validate storage access post-migration

References

Summary

Migrating from LRS to GZRS for Azure Storage offers stronger resilience but requires downtime regardless of whether you use the Portal or IaC. For small datasets like 2GB, downtime is likely minimal, but always plan conservatively. Since UK West lacks Availability Zones, assess whether plain GRS meets your risk requirements. Final recommendations: coordinate closely with Microsoft Support and communicate expected downtime transparently.

This post appeared first on “Microsoft Tech Community”. Read the entire article here