9.3 RPO, RTO & Backup Strategy

Theory: RPO, RTO & Backup Strategy

RAID keeps a server running when a disk dies (9.2), but it cannot bring back a deleted file or an encrypted database. That is the job of backup. This lesson answers three questions: how much data can we afford to lose (RPO), how long can we afford to be down (RTO), and which backup methods and layers achieve those numbers. It ends with a ransomware restore worked from start to finish.

RPO and RTO

Every recovery has two distances, measured from the moment of the incident:

Diagram loads as you scroll.

RPO (Recovery Point Objective): the maximum data loss we accept, measured back in time from the incident to the last good copy. RPO 1 h → we must back up at least every hour.

RTO (Recovery Time Objective): the maximum downtime we accept before the service is back, measured forward from the incident. RTO 4 h → the system must be working again within 4 hours.

Common mistake: mixing them up. RPO is about data (look backwards: when was the last copy?); RTO is about time (look forwards: when are we working again?). A system can meet one and fail the other: a backup taken every 5 minutes meets a 15-minute RPO, but if restoring it takes 2 days, a 4-hour RTO is missed.

Setting RPO and RTO by Business Impact

RPO and RTO are business decisions, not technical ones. Business owners set RPO and RTO by impact; IT designs the solution to meet them.

Example values for MediCare Plus:

System	Impact if it stops	RPO	RTO
EMR	Slower care; risk of wrong treatment	15 min	4 h
Pharmacy system	Medication orders delayed	1 h	8 h
HR payroll	Staff paid late	24 h	3 days

The bigger the harm per hour, the smaller the RPO and RTO, and the more the protection costs.

Backup Types

Type	What it copies	Backup speed / size	What a restore needs
Full	Everything	Slowest / largest	Full only (fastest restore)
Incremental	Changes since the last backup of any kind	Fastest / smallest	Full + EVERY incremental since it (slowest restore)
Differential	Changes since the last full	Medium / grows each day	Full + the LAST differential

With a full backup on Sunday:

Night	Sun	Mon	Tue	Wed	Thu	Fri
Incremental contains	Full	Mon	Tue	Wed	Thu	Fri
Differential contains	Full	Mon	Mon–Tue	Mon–Wed	Mon–Thu	Mon–Fri

Mini-example: the restore chain

Ransomware hits on Friday night, after Friday’s backup finished (and Friday’s backup is clean).

Incremental: Full (Sun) → Mon → Tue → Wed → Thu → Fri: 6 sets, applied in order.
Differential: Full (Sun) → Fri differential: 2 sets.

A long incremental chain is slow, and one broken backup breaks the chain: if Wednesday’s incremental is corrupt, Thursday’s and Friday’s cannot be applied, so you can only restore to Tuesday. With differentials, a bad Wednesday file does not matter for a Friday restore.

Ways to Protect Data: Not All Are Backup

	Backup	Log backup	Snapshot	Replication
What it is	Copy to a separate place	Copies only the changes (database transaction logs)	Point-in-time image on the same storage	Live copy to a second system; copies the damage too
How often / how fast	Hours	Every 5–15 min	Minutes	Seconds
Survives ransomware?	✓ (if stored safely, e.g. immutable)	✓ (same)	✗ (same storage, same admins)	✗ (encryption is replicated)
Is it backup?	BACKUP	BACKUP	ONLY IF COPIED OUT	NOT BACKUP

Replication protects you from a broken server. Backup protects you from a broken day. Replication faithfully copies deletions, corruption and encryption to the standby within seconds, so it is never a backup.

A log backup lets a database be restored to a point between two full/differential backups: restore the last full (and differential), then replay the log backups in order up to the chosen time.

From RPO/RTO to Backup Decisions

Driver	Rule	Example
RPO → how often	Back up at least once per RPO interval	RPO 15 min → log backups, snapshots or replication; RPO 24 h → a nightly backup is enough
RTO → how to restore	Keep the restore path short and reliable	A long incremental chain is slow; one broken backup breaks the chain
Cost → management	Lower RPO/RTO always costs more	Spend where impact is highest

At MediCare: the EMR gets frequent snapshots or replication plus an immutable full backup; HR payroll gets a weekly full and a daily differential.

Layered Protection at MediCare

System (RPO · RTO)	Full	Incr. / Diff.	Log backup	Snapshot	Replication
EMR (15 min · 4 h)	Weekly	Diff. nightly	Every 15 min	Hourly	Live
File server (4 h · 1 day)	Weekly	Incr. nightly	–	Hourly	–
HR payroll (24 h · 3 days)	Weekly	Diff. nightly	–	–	–

The first three columns are the real backup and belong on immutable storage. Snapshots and replication are speed layers: they make common, small incidents fast to fix, but they do not survive a determined attacker.

Which Layer Saves Us?

Incident	Layer that saves us	Action	Data lost	Time to recover
Server fails	Replication	Switch to the standby	~0	Minutes
Wrong edit at 14:20	Snapshot / log backup	Roll back to 14:15	Under 1 h (here 5 min)	Under 1 h
Ransomware	Immutable backup	Restore full + diff + logs	Back to the last safe restore point (hours, in the next example ~2 h)	Hours

For ransomware, replication and snapshots fail: the replica is encrypted too, and the snapshots are deleted or encrypted.

Ransomware: What Can We Restore?

The EMR has a full backup on Sunday at 01:00 and log backups every 15 minutes. Then:

Time	Event
Sun 23:10	The attacker deletes the backup jobs
Mon 01:00	The EMR is encrypted
Mon 07:00	Staff notice

The last log backup that ran was Sun 23:00 (the 23:15 job no longer existed).
Restore chain: Full (Sun 01:00) + logs 01:15, 01:30, …, 23:00 → restored to Sun 23:00.
Data lost: Sun 23:00 → Mon 01:00 = 2 h, so the 15-minute RPO is missed.

The backups were fine. Nobody noticed when they stopped. Monitoring that alerts when backup jobs stop or fail is part of the backup design, not an extra. (Seeing attacks like this while they happen is the job of logging and security monitoring.)

Ransomware Restore: Step by Step

Step	Action	Why
1. Isolate	Disconnect affected systems; stop replication	Stop the spread, including to the standby
2. Exclude	Do not trust the replica and snapshots	They are encrypted, deleted or possibly tampered with
3. Clean rebuild	New servers; reset admin passwords	The attacker may still have backdoors and stolen credentials
4. Pick the point	Choose the last good restore point (example: Sun 23:00)	After it, data may be encrypted or tampered
5. Restore	Full → logs, in order	Rebuild the data up to the chosen point
6. Verify	Scan; test with users	Make sure the data is complete and clean before go-live
7. Go live	Switch users back; re-enter paper records	Work done on paper during the outage must enter the system

Exam tip: in any ransomware question, check four things: (1) which layers survived (immutable / offline / off-domain copies) and which did not (snapshots, replicas, anything the admin accounts could reach); (2) the latest safe restore point and whether it meets the RPO; (3) the downtime compared with the RTO; (4) whether backups of the servers are from before the attacker got in.

Worked Examples

Exercise 1

The pharmacy system has RPO 1 h and RTO 8 h. Its current design is a backup every night at 23:00, and a test restore took 5 hours.

(a) The server fails at 18:00. How much data is lost? Is the RPO met?
(b) Is the RTO met?
(c) What one change fixes the problem?

Show solution ↓

Solution

(a) The last backup was the previous night at 23:00.

\text{Data lost} = 23{:}00 \text{ (yesterday)} \to 18{:}00 = 19\ \text{h}

19 h is far more than 1 h, so the RPO is not met. With only nightly backups, the worst case is almost 24 h.

(b) Restore takes 5 h ≤ 8 h, so the RTO is met ✓ (assuming the restore starts promptly).

(c) RPO 1 h means a copy at least every hour. Add hourly (or more frequent) log backups to the separate, immutable backup store. Recovery then becomes: last full/differential + log backups up to the last hour.

Answer: 19 h lost, RPO 1 h not met; RTO met; add hourly log backups.

Exercise 2

A file server has a full backup every Sunday. Ransomware hits on Friday night, after the Friday backup completed.

(a) Which backup sets are restored, in order, if the nightly backups are incremental?
(b) If they are differential?
(c) Wednesday’s backup file turns out to be corrupt. What is the latest day you can restore to in each case?

Show solution ↓

Solution

(a) Incremental: each incremental holds only one day’s changes, so every one is needed:

Full (Sun) → Mon → Tue → Wed → Thu → Fri (6 sets).

(b) Differential: Friday’s differential already holds all changes Mon–Fri:

Full (Sun) → Fri differential (2 sets).

(c)

Incremental: the chain breaks at Wednesday; Thursday’s and Friday’s incrementals depend on it. Latest point = Tuesday night.
Differential: Friday’s differential depends only on the Sunday full, so the bad Wednesday file does not matter. Latest point = Friday night ✓.

Answer: (a) Full + Mon + Tue + Wed + Thu + Fri; (b) Full + Fri differential; (c) Tuesday (incremental) vs Friday (differential).

Exercise 3

(In-class review) The Lab system is backed up every night at 23:00. The full backup runs on Sunday night; Monday to Saturday nights run a smaller backup. On Thursday at 15:00 ransomware encrypts the Lab system. The last good backup is from Wednesday 23:00.

(a) Incremental: which backup sets do you restore, in order?
(b) Differential: which backup sets do you need?
(c) How many hours of Lab data are lost?
(d) The Lab system has an RPO of 1 hour. Is it met? What would you change?

Show solution ↓

Solution

(a) Incremental: you need the full plus every incremental up to the last good one:

Full (Sun 23:00) → Mon 23:00 → Tue 23:00 → Wed 23:00 (4 sets).

(b) Differential: Wednesday’s differential already contains everything changed since Sunday’s full:

Full (Sun 23:00) → Wed 23:00 differential (2 sets).

(c) Data lost runs from the restore point to the attack:

\text{Wed } 23{:}00 \to \text{Thu } 15{:}00 = 1\ \text{h} + 15\ \text{h} = 16\ \text{h}

(23:00 → 00:00 is 1 h; 00:00 → 15:00 is 15 h.)

(d) 16 h > 1 h, so the RPO is not met. A nightly backup can lose up to 24 h; to meet 1 h:

Add log backups (or incremental backups) at least every hour, written to immutable storage that admin accounts cannot delete.
Add alerts when a backup job fails or stops, so a silent gap is noticed.
(Optional speed layer) snapshots for quick rollback of small errors, remembering they do not survive ransomware.

Answer: (a) Full + Mon + Tue + Wed; (b) Full + Wed differential; (c) 16 h; (d) not met, add at least hourly log backups to immutable storage, with job-failure alerts.

Exercise 4

The EMR is protected by replication to a standby in the same building, hourly snapshots, 15-minute log backups, and a weekly full + nightly differential on immutable storage in another site. For each incident, which layer recovers the EMR, and roughly how much data is lost?

(a) The EMR server’s motherboard fails at 10:07.
(b) A clerk overwrites a patient’s details by mistake at 14:20.
(c) Ransomware encrypts the EMR and its standby at 02:00; the log backups were still running normally until then.
(d) A fire destroys the whole building.

Show solution ↓

Solution

Incident	Layer	Why	Data lost
(a) Server fails	Replication	Switch to the up-to-date standby in minutes	~0
(b) Wrong edit at 14:20	Log backup (or snapshot)	Roll back to 14:15, the last log backup before the edit, then re-enter later good work	~5 min (an hourly snapshot alone would lose 20 min)
(c) Ransomware	Immutable backup: full + differential + logs	The standby is encrypted too; snapshots are on the same storage	Up to 15 min (last log backup before 02:00 is 01:45)
(d) Building fire	Immutable backup at the other site	The replica is in the same building and burns too	Up to 15 min, provided the log backups are sent offsite as they are taken

Answer: (a) replication; (b) log backup / snapshot; (c) and (d) the immutable, offsite backup. Replication only beats hardware failure.

Exercise 5

Use the “What Can We Restore?” timeline: EMR full backup Sun 01:00, log backups every 15 min, backup jobs deleted Sun 23:10, EMR encrypted Mon 01:00, noticed Mon 07:00.

(a) Write the restore chain and the latest restore point.
(b) How much data is lost? Is the 15-minute RPO met?
(c) How long had the backups been missing before anyone noticed?
(d) What single control would have prevented most of the loss?

Show solution ↓

Solution

(a) The 23:00 log backup ran; the 23:15 job had already been deleted. So:

Full (Sun 01:00) → log backups 01:15, 01:30, …, 23:00, in order → restored to Sun 23:00.

(b) $\text{Sun } 23{:}00 \to \text{Mon } 01{:}00 = 2$ h of data lost. $2\ \text{h} > 15$ min, so the RPO is missed.

(c) From the first missing job (Sun 23:15) to discovery (Mon 07:00):

23{:}15 \to 07{:}00 = 45\ \text{min} + 7\ \text{h} = 7\ \text{h}\ 45\ \text{min}

(d) An alert when backup jobs stop or fail (sent to a monitored on-call team). The backups themselves worked; the failure was that nobody noticed they stopped. An alert at about 23:15–23:30 could have led IT to re-enable the jobs and investigate before encryption at 01:00.

Answer: Full + logs to Sun 23:00; 2 h lost, RPO missed; 7 h 45 min unnoticed; backup-job monitoring and alerting.

Exercise 6

A junior admin proposes this order after a ransomware attack: “Restore the EMR from last night’s snapshot onto the existing server, check it works, then reset passwords.” Explain what is wrong and give the correct sequence.

Show solution ↓

Solution

What is wrong:

Snapshots are not trustworthy: they live on the same storage the attacker controlled, so they may be deleted, encrypted or tampered with (step 2: exclude replica and snapshots).
Restoring onto the existing server puts clean data back on a machine that may still contain the attacker’s backdoor; it can be encrypted again.
Resetting passwords last leaves the attacker’s stolen admin credentials valid while you restore.
The plan never isolates the systems or stops replication first.

Correct sequence:

Isolate: disconnect, stop replication.
Exclude the replica and snapshots.
Clean rebuild: new servers, reset admin passwords.
Pick the point: the last good restore point on the immutable backups.
Restore: full → (differential) → logs, in order.
Verify: scan and test with users.
Go live: then re-enter the paper records from the outage.