Storage redundancy & replication
What it is
Azure Storage replication (redundancy) copies your data multiple times so it survives hardware failure, datacenter loss, or region-wide disasters. It is chosen per storage account and cannot be changed to a higher tier after creation (can be upgraded, not downgraded).
Why it exists
Durability (no data loss) and availability (data stays reachable) are the core promise of cloud storage. Replication determines your RPO/RTO in a disaster and your cost.
The redundancy ladder (memorize!)
| Strategy | Copies | Where | Survives |
|---|---|---|---|
| LRS | 3 | 1 datacenter | drive/rack/node failure only |
| ZRS | 3 | 3 availability zones, same region | entire datacenter loss |
| GRS | 3 + 3 | primary region (LRS) + async copy to secondary region | region-wide disaster (RPO ~15 min) |
| GZRS | 3 + 3 | primary across 3 AZs (ZRS) + async secondary region | both AZ loss AND regional disaster |
- RA-GRS / RA-GZRS add read access to the secondary copy (you can read locally redundant data in the secondary region even in normal operation).
- GRS/GZRS require the primary replica to be LRS/ZRS respectively.
How it fits (diagram)
Diagrams courtesy of Microsoft Learn / Azure docs: storage/common/storage-redundancy
Exam notes
- Default = LRS. Choose ZRS/GRS/GZRS explicitly.
- GRS is asynchronous to the secondary region → small RPO (~15 min). Only RA-* gives you readable secondary.
- LRS alone is not a full disaster strategy — it does not survive a datacenter loss.
- You can change redundancy after creating the account (upgrade paths exist); not all downgrades allowed.
Related
storage-account · storage-performance · blob-storage · azure-files
📘 Source: Microsoft Learn — Redundancy Lrs Zrs Grs