Skip to content

Redundancy and DR Best Practices

Use these practices to tie redundancy cost to a clear failover decision model and documented recovery expectations.

This page's baseline at a glance — the recommended practices and the validation gate:

mermaid flowchart TD T["Redundancy and DR Best Practices"] P1["Choose redundancy from business RPO and RTO"] T --> P1 P2["Test application behavior for secondary reads and manual"] T --> P2 P3["Keep backup and replication decisions separate in runbooks"] T --> P3 P4["Record who can authorize failover and how stakeholders"] T --> P4 P5["Review last sync time before any manual failover decision"] T --> P5 V["Validation Checklist"] P1 --> V P2 --> V P3 --> V P4 --> V P5 --> V

Why This Matters

Replication helps only when teams understand what a given mode covers and what it does not.

  • LRS, ZRS, GRS, and RA-GZRS solve different failure scenarios.
  • Secondary-read capability changes application design and testing needs.
  • Backup, replication, and failover communications should not be treated as the same control.
  • Choose redundancy from business RPO and RTO, not from naming familiarity.
  • Test application behavior for secondary reads and manual failover paths.
  • Keep backup and replication decisions separate in runbooks.
  • Record who can authorize failover and how stakeholders are informed.
  • Review last sync time before any manual failover decision.

Example review command

az storage account show \
    --resource-group $RG \
    --name $STORAGE_NAME \
    --query "{sku:sku.name,primaryLocation:primaryLocation,secondaryLocation:secondaryLocation,lastSyncTime:lastSyncTime,statusOfPrimary:statusOfPrimary,statusOfSecondary:statusOfSecondary}" \
    --output json
Command Purpose
az storage account show Capture the failover-relevant fields that should be reviewed before a DR drill or outage decision.
--resource-group Resource group that contains the storage account.
--name Name of the storage account to inspect.
--query JMESPath expression selecting redundancy and replication-status fields.
--output Output format for the result.

Common Mistakes / Anti-Patterns

  • Replication treated as backup: Replicated corruption is still corruption.
  • Geo-redundancy without testing: Paying for a secondary region is not the same as knowing how to use it.
  • Failover without communications: Technical recovery steps fail when ownership and messaging are unclear.

Validation Checklist

  • [ ] Redundancy maps to a documented outage model.
  • [ ] Secondary-read behavior is understood where applicable.
  • [ ] Backup and replication plans are separated.
  • [ ] Failover authority and communication steps are documented.
  • [ ] Last sync time is part of outage review.

See Also

Sources