Storage Accounts & Redundancy
LRS · ZRS · GRS · GZRS · RA- · Changing redundancy
Practice questions for this topic →
Account types
| Type | Services | Redundancy |
|---|---|---|
| Standard general-purpose v2 | Blob (incl. Data Lake Storage), Queue, Table, Files | LRS, GRS, RA-GRS, ZRS, GZRS, RA-GZRS |
| Premium block blobs | Blob (incl. Data Lake Storage) | LRS, ZRS |
| Premium file shares | Azure Files (SMB and NFS) | LRS, ZRS |
| Premium page blobs | Page blobs only | LRS, ZRS |
Redundancy is set per storage account and shared by every service in it: put data with different needs in separate accounts. ZRS options vary by region.
Redundancy options
| Option | Copies | Durability | Survives | Read the secondary? |
|---|---|---|---|---|
| LRS | 3 in one datacenter (no choice of zone) | 11 nines | Drive, server and rack failures | — |
| ZRS | 3+ across zones (synchronous) | 12 nines | Zone failure | — |
| GRS | LRS + async copy to a secondary region | 16 nines (unconfirmed) | Region failure (after failover) | No |
| RA-GRS | As GRS | 16 nines (unconfirmed) | Region | Yes |
| GZRS | ZRS + async copy to a secondary region | 16 nines (unconfirmed) | Zone and region | No |
| RA-GZRS | As GZRS | 16 nines (unconfirmed) | Zone and region | Yes |
Microsoft Learn confirms LRS at 11 nines (storage redundancy and Azure Files pages, and the managed disks page) and ZRS at 12 nines on the managed disks page (the storage-account page's ZRS figure is quoted from Microsoft's docs in a Stack Overflow post). The 16-nines geo-redundant figure appears only in third-party pages, so treat it as unconfirmed. Geo-replication is asynchronous, so RPO is above zero. Microsoft recommends ZRS in the primary region plus a secondary region for high availability (and for Data Lake Storage).
Changing redundancy and failover
- Three ways: add or remove geo-replication or read access; add or remove zone redundancy by a conversion; or a manual migration. Geo and read access can change together; anything involving zone redundancy needs a separate two-step process.
- Planned customer-managed failover swaps regions with no data loss and restores the original redundancy on failback. Unplanned failover can lose writes after the Last Sync Time and leaves the account LRS. Microsoft-managed failover happens only in catastrophic situations.
Exam Tips
Tick each tip once you can answer it without looking.
“Cheapest redundancy, data can be recreated” → LRS.
“Survive a zone failure, data stays in one region” → ZRS.
“Survive a regional disaster” → GRS / GZRS.
“Survive zone AND region failure, and read during outage before failover” → RA-GZRS.
“App must read from secondary region during a primary outage” → RA- prefix (RA-GRS / RA-GZRS).
“Data residency forbids copies leaving the region” → ZRS (no geo).
“Some containers need GRS, others LRS” → Separate storage accounts (redundancy is per account).
“Big data analytics with directories and ACLs” → Enable hierarchical namespace (Data Lake Storage Gen2).
“Storage account types and redundancy” → Standard GPv2: all six options. Premium block blob, file share and page blob accounts: LRS or ZRS. Trap: Redundancy is per account.
“Ways to change storage redundancy” → Add or remove geo-replication or read access; add or remove zone redundancy by conversion; or manual migration. Trap: Zone changes need a separate two-step process.
“Choosing a zone for LRS” → Not supported; Azure may move LRS across zones; it protects against drive, server and rack failures. Trap: LRS durability is 11 nines.
“Microsoft recommendation for high availability” → ZRS in the primary region plus a secondary region. Trap: Also recommended for Data Lake Storage.