Practical engineering guidance
Designing Azure backup and recovery around a tested restore
A backup job reporting success is a claim about a job. The only evidence that matters is a restore you performed, timed, and validated against what the business actually needs.
Series: Azure architecture
Every organisation I have worked with backs things up. A much smaller number can tell you how long a restore takes, and a smaller number still have done one recently for the workload they would actually need to restore.
The design principle worth adopting is that backup is not the deliverable. A demonstrated restore, within an agreed time, of data that is correct, is the deliverable — and designing backwards from that changes several decisions.
Requirements: the two numbers, agreed with the business
Recovery point objective — how much data you can afford to lose, which sets backup frequency. Recovery time objective — how long you can be down, which sets the recovery method.
These are business decisions and they must come from outside IT, in writing. An engineer choosing them alone has chosen the organisation’s tolerance for loss on its behalf, which is not a decision engineers should be making unilaterally.
The second number is the one that invalidates designs. A four-hour recovery time objective cannot be met by restoring several terabytes across a network link, regardless of how good the backup is. Find that out during design, not during an incident.
Two further requirements worth establishing early:
What is in scope. Virtual machines, managed databases, file shares, blob data, and — very commonly forgotten — the configuration itself. Resource Manager templates, policy assignments, role assignments and networking configuration are all things you would need after a serious incident, and none are covered by a virtual machine backup.
What threat you are protecting against. Accidental deletion, regional failure and ransomware need different answers. The third one is what has changed backup design most in recent years, because it assumes an attacker with your credentials who deliberately targets the backups.
Design: the vaults and what they do
Azure splits this across two vault types, and knowing which workload goes where saves confusion.
Recovery Services vaults cover Azure virtual machines, SQL in Azure VMs, SAP HANA in Azure VMs, Azure file shares, and on-premises workloads via the agent or MARS.
Backup vaults cover the newer workload set — Azure Blobs, Azure Disks, Azure Database for PostgreSQL and others.
The distinction is an implementation detail until you try to put a workload in the wrong one, at which point it is the whole conversation.
Redundancy, chosen deliberately
Vault storage redundancy is locally redundant, zone redundant or geo-redundant. This is set early and constrains what you can do later, so decide it against your actual failure scenarios rather than by default.
Cross-region restore — restoring to a paired region — requires geo-redundant storage and must be enabled. If regional failure is in your threat model, this is the setting that makes the difference, and discovering it was not enabled is not something you want to do during a regional outage.
Protecting the backups from your own credentials
This is the part that has changed, and it is the part most designs have not caught up with.
Soft delete retains deleted backup data for a period, so a deletion is recoverable. It is on by default for Recovery Services vaults, and it is the single most important protection against an attacker or a mistake removing backups.
Immutable vaults prevent backup data being modified or deleted before its expiry, and the immutability can be locked so the setting itself cannot be reversed. This is the strongest available protection against ransomware that targets the backup system, and the locking is the point: an attacker with sufficient rights cannot turn it off.
Multi-user authorisation, implemented through a Resource Guard, requires a second authorised party to approve destructive operations on the vault — disabling soft delete, reducing retention, stopping protection with data deletion. Placing the Resource Guard in a separate subscription or tenant, administered by different people, is what gives it force.
These three together are what make backups survive a Tier 0 compromise. Without them, an attacker who reaches your Azure administrative credentials can delete the backups before encrypting anything, and frequently does.
Deployment
- Define the scope and the two numbers, agreed and written down.
- Choose vault type, region and redundancy, including cross-region restore if regional failure is in scope. Redundancy is difficult to change after the vault holds data.
- Enable soft delete, immutability and multi-user authorisation before protecting anything. Retrofitting immutability to an existing vault is more constrained than setting it at the start.
- Create policies per workload class rather than per resource, with retention that reflects a stated requirement rather than a comfortable-sounding number.
- Enforce enrolment with Azure Policy, so a new virtual machine is protected without
anyone remembering. This is the same
deployIfNotExistsapproach as in Azure Policy as a guardrail, and unenrolled resources are the most common gap in an otherwise sound design. - Back up the configuration too — infrastructure as code in version control, which is both the backup and the rebuild mechanism.
- Then do a restore, before declaring any of it complete.
Validation: the restore test is the design
This is the part the article exists for. A restore test is not a checkbox; it produces four pieces of information you cannot get any other way.
How long it actually took. Measured, from decision to usable service. Compare it against the recovery time objective. In my experience the first measurement is regularly several times the assumed figure, and that gap is the finding.
Whether the restored data is correct. Have someone who knows the data confirm it — not the person who ran the restore. A restore that completes and produces subtly wrong data is worse than a failure, because it is trusted.
Whether the restored system actually works. A restored virtual machine needs its network, its identity, its dependencies and its certificates. A database restored without the application that uses it has not restored a service. This is where restores fail in practice.
What you could not reach. Documentation, credentials, the vault itself — the same class of finding as in Active Directory forest recovery planning, and for the same reason.
Test at a realistic scale. Restoring a small test virtual machine proves the mechanism works, not that your recovery time objective is achievable for the system that matters.
Schedule it: at least annually, and after any significant change to the workload, the vault configuration or the network.
Operations
Monitor backup jobs and alert on failure. A job that has been failing quietly for weeks is the most common finding in any backup review.
Alert on destructive vault operations — disabling soft delete, reducing retention, stopping protection. These should be rare and deliberate, which makes them high-quality signals.
Review retention against cost periodically. Retention is where backup cost accumulates, and long retention adopted “to be safe” is frequently paying for data nobody would ever restore.
Re-check what is unprotected. New resources appear. The policy enforcement above is what stops this, and the report of unprotected resources is what tells you the policy is working.
Rollback and honest limits
Restoring is itself the rollback, but a restore usually overwrites or replaces something. For anything significant, restore to a new resource and validate before replacing the original — in-place restore of a system that is merely suspected of being damaged can destroy the evidence of what happened and the only remaining good copy simultaneously.
The limits worth stating: backup protects against loss, not against a compromise you have not detected. Restoring from a backup taken after an attacker was present restores the attacker’s access along with the data, which is why incident response has to establish a timeline before a restore point is chosen. Backup also does not provide high availability — a service that must not stop needs redundancy, and backup is what you use after that has failed.
This article is a design framework rather than a procedure. Per-workload restore steps are version-specific and documented by Microsoft.
Verification and limits
Recovery Services and Backup vault workload coverage, storage redundancy options, cross-region restore requiring geo-redundancy, soft delete, immutable vaults with locking, and multi-user authorisation via Resource Guard were checked against current Microsoft documentation on 20 September 2026.
Nothing here was deployed or restored for this article — which is precisely the gap the article argues you should close in your own environment. Vault redundancy and immutability settings are constrained after data exists, so decide them before protecting workloads. Confirm current capability, regional support and cost implications before committing to a retention model.
References
Reader feedback
Was this article useful?
No ratings yet. Be the first to rate this article.