Sequence 3 — Storage Redundancy & Disaster Recovery

Prerequisites: Sequences 1–2 (account kinds, regions). · What you'll be able to do: pick the correct redundancy option for a durability/cost/availability target · explain primary vs paired secondary region and read access to it · change redundancy and know the constraints · plan planned vs unplanned vs Microsoft-managed failover and reason about RPO/RTO. · Est. time: ~14 min.

Azure Storage always stores multiple copies of your data — redundancy is not optional, only the scope of replication is configurable. The redundancy setting is per storage account and applies to every service in that account (Blob, Files, Queue, Table). If two workloads need different durability, put them in separate storage accounts.

1. The two axes of redundancy

Every redundancy option is a combination of two independent decisions. Memorize the axes and the six names fall out automatically.

• Axis 1 — Primary region layout: Local (LRS) = one physical datacenter, vs Zonal (ZRS) = three or more availability zones (separate power, cooling, networking).
• Axis 2 — Geo-replication: none, vs asynchronous copy to a paired secondary region hundreds of miles away. Add read access to that secondary with the RA- prefix.

The prefixes decode cleanly: G = geo (second region), Z = zone (zones in primary), RA- = read access to secondary.

2. The six options compared

Key facts to lock in:

• Within the primary region, writes are synchronous — the call returns only after all replicas (one datacenter for LRS, all available zones for ZRS) acknowledge.
• To the secondary region, replication is asynchronous — this is the source of potential data loss (see §5).
• In the secondary region, data is always replicated with LRS, regardless of whether the primary is GRS or GZRS. The only difference between GRS and GZRS is the primary-region layout (LRS vs ZRS).
• Microsoft's recommendation for high availability: use ZRS in the primary region, and for the strongest posture choose RA-GZRS (maximum availability and durability).

Redundancy protects against hardware/infrastructure failure only. All replicas reflect the same state — a delete or overwrite is applied to every copy at once. It is not a backup. Object-level protection (soft delete, versioning, snapshots) comes in Sequence 11.

3. Primary, secondary, and the paired region

When you create the account you choose the primary region. The secondary region is the fixed Azure-assigned paired region — you cannot choose or change it. The secondary sits hundreds of miles away to survive a regional disaster.

With GRS/GZRS (no RA-), the secondary is inaccessible for read or write until a failover promotes it. With RA-GRS/RA-GZRS, the secondary is always readable at a separate endpoint: append -secondary to the account name — e.g. myaccount.blob.core.windows.net → myaccount-secondary.blob.core.windows.net. The account access keys are identical on both endpoints.

Azure Files does NOT support RA-GRS/RA-GZRS. Files can use GRS/GZRS (geo-redundancy) but offers no read access to the secondary. This is a classic exam trap.

4. What supports what

Durability/availability by outage scenario (the heart of the exam logic):

¹ Failover is required to restore write availability after a primary region outage.

Account-type and service support — the constraints worth memorizing:

• Recommended for all six options: Standard general-purpose v2 (StorageV2). Premium block blobs (BlockBlobStorage) and SSD/premium file shares (FileStorage) support LRS and ZRS only (no geo).
• ZRS is not available for legacy types (general-purpose v1 Storage, legacy BlobStorage) — those support LRS and GRS/RA-GRS only.
• Archive tier is supported for LRS, GRS, RA-GRS but not for ZRS, GZRS, RA-GZRS.
• Unmanaged disks: no ZRS/GZRS; GRS technically possible but not recommended (async-consistency risk).
• All tiers including archive are geo-replicated when geo-redundancy is on — geo-replication copies every object (block/append/page blobs, queues, tables, files).

5. Changing redundancy after creation

You can change the redundancy option on an existing account — but with limits.

# Inspect current redundancy (Sku.Name = e.g. Standard_LRS, Standard_RAGRS, Standard_GZRS)
az storage account show \
  --name mystorageacct --resource-group rg-storage \
  --query "sku.name" -o tsv

# Upgrade LRS -> GRS (with read access): a "conversion"
az storage account update \
  --name mystorageacct --resource-group rg-storage \
  --sku Standard_RAGRS

Set-AzStorageAccount -ResourceGroupName "rg-storage" `
  -Name "mystorageacct" -SkuName "Standard_GZRS"

How a change happens depends on which axis you touch:

• Adding/removing geo (the G): e.g. LRS↔GRS or ZRS↔GZRS — a live update, no downtime; turning RA- on/off (Standard_GRS↔Standard_RAGRS) is also a simple toggle.
• Changing the primary layout (the Z): e.g. LRS↔ZRS or GRS↔GZRS — a conversion. This can be a customer-initiated conversion (you request it) or a manual migration (create a new account and copy data with AzCopy). Conversions are one-directional in practice for some paths and can take time; plan ahead.
• You cannot mix an unsupported account type/tier (e.g. you can't put an archive-tier blob account on GZRS).

Mnemonic: toggling geo is easy; changing the zone layout is a conversion.

6. Disaster recovery: the three failover types

Geo-redundancy alone keeps a copy in the secondary. To actually use it for writes you fail over, which repoints the Azure DNS endpoints so the secondary becomes the new primary.

¹ No data loss provided both regions stay available throughout the planned failover and failback.

Do NOT design around Microsoft-managed failover. Microsoft initiates it only in extreme circumstances and only for a whole physical unit — it cannot be triggered for an individual account, subscription, or tenant. For selective DR, use customer-managed failover. Customer-managed failover requires the ARM deployment model (classic/ASM accounts must be migrated first).

7. What failover does to the account

This is the highest-value detail in the episode — the planned vs unplanned outcomes differ sharply.

Read the redundancy-config column carefully: after an unplanned failover the account is plain LRS in the new primary, with no copy elsewhere. You must re-enable GRS/RA-GRS, which triggers re-replication that incurs egress/bandwidth charges, and any archived blobs must be rehydrated to an online tier first (also billed). A failover typically completes in under one hour.

8. RPO, RTO, geo-lag, and data loss

Because geo-replication is asynchronous, the secondary lags the primary.

• RPO (Recovery Point Objective) = how much data you can lose = the geo-lag between the last primary write and the last write copied to the secondary. Azure's Geo priority replication targets RPO ≤ 15 minutes for block blobs.
• RTO (Recovery Time Objective) = how long to restore service = roughly the failover time (typically < 1 hour for customer-managed).
• Last Sync Time is the property that makes RPO concrete: it is the most recent time at which primary data was confirmed written to the secondary. Everything written before Last Sync Time is safe on the secondary; anything after it may be lost on an unplanned failover. Design apps to log writes so you can compare write times against Last Sync Time and estimate exposure.
• An unplanned failover loses any primary data not yet synced, and can introduce inconsistencies when hierarchical namespace (ADLS), change feed, or point-in-time restore are enabled (replication then happens at file/log granularity). A planned failover expects no data loss.

Object replication ≠ geo-redundancy. Geo-redundancy copies the whole account to its fixed paired region for DR. Object replication (Sequence 4) asynchronously copies selected block blobs between accounts you choose (even cross-region/cross-subscription) per a policy — a different feature for a different purpose. Note: an account in an object-replication policy can't be failed over.

9. Design for high availability

• Default to RA-GZRS for business-critical apps: zone resilience in the primary, geo-protection, and a readable secondary you can test against in advance.
• Design for transient faults: ZRS DNS repointing during a zone event means apps should implement retry with exponential back-off.
• Build read-failover into the app: on primary read failure, retry against the -secondary endpoint (RA- accounts only).
• Redundancy is not backup — also enable soft delete / versioning (Seq 11), use Azure Backup for Files and disks, and consider Azure Site Recovery for VMs.
• Failover is not migration — it's a temporary DR mechanism, not a way to move data; the Storage resource provider does not fail over (management ops stay tied to the original primary), and VMs / unmanaged disks do not fail over automatically.
• Copy-as-alternative: instead of failing over, you can AzCopy data to an account in an unaffected region and repoint the app.

Key takeaways

• Two axes → six names. Axis 1 = Local vs Zone in primary; axis 2 = Geo + optional RA- read. Decode any name: G = second region, Z = zones in primary, RA- = read the secondary.
• Durability ladder: LRS 11 nines → ZRS 12 nines → GRS/GZRS 16 nines. Geo wins on durability; only GZRS/RA-GZRS survive a zone loss and a region disaster.
• Sync inside the primary, async to the secondary. Async lag = RPO. Secondary is always LRS.
• GRS vs GZRS differ only in the primary (LRS vs ZRS). RA- = readable -secondary endpoint. Azure Files has no RA-.
• Planned failover = clean swap, geo retained, → GRS, no data loss. Unplanned failover = old primary deleted, → LRS, geo lost, possible data loss, re-replication billed.
• Don't rely on Microsoft-managed failover — region-wide only, can't target one account.
• Last Sync Time = your RPO yardstick. RTO ≈ failover time (< 1 hr).
• Redundancy ≠ backup; failover ≠ migration; geo-redundancy ≠ object replication.

Exercises

1. Recall. What are the two independent choices that generate all six redundancy options, and what do the prefixes Z, G, and RA- each mean?
2. Recall. State the durability figures (number of nines) for LRS, ZRS, and GRS/GZRS.
3. Applied. An account is Standard_GRS. You need to read data from the secondary region for reporting during a primary outage, with no failover. Which SKU do you set, and what hostname does the app target?
4. Applied. A team runs an SSD (premium) Azure Files share and asks for RA-GZRS. What do you tell them, and what is the strongest redundancy they can actually get?
5. Scenario. A GZRS general-purpose v2 account suffers a confirmed region-wide outage in its primary. You initiate a customer-managed unplanned failover and it completes in 40 minutes. (a) What redundancy state is the account in afterward? (b) What happened to the data in the original primary? (c) What must you do to get geo-redundancy back, and what cost/prep is involved? (d) How would you have estimated the data lost?
6. Scenario. You want to validate your DR runbook every quarter without losing data. Which failover type do you use, what happens to the primary/secondary roles, and what is the redundancy state after failover and after failback?

Coming up next

Sequence 4 — Encryption at Rest & Object Replication: how Azure protects data at rest with Microsoft-managed and customer-managed keys, and how object replication asynchronously copies selected blobs between accounts — a feature distinct from the geo-redundancy you just learned.