The proof: restore what you deleted.

Read the step before copying. Bash commands belong in Git Bash on Windows or Azure Cloud Shell set to Bash; PowerShell uses different syntax. A JSON, YAML, Bicep or application-code example belongs in the named file, not directly at the terminal prompt. Follow any shell-specific instructions below.

Keep the same terminal open so earlier variables remain available. Copy one complete command block without the terminal's $ prompt. A backslash continues a command onto the next line. If Bash shows a lone >, it is waiting for the rest of a quote, command or file block. Finish the complete block; if the paste was incomplete, press Ctrl+C and copy it again. Do not paste the next step into an unfinished command.

A line such as RG="training-group" stores a value without printing it. Output captured with $(...) is also stored; a blank screen alone does not prove failure. A sleep deliberately waits, and -o none suppresses normal output. Wait for your normal prompt, then run the step's checkpoint. After an error, stop and keep the exact command and message; later steps cannot repair a missing resource. Never share passwords, access tokens or secret values in a screenshot.

Storage redundancy (LRS/ZRS/GRS) keeps extra copies of your data against a hardware failure — but it faithfully replicates a deletion or a ransomware encryption too, because it does not know the change was a mistake. A one-off snapshot is better, but nobody remembers to take them and nobody knows when the last one was. Azure Backup is the discipline in between: a policy takes recovery points on a schedule and keeps them for a set retention, in a Recovery Services vault that lives apart from the data it protects. This lab runs the whole loop on an Azure Files share — the cheapest, fastest workload that still teaches vault, policy, recovery point, and, the part that actually matters, the restore.

A backup you never restore is a rumour.

Create a storage account, a small file share, and drop one file in it — the thing you will later "lose."

Commands inside $(...) save their output in a variable. Check the printed identifier or the checkpoint before continuing. Normal command output is suppressed here. Use the checkpoint to verify the resource or result; an error still needs investigation.

# Windows/Git Bash: stop it mangling resource-id arguments (harmless on macOS/Linux)
export MSYS_NO_PATHCONV=1

SUFFIX=$RANDOM
RG="campux-lab-dr-rg"
LOCATION="eastus"
SA="campuxdr$SUFFIX"          # 3-24 lowercase alphanumeric
SHARE="campuxfiles"
VAULT="campux-dr-vault"
POLICY="campux-afs-policy"

az group create --name "$RG" --location "$LOCATION" -o table
az storage account create --name "$SA" --resource-group "$RG" \
  --location "$LOCATION" --sku Standard_LRS --kind StorageV2 -o none
az storage share-rm create --resource-group "$RG" \
  --storage-account "$SA" --name "$SHARE" --quota 1 -o none

# upload one throwaway file, using an account key
KEY=$(az storage account keys list -g "$RG" -n "$SA" --query "[0].value" -o tsv)
echo "The quarterly numbers nobody wants to lose." > payroll.csv
az storage file upload --account-name "$SA" --account-key "$KEY" \
  --share-name "$SHARE" --source payroll.csv -o none

The vault holds recovery points apart from the share. Set its redundancy while it is empty (you cannot change it once backups exist), then build a file-share policy from the built-in default template so you do not have to hand-write the schedule JSON.

az backup vault create --resource-group "$RG" --name "$VAULT" \
  --location "$LOCATION" -o table

# cheaper local redundancy for a throwaway lab — must run before any backup item exists
az backup vault backup-properties set --name "$VAULT" --resource-group "$RG" \
  --backup-storage-redundancy LocallyRedundant

# a new vault has no file-share policy to copy, so write one: back up daily, keep 30 days
cat > afs-policy.json <<'EOF'
{
  "properties": {
    "backupManagementType": "AzureStorage",
    "workLoadType": "AzureFileShare",
    "schedulePolicy": {
      "schedulePolicyType": "SimpleSchedulePolicy",
      "scheduleRunFrequency": "Daily",
      "scheduleRunTimes": ["2026-01-01T19:30:00Z"]
    },
    "retentionPolicy": {
      "retentionPolicyType": "LongTermRetentionPolicy",
      "dailySchedule": {
        "retentionTimes": ["2026-01-01T19:30:00Z"],
        "retentionDuration": { "count": 30, "durationType": "Days" }
      }
    },
    "timeZone": "UTC"
  }
}
EOF
az backup policy create --resource-group "$RG" --vault-name "$VAULT" \
  --policy afs-policy.json --name "$POLICY" \
  --backup-management-type AzureStorage

Enable protection, then trigger an on-demand backup rather than waiting for the schedule — you want a recovery point in hand and you want to watch a job finish.

Commands inside $(...) save their output in a variable. Check the printed identifier or the checkpoint before continuing.

az backup protection enable-for-azurefileshare \
  --vault-name "$VAULT" --resource-group "$RG" \
  --policy-name "$POLICY" --storage-account "$SA" \
  --azure-file-share "$SHARE" -o table

# capture the exact container + item names the later commands need
CONTAINER=$(az backup container list --resource-group "$RG" --vault-name "$VAULT" \
  --backup-management-type azurestorage --query "[0].name" -o tsv)
ITEM=$(az backup item list --resource-group "$RG" --vault-name "$VAULT" \
  --backup-management-type azurestorage --query "[0].name" -o tsv)

az backup protection backup-now \
  --vault-name "$VAULT" --resource-group "$RG" \
  --container-name "$CONTAINER" --item-name "$ITEM" \
  --retain-until "$(date -u -d '+30 days' +%d-%m-%Y)" -o table

Now lose it — the deleted spreadsheet, the fat-fingered delete, the everyday incident that item-level restore exists for.

az storage file delete --account-name "$SA" --account-key "$KEY" \
  --share-name "$SHARE" --path payroll.csv

az storage file exists --account-name "$SA" --account-key "$KEY" \
  --share-name "$SHARE" --path payroll.csv --query exists   # -> false

Find the recovery point and restore just that one file back to its original location.

Commands inside $(...) save their output in a variable. Check the printed identifier or the checkpoint before continuing.

# the newest recovery point
RP=$(az backup recoverypoint list --vault-name "$VAULT" --resource-group "$RG" \
  --container-name "$CONTAINER" --item-name "$ITEM" \
  --backup-management-type azurestorage --workload-type azurefileshare \
  --query "[0].name" -o tsv)

az backup restore restore-azurefiles \
  --vault-name "$VAULT" --resource-group "$RG" --rp-name "$RP" \
  --container-name "$CONTAINER" --item-name "$ITEM" \
  --restore-mode originallocation \
  --source-file-type file --source-file-path "payroll.csv" \
  --resolve-conflict overwrite -o table

Two things Azure Backup did while you were not looking. It put a delete lock called AzureBackupProtectionLock on the storage account, so the group cannot be deleted until that lock goes. And soft delete is always on for new vaults: when you delete the backup data, the recovery point is kept, free, for 14 days, and the vault cannot be deleted while it holds one. So the honest teardown removes everything except the empty vault today, and the vault after the hold ends.

az backup protection disable \
  --vault-name "$VAULT" --resource-group "$RG" \
  --container-name "$CONTAINER" --item-name "$ITEM" \
  --backup-management-type azurestorage --workload-type azurefileshare \
  --delete-backup-data true --yes -o table

# remove the lock Azure Backup added, then delete what can be deleted today
for LOCK in $(az lock list --resource-group "$RG" --query "[].id" -o tsv); do
  az lock delete --ids "$LOCK"
done
az storage account delete --name "$SA" --resource-group "$RG" --yes
az resource list --resource-group "$RG" --query "[].name" -o tsv   # -> only campux-dr-vault

You created a Recovery Services vault, built a backup policy, protected an Azure Files share, took an on-demand recovery point, and — the part most engineers never do — actually restored, returning a deleted file from the vault to its original place. You know a vault stores recovery points apart from what they protect, that a policy is a schedule plus a retention, and that soft delete guards the backups themselves (and blocks a careless teardown). The same loop scales up: a full share restore, a full VM restore, or a cross-region restore where the vault is GRS. The one DR step this lab deliberately skips is an Azure Site Recovery test failover — it needs replicated VMs and target-region compute, so Class 36e — Azure Site Recovery covers it as a walkthrough rather than a paid exercise.