We close Part VI with Chapter 26: High availability and disaster recovery, which deals with how to make your systems resist failures and disasters. Because things fail: a server goes down, a region has problems, someone deletes data by mistake. The question is not if something will fail, but when, and how prepared you are. Before looking at strategies and tools, we need two fundamental concepts that guide all recovery decisions: RTO and RPO.

An uncomfortable truth about systems: everything fails at some point. Disks, servers, networks, even entire data centers. Serious companies don’t pretend it won’t happen; they prepare for when it does. This preparation for recovering from major failures is called disaster recovery (DR).

But “being prepared” costs money and effort, and not all applications need the same level. How much should you invest in recovery? To answer that, you first have to define what level of recovery you need, and that is measured with two questions: RTO and RPO.

RTO (Recovery Time Objective) is the maximum time your system can be down after a disaster before recovering. It answers the question: “if this goes down, how quickly do I need it back up?”

Examples of RTO by system type:

• An online store during a campaign: RTO of minutes (every minute down = lost sales).
• An internal reporting tool: RTO of hours (annoying, but tolerable).
• A historical archive system: RTO of days (almost no one notices).

Analogy: RTO is like asking yourself, if your car breaks down, “how long can I be without a car?”. If you need it for work every day, you want it fixed in hours (low RTO), even if that means paying for urgent towing and express repair. If it’s a weekend car, you can wait a week without a problem (high RTO) and look for the cheapest repair.

RPO (Recovery Point Objective) is the maximum amount of data (measured in time) you can afford to lose in a disaster. It answers: “if this goes down, up to what point in the past do I need to recover the data without it being a problem?”. In practice, it determines how often you need to make backups.

If your last backup was an hour ago and a disaster occurs, you lose the last hour of data. Examples:

• A bank: RPO of seconds (cannot lose a single transaction).
• An online store: RPO of minutes (losing a few minutes of orders would be serious but not catastrophic).
• A blog: RPO of hours or a day (losing the latest comments is tolerable).

Analogy: RPO is like asking yourself “how much work can I afford to lose if the computer shuts down without saving?”. If you save every 5 minutes, at most you lose 5 minutes of work (RPO of 5 min). If you only save once a day, you could lose a whole day’s work. The less you can afford to lose, the more often you must save (more frequent backups).

It’s essential not to confuse them: they measure different things.

RTO and RPO are the compass for your entire recovery plan. The stricter they are (RTO and RPO of minutes or seconds), the more expensive the solution (you need duplicated systems, constant backups, automation...). The more relaxed, the cheaper.

That’s why the first step is always to ask the business: “how much downtime and how much data can we tolerate?”. The answer determines how much to invest. There’s no point spending a fortune on instant recovery for a system no one would miss for a day.

Real world example: a company defines RTO and RPO for each system. For its payment platform: RTO of 5 minutes and RPO of 0 (they can’t lose any transaction or be down), so they invest in a duplicated and costly architecture. For its internal reporting system: RTO of 8 hours and RPO of 24 hours, so a simple daily backup and manual recovery are enough, saving a lot of money. Same company, very different strategies, each tailored to what each system really needs. Defining RTO and RPO first lets them invest money where it really matters.

• Everything fails at some point; serious companies prepare to recover (disaster recovery). But “being prepared” costs, and each system needs a different level.
• RTO (Recovery Time Objective): the maximum downtime tolerable before recovery (“how quickly am I back?”). Looks to the future; affects recovery speed.
• RPO (Recovery Point Objective): the maximum amount of data (in time) you can lose (“how much data do I lose?”). Looks to the past; determines backup frequency.
• Don’t confuse them: RPO looks to the past (data lost), RTO looks to the future (time to return).
• The stricter (minutes/seconds), the more expensive the solution. That’s why the first step is to ask the business what it can tolerate, and invest accordingly.

In the next subchapter we’ll look at the different disaster recovery strategies (from the cheapest to the fastest) that you choose according to your RTO and RPO.