Business continuity and disaster recovery in Azure — start with two numbers

Most conversations about disaster recovery start at the wrong end — with services and features. "Should we have geo-replication? Do we need Azure Site Recovery?" Those are the right questions, asked too early. The two numbers that actually drive the design are rarely put first: how long may the system be down, and how much data may be lost?

RTO and RPO: the two numbers everything hangs on

RTO (Recovery Time Objective) is how long it may take to get the system running again after an outage. RPO (Recovery Point Objective) is how much data the business can tolerate losing, measured in time — an hour of transactions, a day, a second.

Both are business decisions, not technical ones. An order platform where a one-hour RPO means lost orders has entirely different requirements from an internal reporting portal that can be rebuilt from source data over a weekend. Our first job is to set the numbers per system — not one value for the whole organisation, but one per service, based on what an outage actually costs.

Once the numbers exist, the rest becomes architecture instead of opinion.

Backup, high availability and disaster recovery are not the same thing

Three concepts get conflated, and the difference decides what you actually get for the money:

• High availability (HA) keeps the system up through failures within a region — a node that dies, a zone that drops out. In Azure that's availability zones and zone-redundant services. HA does not protect against a whole region becoming unavailable.
• Disaster recovery (DR) takes over when an entire region fails — by being able to keep running from another geographic location.
• Backup is your last resort against what neither HA nor DR protects you from: bad data, a deleted resource, a ransomware attack. Replication faithfully copies your mistakes too; backup lets you go back in time.

A system can have first-class HA and still lack both DR and usable backup. They solve different problems and each is needed in its own right.

The building blocks in Azure

With RTO and RPO set, we choose tools to match — not the other way round:

• Availability zones give HA within a region and should be the baseline for anything business-critical. The cost is low relative to the protection.
• Paired regions and geo-redundant storage (GRS/GZRS) replicate data to a second region. The foundation for DR when a whole region goes down.
• Azure Backup with an appropriate retention period and immutable vaults protects against deletion and attack — not just hardware failure.
• Failover groups for Azure SQL, and the equivalent patterns for other data services, turn recovery into a controlled handover rather than a manual rescue under pressure.
• Azure Site Recovery orchestrates failover for whole workloads where that's warranted.

Every step up this list costs more in money and complexity. The point is not to buy everything, but to match the level to what an outage actually costs the business. Protecting an internal portal like a payment flow is also a mistake — just a more expensive one.

A plan you haven't tested is a guess

This is the part most often skipped, and the only one that decides whether the rest was worth anything. A recovery plan that has never been run for real is not a plan — it's an assumption, and assumptions break precisely when it matters.

We test failover for real, planned and recurring: measure the actual RTO against the target, verify the data really is intact at the recovery point we promised, and write down where it hurt. Almost every first test reveals something — a dependency nobody thought of, a permission missing in the second region, a recovery step that only lived in someone's head. Better to find it on a Tuesday than during a real outage.

Where we usually start

When we come into an existing environment, we rarely start with the technology. We sit down with the business and set RTO and RPO per system, map what already exists against those numbers, and make the gaps visible and priced. From there, disaster recovery becomes a set of deliberate trade-offs instead of a nagging sense that you "probably ought to have better backup."

If you have systems where you don't know what a longer outage would cost — or a plan that has never been tested — that's usually where we begin.