Lab 04: Storage Replication and Failover¶

Create a geo-redundant storage account, record the baseline replication configuration, and practice the operational checklist that precedes a failover decision.

Prerequisites¶

• Azure subscription with permission to create storage, networking, and monitoring resources.
• Azure CLI logged in with the correct tenant and subscription.
• Variables defined for $RG, $LOCATION, $STORAGE_NAME, and any lab-specific names.
• A workstation or Cloud Shell session with access to the resource group.
• Optional Log Analytics workspace if you want to capture diagnostics during the lab.

Architecture Diagram¶

mermaid flowchart TD A[Operator workstation] --> B[Azure CLI] B --> C[Resource group] C --> D[Storage account] D --> E[Data path under test] D --> F[Lifecycle, networking, or replication control] D --> G[Validation and cleanup]

Step-by-Step Instructions¶

Step 1: Create a geo-redundant account¶

az storage account create \
    --resource-group $RG \
    --name $STORAGE_NAME \
    --location $LOCATION \
    --sku Standard_GRS \
    --kind StorageV2 \
    --allow-blob-public-access false \
    --output json

After this step, confirm the account sku.name is a geo-redundant tier such as Standard_GRS — replication status is only meaningful on geo-redundant accounts (Standard_GRS, Standard_GZRS, Standard_RAGRS, or Standard_RAGZRS).

Step 2: Inspect replication status¶

az storage account show \
    --resource-group $RG \
    --name $STORAGE_NAME \
    --query "{sku:sku.name,primaryLocation:primaryLocation,secondaryLocation:secondaryLocation,statusOfPrimary:statusOfPrimary,statusOfSecondary:statusOfSecondary,lastSyncTime:geoReplicationStats.lastSyncTime}" \
    --output json

After this step, confirm statusOfPrimary (and statusOfSecondary on geo-redundant accounts) reports available; on read-access accounts the secondary's lastSyncTime means writes made before that timestamp have replicated — not that every latest write is present.

Step 3: Upload sample content and validate the primary path¶

az storage container create \
    --account-name $STORAGE_NAME \
    --name $CONTAINER_NAME \
    --auth-mode login \
    --output json

mkdir -p lab-data/dr
cat > lab-data/dr/dr-test.txt <<'EOF'
Replication failover drill artifact created from the lab guide.
EOF

az storage blob upload \
    --account-name $STORAGE_NAME \
    --container-name $CONTAINER_NAME \
    --name dr-test.txt \
    --file ./lab-data/dr/dr-test.txt \
    --auth-mode login \
    --output json

After this step, confirm the uploaded blob is readable from the primary endpoint before you consider any failover.

Step 4: Review the failover command without executing it until approved¶

az storage account failover \
    --resource-group $RG \
    --name $STORAGE_NAME

Do not execute the failover command in this lab — read the command plan and note that account failover is region-wide and permanently changes the primary region until failback.

Validation Steps¶

1. Confirm the storage account properties match the intended SKU, kind, and access posture.
2. Validate the lab-specific feature from the consumer point of view rather than trusting only control-plane success.
3. Capture one or more JSON outputs that prove the configuration is active.
4. Record any timing behavior that matters, especially for lifecycle or replication scenarios.
5. Note the operational follow-up required before using the same pattern in production.

Example validation commands¶

az storage account show \
    --resource-group $RG \
    --name $STORAGE_NAME \
    --output json

az monitor diagnostic-settings list \
    --resource $(az storage account show --resource-group $RG --name $STORAGE_NAME --query id --output tsv) \
    --output json

Cleanup Instructions¶

• Delete lab resources when validation is complete to prevent ongoing cost.
• Preserve any JSON output or screenshots you need before deletion.
• If you created role assignments or network links used elsewhere, confirm scope before removing them.

az group delete \
    --name $RG \
    --yes \
    --no-wait

See Also¶

• Redundancy and DR Best Practices
• Backup and Data Protection
• Replication Lag Issues

Sources¶

• azure/storage/common/storage-redundancy
• azure/storage/common/storage-disaster-recovery-guidance