Skip to content
CAMPUX Cloud Bootcamp Lab · Backup & DR ← All labs
Hands-On Lab · Beginner
~30 min · a few cents · Cloud Shell
CLI · torn down at the end
Backup & DR

The proof: restore what you deleted.

A backup you have never restored is a rumour, not a recovery. Here you protect a file share with a Recovery Services vault, take a real recovery point, delete a file to stage the disaster, and pull it back from the vault — the full loop, on the cheapest workload that still teaches it.

Fig. 1 · The loop: protect, lose, restore
The file share is backed up into a recovery point in the vault; a file is deleted; a restore job returns it from the recovery point. file share payroll.csv vault recovery point file share restored back up restore delete the file — the everyday disaster
● Screen walkthrough Not yet recorded · ~6 min
Reel · 00:00 / 06:00

Victor protects a file share, takes a recovery point, deletes the file, and watches the restore job return it.

Placeholder — the page below stands alone until the reel lands
Why

Backup vs. redundancy vs. a snapshot you took once

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.

Before you begin — one-time setup

You need a free Azure account and the Azure CLI (az), signed in with az login. First time? The 15-minute Set up your machine page covers the account, the installs, and sign-in. Prefer zero installs? Run everything in Azure Cloud Shell (Bash), preinstalled and already signed in.

Cost & honesty

This is not strictly free tier: protecting a file share carries a small protected-instance charge plus a few pennies of snapshot storage. Run start-to-finish and tear down the same day and it costs roughly a few cents — but if you leave it running, that becomes a few dollars a month. The teardown section removes everything. Pairs with Class 36d — Azure Backup.

Step 1

A file share worth protecting

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

# 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
Checkpoint az storage file list --account-name "$SA" --account-key "$KEY" --share-name "$SHARE" -o table shows payroll.csv.
Step 2

A vault and a backup policy

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

# export the built-in default policy, then create our file-share policy from it
az backup policy show --resource-group "$RG" --vault-name "$VAULT" \
  --name DefaultVaultPolicy > afs-policy.json
az backup policy create --resource-group "$RG" --vault-name "$VAULT" \
  --policy afs-policy.json --name "$POLICY" \
  --backup-management-type AzureStorage
Checkpoint az backup policy list --resource-group "$RG" --vault-name "$VAULT" --backup-management-type AzureStorage -o table lists campux-afs-policy.
If DefaultVaultPolicy is not found

The built-in template name can vary by vault. If the policy show line errors, list what the vault already has — az backup policy list --resource-group "$RG" --vault-name "$VAULT" -o table — and export whichever policy it names instead, or skip the create entirely and pass an existing AzureStorage policy name straight to --policy-name in Step 3.

Step 3

Protect the share, then take a recovery point

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.

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 31-12-2026 -o table
Checkpoint Poll until the job is done: az backup job list --resource-group "$RG" --vault-name "$VAULT" -o table. When the Backup operation reads Completed, you hold a real recovery point. (A file-share backup usually finishes in a minute or two.)
Step 4

Stage the disaster: delete the file

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
Checkpoint The exists query returns false. The live share no longer has the file — but the vault still does.
Step 5

Restore it from the vault

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

# 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
Checkpoint Wait for the Restore job to read Completed in az backup job list ... -o table, then re-run the exists check: az storage file exists --account-name "$SA" --account-key "$KEY" --share-name "$SHARE" --path payroll.csv --query exists now returns true. The identical share that was missing the file has it back — the only thing that changed was a restore job. That is the entire lesson.
Down

Tear it down (mind soft delete)

Stop protection and clear the backup data, then remove the group. Soft delete is the trap here, and there is no longer a way around it: Azure Backup now enforces soft delete on every Recovery Services vault by default, and no client — portal, CLI, or PowerShell — can switch it off. Delete the backup data anyway; the recovery point moves into a soft-deleted state behind the scenes, at no charge for the default 14-day window, and that does not stop the resource group above it from being removed.

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

az group delete --name "$RG" --yes
az group exists --name "$RG"   # -> false
If the group delete refuses

Give the protection disable job a minute to finish moving the recovery point into its soft-deleted state — check az backup job list --resource-group "$RG" --vault-name "$VAULT" -o table — then delete the group again. Do not reach for az backup vault backup-properties set --soft-delete-feature-state Disable as a shortcut: Azure Backup's secure-by-default policy rejects that call outright on every vault created today, in every region, from every client.

End

What you can now honestly claim

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.