Why Redundancy Matters
Azure Storage redundancy determines how many copies of your data are maintained and where those copies physically live, protecting against everything from a single disk failure to a full datacenter or regional outage. Choosing a redundancy option is fundamentally a decision about your acceptable Recovery Point Objective (RPO) and durability guarantees — locally redundant options protect against hardware failure within one datacenter, while geo-redundant options protect against an entire region becoming unavailable, each Azure durability SLA reflecting the number of nines of guaranteed data durability per year.
Cricket analogy: It's like a team deciding how many backup wicketkeepers to carry on tour: one reserve covers an injury in a single match, but a squad also needs a completely separate contingency plan in case the whole venue becomes unusable due to weather.
Locally Redundant and Zone-Redundant Storage (LRS, ZRS)
Locally Redundant Storage (LRS) keeps three synchronous copies of your data within a single physical location in the primary region, protecting against server rack and drive failures but not against a datacenter-wide outage. Zone-Redundant Storage (ZRS) synchronously replicates data across three Azure availability zones within the same region — physically separate datacenters with independent power, cooling, and networking — so ZRS survives the loss of an entire datacenter while still keeping data within the same region for lower latency and no cross-region data residency concerns.
Cricket analogy: LRS is like a team keeping three backup bats in the same kit bag at one ground; ZRS is like keeping backup bats spread across three separate storage rooms at three grounds in the same city, so a fire in one room doesn't wipe out all the spares.
# Create storage accounts with different redundancy options
# LRS: three copies within a single datacenter
az storage account create --name lrsdemoacct --resource-group rg-redundancy \
--location eastus --sku Standard_LRS --kind StorageV2
# ZRS: three copies across availability zones in one region
az storage account create --name zrsdemoacct --resource-group rg-redundancy \
--location eastus --sku Standard_ZRS --kind StorageV2
# GZRS: zone redundancy in the primary region plus async geo-replication
az storage account create --name gzrsdemoacct --resource-group rg-redundancy \
--location eastus --sku Standard_GZRS --kind StorageV2
# Enable read access to the secondary region for RA-GZRS
az storage account update --name gzrsdemoacct --resource-group rg-redundancy \
--sku Standard_RAGZRSGeo-Redundant Storage (GRS, GZRS) and Read Access
Geo-Redundant Storage (GRS) asynchronously replicates your LRS data to a secondary, geographically distant Azure paired region, protecting against a full regional outage at the cost of a small replication lag (the RPO is typically under 15 minutes but not guaranteed to be zero). Geo-Zone-Redundant Storage (GZRS) combines the two, keeping zone-redundant copies in the primary region and asynchronously geo-replicating to a secondary region. Both GRS and GZRS have read-access variants — RA-GRS and RA-GZRS — that expose a separate read-only endpoint against the secondary region, letting applications read data even if the primary region is completely down.
Cricket analogy: GRS is like a board keeping the primary archive in Mumbai but asynchronously couriering a backup copy to a secondary archive in Delhi; RA-GRS is like also letting fans stream from the Delhi archive directly if the Mumbai feed ever goes dark.
You don't choose your storage account's secondary region arbitrarily — Azure geo-redundant options always replicate to a predetermined Azure paired region (for example, East US pairs with West US), chosen by Microsoft for geographic distance and coordinated maintenance/failover behavior.
Choosing the Right Option
Choosing between LRS, ZRS, GRS, GZRS, and their read-access variants is a tradeoff between cost and the level of disaster you need to survive: LRS is cheapest but only protects against hardware failure, ZRS adds datacenter-level resilience for a modest cost increase, and GRS/GZRS add regional resilience at higher cost with an asynchronous replication lag. If a full regional outage occurs, Microsoft-managed failover for GRS/GZRS accounts is not automatic in most cases — customer-initiated account failover promotes the secondary region to primary, which changes the storage account's DNS endpoints, so applications should be built to tolerate this failover process rather than assuming instant, transparent recovery.
Cricket analogy: It's like choosing your fielding formation based on the bowler and pitch conditions: a defensive ring (LRS) suits a low-risk situation, while an aggressive attacking field with slips and gully (GZRS) is worth the extra risk and cost only when the match situation truly demands it.
Geo-failover (promoting the secondary region to primary) is a customer-initiated, DNS-based operation that can take time to propagate and, for standard GRS/GZRS, may result in some very recent writes not yet replicated being lost since replication is asynchronous. Design applications to handle failover latency and potential minor data loss rather than assuming an instant, lossless switch.
- Redundancy options determine how many copies of data exist and where, shaping your durability guarantees and RPO.
- LRS keeps three copies within one datacenter, protecting against hardware failure but not datacenter-wide outages.
- ZRS synchronously replicates across three availability zones in a region, surviving a full datacenter loss.
- GRS asynchronously replicates LRS data to a paired secondary region, protecting against regional outages.
- GZRS combines zone redundancy in the primary region with geo-replication to a secondary region.
- RA-GRS and RA-GZRS add a read-only endpoint against the secondary region for read access during outages.
- Geo-failover is typically customer-initiated, DNS-based, and can involve minor data loss due to asynchronous replication.
Practice what you learned
1. What does Locally Redundant Storage (LRS) protect against?
2. What distinguishes Zone-Redundant Storage (ZRS) from LRS?
3. What does RA-GRS add on top of standard GRS?
4. How is the secondary region for GRS/GZRS typically determined?
5. What is a risk associated with geo-failover from a primary to secondary region?
Was this page helpful?
You May Also Like
Azure Storage Account Types
A guide to choosing between general-purpose and premium Azure storage account kinds, and how performance and redundancy tiers interact.
Azure Blob Storage
Azure's massively scalable object storage service for unstructured data, covering blob types, access tiers, and security controls.
Azure Disks Explained
How Azure Managed Disks work, including performance tiers, OS/data/temporary disk roles, caching, and snapshotting.