Backup, Recovery, and Resilience

Everything you've learned so far in this course assumes the data is still there. This lesson is about the day it isn't: a server dies, someone deletes the wrong records, an entire region goes dark. The useful insight is that "how much protection do we need?" is not a technical question at all. It's a business question, and the cloud gives you a precise vocabulary for asking it.

In this lesson, you will learn to:

• Define recovery time objective (RTO) and recovery point objective (RPO), and explain what each target protects.
• Distinguish backups, replication, high availability, and disaster recovery by the failure each addresses.
• Turn stated RTO and RPO targets into a resilience recommendation a stakeholder can approve.

Two numbers frame every conversation about failure. The first is the recovery time objective (RTO): the maximum acceptable downtime before the service is working again. If a booking system has a four-hour recovery time objective, that means the business has decided it can survive four hours of nobody being able to book, and no longer.

The second is the recovery point objective (RPO): the maximum acceptable data loss, measured as time since the last recoverable copy. A one-hour recovery point objective means that if the system fails, you might lose up to the last hour of work, and the business has accepted that. Notice the shape of these two: recovery time objective is about how long you're offline, recovery point objective is about how much data you never get back. They are different numbers, they cost different money, and people confuse them constantly.

A helpful way to hold them apart is to imagine the moment of failure. Looking backwards from that moment, how much recent data can you afford to lose? That's the recovery point objective. Looking forwards, how long can the service stay dark? That's the recovery time objective.

Here, Victoria, a clinic manager, asks Dan, the cloud engineer, to protect her appointment system. Dan turns a vague request into two business targets rather than a blank check:

• Victoria: I need the appointment system protected properly. Just make it so we never lose anything.
• Dan: I can get close, but "never" gets expensive fast. Two questions instead. If it failed at 10 a.m., how long could the clinic run without it before it became a real problem?
• Victoria: Reception could work off paper for a morning. Half a day, maybe. Four hours is honest.
• Dan: Good, that's the recovery time objective. Now the other one. If we restored it and the last hour of bookings was missing, could you rebuild that hour from your own records?
• Victoria: An hour, yes. A whole day, absolutely not.
• Dan: Then one hour is the recovery point objective. Four hours and one hour, and now I know exactly what to build.

Notice that Dan never asks the stakeholder for a technical decision. He asks about the business day and converts the answers into targets.