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.

These four terms get used interchangeably, but each protects against a genuinely different failure. Keeping them straight is most of the skill.

A backup is a copy of your data taken at a point in time and stored somewhere safe. A snapshot is the same idea applied to a disk: a point-in-time image you can restore from. Backups protect against things that replication cannot help with, most importantly human error. If someone deletes three hundred patient records by accident, a backup from last night can bring them back.

Replication is continuous copying of data to a second location as changes happen. It shrinks your recovery point objective, because the second copy is only seconds or minutes behind. But it is not a backup, and this catches teams out: if someone deletes those records, replication faithfully copies the deletion. It protects against losing hardware, not against losing judgment.

High availability means running redundant capacity so that a single failure doesn't take the service down at all. In cloud terms this usually means running across more than one availability zone (remember, those are separate data centers with their own power and networking inside a region). If one server or one zone fails, traffic continues on the other. High availability is about avoiding downtime rather than recovering from it.

Disaster recovery is the plan for a much larger failure: an entire region going offline. That means a copy of your data and a way to run your application somewhere geographically separate, plus a documented process for switching over.

The classic discipline that ties this together is the 3-2-1 backup rule: keep three copies of your data, on two different types of storage, with one copy in a separate location or region. It predates the cloud, and it still catches the failure mode where all your copies live in the same place that just burned down.

The comparison makes the design decision concrete: choose each mechanism for the specific failure it covers, rather than treating every extra copy as the same kind of protection.

Once you have the two numbers, the design almost writes itself. The recovery point objective sets how often you copy data. A one-hour target means a daily automated backup is not enough on its own, so you add transaction log copies every fifteen to thirty minutes, guaranteeing you never have more than an hour at risk. The recovery time objective sets how you restore. Four hours is comfortable for restoring from a backup into a fresh database; four minutes would demand a standby copy already running and waiting — roughly double the database capacity, running whether you need it or not.

Then you check the failure types separately. Accidental deletion is answered by restoring from a backup or snapshot. A whole region offline is answered by a replicated copy in a second region. And one honest caveat belongs in every recommendation: tightening either number costs real money, usually in duplicated capacity, and an untested recovery process is an assumption, not a plan.

The core takeaway is that resilience is a conversation about two business numbers, and every technical choice downstream is just those numbers made concrete. Next you'll do a quick vocabulary check on the terms themselves, then a pattern-spotting exercise matching each mechanism to the failure it actually protects against, before writing a recommendation that turns a stated four-hour and one-hour target into something a director could sign.