DevOps Peach| SKU | Copies | Survives | Secondary reads |
|---|---|---|---|
| LRS | 3, in one datacenter | Disk, node, rack failures | — |
| ZRS | 3, across 3 availability zones in one region | Losing one zone/datacenter | — |
| GRS | 6: LRS in primary + LRS in a secondary region (async) | Losing a whole region | No (only after failover) |
| RA-GRS | Same as GRS | Losing a whole region | Yes (-secondary endpoint) |
| GZRS | 6: ZRS in primary + LRS in the secondary | Losing a zone and a region | No |
| RA-GZRS | Same as GZRS | Losing a zone and a region | Yes |
flowchart LR
subgraph P["Southeast Asia (primary)"]
Z1["Zone 1"]
Z2["Zone 2"]
Z3["Zone 3"]
end
subgraph S["East Asia (secondary)"]
D["3 LRS copies"]
end
P -- "asynchronous (RPO usually < 15 min)" --> S
- Writes to LRS/ZRS succeed only when all 3 copies commit (synchronous). Copying to the secondary region is asynchronous, so a failover may lose the latest writes; check
lastSyncTime. - GRS/GZRS are not readable in the secondary until failover; use RA- to read there.
- ZRS does not protect against losing a whole region.
- Change the SKU with
az storage account update --sku …(some changes, such as to ZRS, need a separate conversion process).
| Command | Meaning |
|---|---|
az storage account update -n stdevopslab01 -g rg-devops-lab --sku Standard_GRS |
Switch to GRS |
az storage account show -n stdevopslab01 -g rg-devops-lab --query sku.name -o tsv |
Show the current SKU |
RPO, RTO, and what replication is not
RPO (recovery point objective) is how much recent data you can afford to lose; RTO (recovery time objective) is how long recovery may take. Geo-replication is asynchronous, so its RPO is minutes, not zero.
Replication copies every change, including mistakes: deleting or encrypting a blob in the primary deletes or encrypts it in every copy. Replication protects against hardware and site failures; backup, soft delete, and versioning protect against human error and ransomware. You usually need both.
Failover options
| Type | Who starts it | Effect |
|---|---|---|
| Customer-managed planned failover | You, for testing or a known event | Swaps primary and secondary without data loss |
| Customer-managed unplanned failover | You, when the primary region is down | Secondary becomes primary; writes not yet synced are lost |
| Microsoft-managed failover | Microsoft, in a severe regional disaster | Used only in extreme cases |
After an unplanned failover the account is locally redundant in the new region until you enable geo-redundancy again, which starts a fresh copy.
Picking redundancy by scenario
| Scenario | Reasonable choice |
|---|---|
| Dev/test, data easy to recreate | LRS |
| Production in one region, needs zone resilience | ZRS |
| Must survive a regional outage | GZRS (or GRS where ZRS is not available) |
| Must also read during an outage | RA-GZRS or RA-GRS |
Higher redundancy costs more for storage and for geo-replication bandwidth. Not every region supports ZRS or GZRS, and Premium accounts support only LRS and ZRS.
Related features
Object replication copies selected containers to another account you choose, even in the same region, which is different from the platform-managed secondary of GRS. Applications using RA-GRS should be written to fall back to the -secondary endpoint for reads when the primary fails.