Skip to content

Backup and Recovery

Recovery planning starts with one question: if this is lost, how long can we be without it, and how much data can we lose? For the platform, the most important thing to recover isn't a VM. It is the code and state that rebuild everything else. This page covers what is protected, the recovery targets, and how restores are tested.

Status: partly in place

Terraform state is protected with versioning, soft delete and delete locks. The VM backup policy is audit-only. There are no VMs today. Restore testing is not yet scheduled.


What must be recoverable

Asset Protection Recovery target
Terraform code GitLab, with every change in git history Minutes. Clone from GitLab or a mirror.
Terraform state Blob versioning, 30-day soft delete for blobs and containers, CanNotDelete locks on the resource group and storage account Under 1 hour. Restore a previous blob version.
Entra ID configuration (Conditional Access, groups, roles, access packages) Defined in code, so it can be re-applied. Entra soft delete keeps deleted users, groups and apps for 30 days. Hours. Re-apply from code.
Central logs The workspace itself, about 2 years archive for key tables Not rebuildable. Protect with delete locks.
Workload data (databases, storage) Owned by each workload. The platform sets the standard below. Set per workload
The whole tenant A documented rebuild, from zero to a working platform Days

Workload backup standard

Workload tier RPO (maximum data loss) RTO (maximum downtime) Backup
Critical 1 hour 4 hours Native point-in-time restore, plus a geo-redundant backup vault
Standard 24 hours 24 hours Daily backup, locally or zone redundant
Non-critical 7 days Best effort Weekly, or rebuild from code
Sandbox None None Not backed up

The backup baseline policy (psa-bak-baseline-001) reports VMs without backup. The built-in policy it uses can only audit. Automatic backup enrolment needs a separate DeployIfNotExists initiative and a vault per region, which is deferred until VMs exist.


Restore testing

A backup that has never been restored is an assumption, not a backup.

Test Frequency Pass criteria
Restore a previous Terraform state version for one deployment into a scratch container, then terraform plan against it Quarterly The plan runs, with the expected drift only
Recover a soft-deleted Entra object in a test Annually Recovered with its memberships intact
Workload restore for critical workloads Twice a year Meets the RTO and RPO above
Tenant rebuild walk-through of the rebuild document Annually Every step still matches the current code

Rebuilding the tenant

ci-templates/docs/tenant-rebuild-from-zero.md records how the tenant was built from an empty directory:

  1. Create a manual seed: a management subscription, state storage and the first federated identity.
  2. Terraform then builds the management groups, policy, identities and subscriptions, in the order described in the Landing Zone pages.

Keep that document current. It is the platform's disaster recovery plan for the worst case.