Azure storage redundancy: LRS, ZRS, GRS, GZRS — which copy survives what
Azure keeps multiple copies of everything in a storage account — the only question is where. One letter of the redundancy setting is the difference between surviving a dead drive and surviving a dead region. Here is how to choose without overpaying for a disaster you will never have.
New to cloud? CAMPUX is a free, build-first course. Start here →
Azure LRS keeps three copies of your data in one datacenter; ZRS spreads three copies across three availability zones in one region; GRS and GZRS add an asynchronous copy in a paired secondary region; the RA- variants add read access to that secondary. Redundancy protects against hardware, zone, or region loss — not against deletion. That is backup, a different thing.
Every Azure storage account replicates your data automatically; you never store a single unguarded copy. What you actually choose when you pick a redundancy option is the blast radius you want to survive — a failed disk, a flooded datacenter, or an entire region falling off the map. The four options read like alphabet soup, but they are just two questions stacked on top of each other: how far apart are the copies in my primary region, and do I also keep copies in a second region hundreds of miles away?
The two questions, answered
Question one — spread within the primary region:
- LRS (locally redundant storage) keeps your copies inside a single physical datacenter. It protects against the everyday failure — a dead drive, a bad server, a failed rack. It does not protect against that datacenter itself going down. Cheapest option; Microsoft rates it at at least eleven nines (99.999999999%) of durability over a year.
- ZRS (zone-redundant storage) writes each copy synchronously across three or more availability zones in the region — separate buildings with independent power, cooling, and networking. Lose a whole datacenter and you keep reading and writing. Rated at at least twelve nines.
Question two — do you also copy to a second region? Both of the above have a geo- sibling:
- GRS (geo-redundant storage) = LRS in the primary region, plus an asynchronous copy to a paired secondary region hundreds of miles away (where it is stored with LRS again).
- GZRS (geo-zone-redundant storage) = ZRS in the primary region, plus that same asynchronous copy to the secondary. The best of both: zone resilience at home and regional protection abroad. Both geo options are rated at at least sixteen nines of durability.
| Option | Copies | Scope of those copies | Read from secondary | Durability (per year) | Typical use |
|---|---|---|---|---|---|
| LRS | 3 | One datacenter, one region | — | 11 nines | Dev/test, logs, anything regenerable |
| ZRS | 3 | Three zones in the primary region | — | 12 nines | Production that must survive a lost datacenter, in-region |
| GRS | 6 | Primary datacenter + paired region | No (failover only) | 16 nines | Regional DR when in-region zone cost is not justified |
| RA-GRS | 6 | Primary datacenter + paired region | Yes (read-only endpoint) | 16 nines | Regional DR plus live reads from the secondary |
| GZRS | 6 | Three zones in primary + paired region | No (failover only) | 16 nines | Crown-jewel data needing zone and region resilience |
| RA-GZRS | 6 | Three zones in primary + paired region | Yes (read-only endpoint) | 16 nines | Maximum resilience plus live reads from the secondary |
GRS and RA-GRS use LRS in the primary region, so a full primary-datacenter loss still leans on the secondary region; GZRS and RA-GZRS spread the primary copies across zones first. Durability figures are Microsoft's published design targets, as of 2026.
Azure LRS, precisely
LRS (locally redundant storage) writes your data three times, synchronously, within a single physical datacenter in one region. Every write is acknowledged only after all three copies land, so the copies never drift apart. What it survives: a dead drive, a failed server, a broken rack — the everyday hardware attrition that is genuinely common. What it does not survive: the datacenter itself. Fire, flood, a facility-wide power event — all three copies are in the same building, and they go down together. Microsoft's published design target is at least eleven nines of durability over a year (99.999999999%), as of 2026.
When LRS is the right answer, and it often is: data you can re-create. Dev and test environments, build artifacts, rebuildable logs, staging copies, cache-style blobs, anything a pipeline can regenerate. It is the cheapest tier, and paying for more redundancy on regenerable data is money spent on a disaster that costs you nothing. It is also the forced answer in regions without availability zones, and the usual choice where data-residency rules pin everything to one place.
Azure ZRS, precisely
ZRS (zone-redundant storage) also keeps three copies, but each one lives in a different availability zone — physically separate facilities in the same region with independent power, cooling, and networking. Writes are still synchronous: Azure confirms the write only after all zones have it, so there is no replication lag and no data-loss window inside the region. Lose an entire datacenter, or an entire zone, and the account keeps reading and writing as if nothing happened — no failover, no DNS change, no intervention.
That makes ZRS the modern default for production data in regions that support zones: it removes the single-building failure mode for a modest price step over LRS. Its limit is the region boundary. A full regional outage — rare, but not fictional — takes all three zones with it, and ZRS has no copy anywhere else. Microsoft's published design target is at least twelve nines of durability, as of 2026.
Azure GRS and RA-GRS, precisely
GRS (geo-redundant storage) is LRS at home plus a second region. Your data sits as three synchronous copies in one datacenter in the primary region, and Azure asynchronously replicates it to the paired secondary region hundreds of miles away, where it is stored as three more copies — six in total. The geo copy is what survives a whole-region disaster. Microsoft's published design target for the geo tiers is at least sixteen nines, as of 2026.
Two catches, both worth knowing cold. First, the copy to the secondary is asynchronous, so the secondary trails the primary by a little. If the primary region is destroyed before the last writes replicate, those writes are gone. That gap is your recovery point objective (RPO) — "geo-redundant" is not "zero data loss."
Second, the secondary is not readable with plain GRS. That second-region copy is a disaster-recovery target, not a live replica: you cannot read from it while the primary is healthy, and you cannot read from it during an outage either, until a failover promotes it to primary. Failover comes in two flavours: customer-initiated (you decide the primary is down long enough and trigger it yourself — the account's secondary becomes the new primary, and it drops to LRS until you re-enable geo-replication) and Microsoft-declared (in a catastrophic regional loss, Microsoft may fail accounts over — but you should not plan around waiting for that).
RA-GRS is GRS with the RA- prefix: read access to the secondary. It exposes a live read-only endpoint at a -secondary suffix on the account name, so an application can keep reading through a primary outage or serve reads from the closer copy — no failover needed for reads. The honest limitation: because replication is asynchronous, secondary reads are eventually consistent. What you read there can be seconds or minutes behind the primary, and your application has to be able to tolerate that. Writes still go to the primary only.
"We use GRS, so we can read from the secondary if the primary goes down" — no, you cannot, not without a failover. Without the RA-, that copy is a fire extinguisher behind glass: there for the disaster, not for daily use. This distinction shows up in AZ-104 questions and real incident reviews alike.
GZRS and RA-GZRS: ZRS plus a second region
GZRS (geo-zone-redundant storage) is the combination tier: three copies written synchronously across three availability zones in your primary region — the ZRS half — plus the asynchronous copy to the paired secondary region, where it lands as LRS. Zone resilience at home, a whole-region disaster copy abroad, one setting. If a datacenter or an entire zone in the primary region fails, GZRS keeps serving without any failover; only a full-region loss involves the secondary. Same sixteen-nines design target as GRS.
GRS vs GZRS comes down entirely to the primary region. Both survive losing the whole region. But GRS keeps its primary copies in a single datacenter, so a lost datacenter leaves it with no in-region resilience — recovery means failing over to the secondary, with the RPO loss that implies. GZRS spreads its primary copies across three zones, so a lost datacenter is a non-event and the secondary stays reserved for a genuine regional disaster. Put simply: GZRS also protects against a zone failure in the primary region; GRS does not. That zone protection is what the extra cost buys, and in zone-enabled regions it is usually the better geo choice.
RA-GZRS is GZRS with the same read-only secondary endpoint RA-GRS has, with the same eventually-consistent caveat. The RA- changes access, not the number of copies — durability is identical to the non-RA sibling.
Can you change redundancy on an account you already created?
Yes, and for most accounts it does not mean starting over. Azure splits the change into two different mechanisms depending on what you are changing:
- Adding or removing geo-replication or read access — LRS ↔ GRS, GRS ↔ RA-GRS — is a direct property update. Change the Redundancy setting on the storage account in the portal, or update the SKU with
Set-AzStorageAccount(PowerShell) oraz storage account update --sku(CLI). This takes effect without downtime. - Adding or removing zone-redundancy — LRS ↔ ZRS, GRS ↔ GZRS — is a conversion, not a simple property flip. You request it the same way (portal, PowerShell's
Start-AzStorageAccountMigration, or the CLI'saz storage account migration start), but Microsoft moves the data in the background rather than applying the change instantly. A conversion typically starts within 72 hours, carries no published SLA for when it finishes, and causes no data loss; most accounts see no interruption, though hierarchical-namespace (Data Lake Storage Gen2) accounts can see a pause of under 30 seconds while the switch completes.
Two changes that add zone redundancy and geo-redundancy at once — LRS straight to GZRS, for instance — are not a single step. Add zone-redundancy first (LRS → ZRS), wait for that conversion to finish, then add geo-redundancy (ZRS → GZRS) as a second, ordinary property update. Microsoft also asks for a 72-hour wait after a conversion before you request another one on the same account.
A conversion isn't available in every case — premium page-blob accounts, an account holding blobs in the archive tier, or a move to a different region all fall back to a manual migration: copy the data into a new account with the target redundancy (with a tool like AzCopy) and cut over. That path does involve planned downtime, which is exactly why Microsoft treats it as the fallback rather than the default. Verify your own scenario against the redundancy-migration reference before you schedule anything, since account type and archive-tier data both change what's possible.
What each tier costs, structurally
Exact prices move by region, capacity, and access tier, so check the official Azure Storage pricing page rather than any blog's numbers. The structure, though, is stable: LRS < ZRS < GRS < GZRS per gigabyte, with the RA- variants a step above their plain siblings. Geo tiers also bill for the replication bandwidth between regions, and a failover means your traffic egresses from the new primary. The practical reading: redundancy is one of the few storage settings where over-provisioning silently doubles a bill, because every gigabyte pays the multiplier forever.
Durability protects you from Azure losing your data. It does nothing to protect you from you deleting it.
Redundancy is not backup
Sixteen nines sounds like it should let you sleep through anything, so say the quiet part clearly: all replicas reflect the same current state. Delete a blob, or overwrite it with garbage, and every copy — local, zonal, and geo — faithfully deletes or corrupts in lockstep. Redundancy defends against hardware and infrastructure failure. It is not a defence against a fat-fingered delete, a buggy job, or ransomware. For those you need actual data-protection features: soft delete, blob versioning, point-in-time restore, or Azure Backup proper — the difference between the recovery tools is its own topic, covered in Azure Backup vs Site Recovery. If you want to feel the distinction in your hands, the backup-and-restore-a-file-share lab walks through deleting data on a redundant account and getting it back — redundancy does not save you there, the backup does. Redundancy and backup answer different questions; a good engineer never confuses them.
So which do you pick?
- LRS — for data you can regenerate: dev and test, temporary files, logs you can rebuild, staging copies. Do not pay for more.
- ZRS — the sensible default for production data that must stay available if a datacenter drops, but is governed to stay within one region.
- GZRS / RA-GZRS — for the crown-jewel data where a whole-region outage must not mean data loss, and (for RA-) where you want to keep reading through it. This is the "maximum" choice, at the highest price.
- GRS / RA-GRS — regional protection when the extra cost of ZRS at home is not justified.
Match the option to the blast radius the data actually warrants, remember that geo-copies are for disasters rather than daily reads, and keep backup as a separate line of defence. Do that and you will never again pay region-scale prices for a spreadsheet you could rebuild in an afternoon.
Redundancy is one of four settings you fix at account level. The others — account kind, performance tier, and access tier — are covered in storage account types and blob access tiers, and the four services the account hosts are in blob vs file vs queue vs table.
Questions people also ask
What is the difference between LRS, ZRS, GRS, and GZRS?
LRS keeps three copies of your data in one datacenter. ZRS keeps three copies spread across three availability zones in one region. GRS takes LRS in the primary region and adds an asynchronous copy to a paired secondary region. GZRS takes ZRS and adds that same secondary copy. Each step widens the failure you can survive: a drive, a datacenter, a region.
What is Azure GRS?
GRS (geo-redundant storage) stores three copies of your data in a single datacenter in the primary region, then asynchronously replicates it to a paired secondary region hundreds of miles away, where it is stored as three more copies — six in total. The secondary is a disaster-recovery target: you cannot read from it until a failover promotes it to primary.
What is Azure ZRS?
ZRS (zone-redundant storage) writes each copy of your data synchronously across three availability zones in one region — separate facilities with independent power, cooling, and networking. A whole datacenter can fail and the account keeps reading and writing. It is the usual production default in regions that support zones, but a full regional outage still takes it down.
What is RA-GRS?
RA-GRS is GRS with read access to the secondary region. Plain GRS keeps the second-region copy sealed until a failover; RA-GRS exposes a live read-only endpoint at a -secondary suffix on the account name, so an application can read through a primary outage. Because geo-replication is asynchronous, reads from the secondary can lag the primary — they are eventually consistent, not guaranteed current.
Is GZRS better than GRS?
For resilience, yes. Both survive a lost region, but GZRS also survives a lost zone or datacenter in the primary region without any failover, because its primary copies are spread across three availability zones while GRS keeps them in one datacenter. GRS is cheaper. If the data justifies geo-redundancy at all, GZRS is usually worth the difference in zone-enabled regions.
Does storage redundancy protect against accidental deletion?
No. Every replica reflects the same current state, so a deletion or corruption is copied faithfully to all of them — local, zonal, and geo. Redundancy protects against hardware, zone, and region failure. For deletion, corruption, or ransomware you need backup features: soft delete, blob versioning, point-in-time restore, or Azure Backup.
Can you change the redundancy of an existing storage account?
Yes. Adding or removing geo-replication or read access (LRS to GRS, GRS to RA-GRS) is a direct property update with no downtime. Adding or removing zone-redundancy (LRS to ZRS, GRS to GZRS) is a conversion that Microsoft runs in the background, usually starting within 72 hours, with no data loss. Some accounts — premium page blobs, archive-tier data, or a move to another region — require a manual migration instead, which does involve planned downtime.