DR Scenario: Point-in-Time Data Restore¶

Recover data from the recoverability half of DR — the Azure Backup Policy Module (L1) vaults — into a clean recovery resource group, validate it, and promote or copy it back. Use this for data loss/corruption (incl. ransomware/data-leak per the Incident Response Runbooks (K1)) rather than a whole-region outage. Copy per workload; fill every <PLACEHOLDER>.

This is the procedure the Automated Restore Drill (L4) rehearses every month into an ephemeral sandbox RG and reports via the RestoreDrillReport / Compliance Dashboard (S2) DR panel. If L4 has never passed for the item you are restoring, expect surprises.

Field	Value
Workload	`<WORKLOAD>`
Env	`<dev / staging / prod>`
Item(s) to restore	`<VM / Azure Files share / AKS / blob container>`
Recovery point	`<YYYY-MM-DD HH:MM UTC or "latest">`

Objective¶

Restore <ITEM> to point-in-time <RECOVERY_POINT> from the L1 vault into a recovery RG (never overwrite the live resource until validated), confirm integrity, then promote/copy and clean up.

RTO / RPO target¶

RTO: <≤ 4h (prod full restore)> — a restore rehydrates from a vault and is slower than a failover.
RPO: bounded by the L1 daily backup schedule (backup_time, default 23:00 UTC) — i.e. worst case ~24h of data since the last successful backup, unless an application-consistent point closer to the event exists.

Which vault holds what (`L1`)¶

Item	Vault type	`L1` policy
VM	Recovery Services vault	`azurerm_backup_policy_vm`
Azure Files share	Recovery Services vault	`azurerm_backup_policy_file_share`
SQL-in-VM	Recovery Services vault	`azurerm_backup_policy_vm_workload`
AKS cluster	Data Protection (Backup) vault	`azurerm_data_protection_backup_policy_kubernetes_cluster`
Blob	Data Protection (Backup) vault	(operational/vaulted blob backup)

Preconditions¶

You know the exact item, recovery point, and target recovery RG.

Recovery RG exists (separate from production), tagged appropriately:

az group create --name "<recovery-rg>" --location "<region>" \
  --tags purpose=dr-restore workload="<WORKLOAD>"

If this restore is part of a security incident, restore to an isolated network and scan before promoting (coordinate with K1).

Vault identifiers gathered:

RSV="<recovery-services-vault-name>"          # VM / Files / SQL-in-VM
DPV="<data-protection-vault-name>"            # AKS / blob
SRC_RG="<source-rg>"
RECOVERY_RG="<recovery-rg>"
SUB="<subscription-id>"
az account set --subscription "$SUB"

Recovery steps¶

Declare & start the clock per dr-plan-template.md §5; notify per §6.
List recovery points and pick <RECOVERY_POINT>.

VM (Recovery Services vault):

az backup recoverypoint list \
  --resource-group "$SRC_RG" --vault-name "$RSV" \
  --container-name "<container>" --item-name "<vm-name>" \
  --backup-management-type AzureIaasVM \
  --query "[].{name:name, time:properties.recoveryPointTime}" -o table

AKS (Data Protection vault):

az dataprotection recovery-point list \
  --resource-group "$SRC_RG" --vault-name "$DPV" \
  --backup-instance-name "<backup-instance>" \
  --query "[].{name:name, time:properties.recoveryPointTime}" -o table

Restore into the recovery RG (not over the live resource):

VM → restore disks, then build a new VM from them:

az backup restore restore-disks \
  --resource-group "$SRC_RG" --vault-name "$RSV" \
  --container-name "<container>" --item-name "<vm-name>" \
  --rp-name "<recovery-point-name>" \
  --storage-account "<staging-storage-account>" \
  --target-resource-group "$RECOVERY_RG" \
  --restore-mode AlternateLocation

Azure Files share → alternate-location restore into a recovery account:

az backup restore restore-azurefileshare \
  --resource-group "$SRC_RG" --vault-name "$RSV" \
  --container-name "<storage-container>" --item-name "<share>" \
  --rp-name "<recovery-point-name>" \
  --resolve-conflict Overwrite \
  --restore-mode AlternateLocation \
  --target-storage-account "<recovery-storage-account>" \
  --target-file-share "<recovery-share>" --target-folder "restore-<DATE>"

AKS → trigger a Data Protection restore to the recovery cluster/RG:

az dataprotection backup-instance restore trigger \
  --resource-group "$SRC_RG" --vault-name "$DPV" \
  --backup-instance-name "<backup-instance>" \
  --restore-request-object "@restore-request.json"   # alt-location target = recovery RG/cluster

Blob → vaulted/operational restore to the alternate (recovery) account using the corresponding az dataprotection restore request.

Monitor the restore job to completion:

az backup job list --resource-group "$SRC_RG" --vault-name "$RSV" \
  --query "[?properties.status=='InProgress'].{op:properties.operation, status:properties.status}" -o table
# AKS/blob:
az dataprotection job list --resource-group "$SRC_RG" --vault-name "$DPV" -o table

Validate in isolation (see checklist) before any promotion.
Promote / cut over once validated:
Re-point the app at the recovered data, or copy recovered files/disks back over the production target during a maintenance window.
For SQL data, prefer the SQL path in scenario-sql-failover.md.

Validation checklist¶

Restore job status = Completed (no warnings) in az backup job / az dataprotection job.
Restored disk/VM boots; restored share mounts; restored AKS PVCs bind.
Data integrity spot-check: row counts / file checksums / object counts match expectation for <RECOVERY_POINT>.
(Security restores) malware scan clean before promotion (K1).
Application smoke test against the recovered data passes.
Measured RTO recorded vs target; effective RPO (gap to <RECOVERY_POINT>) recorded.

Fail-back / cleanup¶

Once the live resource is healthy on recovered data, delete the recovery RG and any staging storage to stop spend:
```
az group delete --name "$RECOVERY_RG" --yes --no-wait
```
Remove temporary alternate shares/accounts created for the restore.
Confirm the regular L1 backup schedule resumes against the live resource.
Add/extend an L4 drill case if this restore exercised a path the drill does not currently cover.
File the post-DR review (dr-plan-template.md §8).

Sign-off¶

Field	Value
DR event / drill ref	`<id>`
Scenario	Point-in-time data restore
Item restored	`<VM / Files / AKS / blob>`
Recovery point used	`<YYYY-MM-DD HH:MM UTC>`
Date / time (UTC)	`<YYYY-MM-DD HH:MM>`
Operator	`<NAME>`
Restored to	`<recovery RG>` then `<promoted? yes/no>`
Measured RTO / effective RPO	`<actual>` / `<actual>`
Validation passed	☐ yes ☐ no — notes: `<…>`
Recovery RG cleaned up	☐ yes ☐ no
Reviewed by (IC)	`<NAME>`