LRS, ZRS, GRS, GZRS: which copy of your data 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.
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 | Survives a dead drive/rack | Survives a lost datacenter | Survives a lost region | Durability (per year) |
|---|---|---|---|---|
| LRS | Yes | No | No | 11 nines |
| ZRS | Yes | Yes | No | 12 nines |
| GRS | Yes | No* | Yes (after failover) | 16 nines |
| GZRS | Yes | Yes | Yes (after failover) | 16 nines |
* GRS uses LRS in the primary region, so a full primary-datacenter loss still needs the secondary region to take over.
The catch nobody mentions until it bites: the secondary is not readable
This is the single most misunderstood point, and a favourite interview trap. With plain GRS or GZRS, that second-region copy is a disaster-recovery copy, not a live read replica. You cannot read from it while the primary is healthy — and even during a primary outage you cannot read from it until a failover promotes the secondary to primary.
If you want to actually read from the secondary region — say, to serve traffic from the closest copy or to keep reading through an outage — you must enable the read-access variants: RA-GRS or RA-GZRS. They expose a second read-only endpoint with a -secondary suffix on the account name. Without the RA-, that copy is a fire extinguisher behind glass: there for the disaster, not for daily use.
The copy to the secondary region is asynchronous, so the secondary trails the primary by a little. If the primary is destroyed before the last writes replicate, those writes can be lost. That gap is your recovery point objective (RPO) — worth naming out loud, because "geo-redundant" can otherwise sound like "zero data loss," which it is not.
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, and point-in-time restore. 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.