Azure Backup or Azure Site Recovery? Which Servers Need Which

Two Azure services come up in almost every disaster recovery conversation, and they get mixed up more than any others. Azure Backup and Azure Site Recovery are both part of Azure Recovery Services and both "recover" things, so it's easy to assume one covers the other. It doesn't. They answer different questions, and most environments need both, just not for every server.

Two Different Questions

Azure Backup answers "can we get the data back?" Microsoft positions it for protecting data against accidental deletion, corruption and ransomware, for short- and long-term retention, and for restoring anything from a single item to a whole workload. It runs on policies (a schedule, a frequency and a retention period), with recovery points kept in a Recovery Services vault or Backup vault. Microsoft's Azure Backup overview covers what it protects, from Azure VMs and Azure Files to SQL Server databases and on-premises files and folders.

Azure Site Recovery answers "can we keep running somewhere else?" It replicates Azure VMs, on-premises Hyper-V and VMware VMs, and physical servers to a secondary location, then orchestrates failover when the primary site is down and failback once it's healthy again (About Site Recovery).

Microsoft's own documentation draws the line plainly: Azure Backup focuses on backup and restore, and for disaster recovery and failover orchestration you use Site Recovery.

Why Replication Is Not a Backup

Site Recovery is built to keep a near-current copy ready to run. Microsoft documents continuous replication for Azure VMs and VMware VMs, and replication frequency as low as 30 seconds for Hyper-V. That is what you want in an outage. It is not what you want when the problem is bad data: replication copies changes as they happen, so a mass deletion or encrypted files on the source travel to the replica too.

Recovery points help, but only for a short window. For Azure VMs replicating between regions, Site Recovery's default replication policy keeps one day of recovery point history, and the oldest point you can recover to is 15 days with managed disks (Site Recovery FAQ). That's a continuity tool, not a retention strategy. When you need last quarter's version of a file, or a restore point that predates an attack nobody noticed for weeks, you need backup.

Which Servers Need Which

Start from what each application means to the business, not from the tool. A simple way to sort servers:

• Backup only. Systems the business can do without for a day or more while you restore them, such as file archives, reporting servers and test environments. A restore is fast enough, so replication would be paying for speed nobody needs.
• Backup and Site Recovery. Systems that have to come back quickly at another site, such as identity, line-of-business applications and the databases behind them. Site Recovery handles the outage. Backup handles deletion, corruption and ransomware, and keeps history beyond the replication window.
• Neither, by design. Servers you can rebuild from scripts or images faster than you could restore them. Write that down as the plan, so nobody discovers it during an incident.

Where each server lands depends on its recovery time and recovery point objectives (RTO and RPO), agreed with the people who run the business rather than set by whoever configured the policy. If those haven't been signed off, that's the first job.

Where an Existing Backup Platform Fits

Many organizations already run a third-party backup platform. That isn't a reason to replace it. Azure Backup can sit alongside it, for example for Azure VMs and Azure Files, while the existing platform keeps covering what it covers today. What matters is that every server has a named owner for backup and for recovery, and that nobody assumes the other tool has it covered.

In a recent DR engagement for a Canadian group of companies, Azure Backup, Azure Site Recovery and an existing third-party backup platform were already in place across two sites. We factored the existing platform into the design rather than replacing it, and wrote runbooks for failover, failback, re-protection and restore that the client's own team can follow.

Protect the Backups Themselves

Backups only help if they survive the incident. Two Azure Backup controls are worth checking on every vault:

• Soft delete. Deleted backup data is kept for 14 days by default at no extra cost, and you can extend the retention period up to 180 days, with charges beyond the first 14 days (soft delete for Azure Backup).
• Immutable vaults. Immutability blocks operations that could lose recovery points. You can lock the setting so it can't be reversed and use WORM (write once, read many) storage, so a malicious actor can't disable immutability and delete backups (immutable vault for Azure Backup).

Test Both, Separately

The two tools need different tests.

• For Site Recovery, run test failovers. Microsoft documents that a test failover doesn't affect ongoing replication or production, and recommends a test network isolated from production that mirrors it, with the same subnets, subnet names and IP address range (run a test failover). Recovery plans fail machines over in groups, in order, with scripts or pauses for manual steps between them, so the drill follows how your applications actually start.
• For backup, run test restores. Restore a single file, a database and a full VM on a schedule, and time each one. A backup job that reports success hasn't shown it can be restored inside your RTO.

An untested DR plan is a hope, not a plan. The same goes for backups nobody has restored.

Book a DR Readiness Review

If you're not sure which servers are covered by which tool, or when either was last tested, that's worth finding out on a quiet afternoon rather than during an outage. Book a DR readiness review to go through what you have, what each tool covers, and where the gaps are.