Backup types, RTO and RPO explained
A backup type decides how much data is copied each night and how many pieces you need on restore day. RPO (recovery point objective) is how much data the business can afford to lose, measured as time. RTO (recovery time objective) is how long the service can stay down. The exam rule: RPO sets how often you must back up or replicate, RTO sets how fast your restore method and recovery site must be, and the cheapest design that meets both numbers is the answer.
Three backup types on one calendar
NIST SP 800-34 Rev. 1 describes the three classic types. A full backup captures all files in the selected scope. An incremental backup captures what was created or changed since the last backup of any type. A differential backup captures what changed since the last full backup, so it grows every day until the next full one.
Take a file server with a 500 GB full backup on Sunday night and 20 GB of newly changed data each day (assumed to be different files every day, so changes accumulate). The server dies on Thursday morning, before the Thursday backup runs.
| Strategy | Daily backup size (Mon to Fri) | Sets needed to restore on Thursday | Restore data |
|---|---|---|---|
| Full every night | 500 GB each | 1 (Wednesday’s) | 560 GB |
| Full Sunday + incremental | 20, 20, 20, 20, 20 GB | 4 (Sunday + Mon, Tue, Wed) | 560 GB |
| Full Sunday + differential | 20, 40, 60, 80, 100 GB | 2 (Sunday + Wednesday) | 560 GB |
The sizes come from simple arithmetic: the incremental chain stores 100 GB for the week, the differential chain 300 GB. The trade-off is the one NIST names: incrementals use the least media and time per night but need several sets to restore; differentials take longer each night but need only the full backup plus the latest differential. Full backups are simplest to restore from and the most expensive to take.
Restore time is where RTO bites. If the restore runs at an assumed 100 GB per hour, 560 GB takes 5.6 hours before any setup or validation. An RTO of 8 hours is tight but possible; an RTO of 4 hours is not, whatever the backup type, and the answer moves to replication or a standby system.
RPO and RTO read from the same outage
Place the failure on a timeline. Backups run at 01:00. The server fails at 00:30 the next night, so everything written since the previous 01:00 (about 23.5 hours) is gone. The worst-case loss equals the backup interval, so a nightly backup supports an RPO of roughly 24 hours, not 4. To get to a 4-hour RPO you back up at least every 4 hours or replicate continuously.
NIST SP 800-34 defines RPO as the point in time to which data must be recovered after an outage, and RTO as the length of time a system can be in recovery before the impact becomes unacceptable. It adds a third value, maximum tolerable downtime (MTD), and notes that the RTO must normally be shorter than the MTD. Exams rarely ask for MTD, but if it appears, it is the business limit; RTO is the technical target inside it.
MTTR and MTBF are averages, not targets
SY0-801 and Network+ N10-009 both list the four metrics together. MTBF is the mean time between failures (how reliable the thing is). MTTR is the mean time to repair (how fast it comes back). RTO and RPO are objectives you set; MTBF and MTTR are measurements you observe. A common derived figure is availability = MTBF / (MTBF + MTTR). With an MTBF of 1,000 hours and an MTTR of 4 hours, availability is 1000 / 1004, about 99.6 percent. Lowering MTTR improves availability as surely as raising MTBF.
Which recovery site fits which RTO
NIST SP 800-34 ranks the alternate sites by readiness. A cold site has space and infrastructure (power, connectivity, environmental controls) but no equipment installed, recovery takes days to weeks and it is cheapest. A warm site has equipment installed but not loaded with software or data, so recovery takes hours to days. A hot site has operating equipment, current software and near-current data, takes over quickly and costs the most. The same document notes that high availability is no substitute for backups, because corruption can propagate through a redundant system.
| Requirement in the scenario | Fits |
|---|---|
| RTO of days, tight budget | Cold site, restore from backup |
| RTO of hours, RPO of hours | Warm site or restore to prepared infrastructure |
| RTO and RPO of minutes | Hot site or active replication |
| Ransomware must not alter the copies | Immutable, offline or air-gapped backups |
For Azure, the same ideas map to Azure Backup (restore points, so RPO) and Site Recovery (replication, so lower RTO); see Azure Backup and Site Recovery. Disk-level redundancy such as RAID levels is not a backup: it survives a disk failure, not a deletion.
Which exams test this
| Exam | How the topic appears | Where on this site |
|---|---|---|
| SY0-801 | Domain 3 Security Architecture (19%), objective 3.4: site types, backups (retention, immutability, scope, restoration testing), DR and business continuity, RTO, RPO, MTTR, MTBF. Note: V8 launches Nov 17, 2026; SY0-701 until then | Security architecture explained |
| N10-009 | Domain 3 Network Operations (19%), objective 3.3: DR metrics (RPO, RTO, MTTR, MTBF), cold/warm/hot sites, active-active vs active-passive, tabletop tests | Network operations explained |
| AZ-305 | Design business continuity (15-20%): recommend backup and recovery that meets recovery objectives for compute, databases and unstructured data | Business continuity explained |
| AZ-104 | Monitor and maintain Azure resources (10-15%): Recovery Services vault, Backup vault, policies, restore, Site Recovery failover | Monitor and maintain explained |
| SC-500 | Minor: security controls for backup protection with Azure Backup security features | Identity and governance (20–25%) |
How questions are built around backups
The trap is mixing RPO and RTO. “Can lose at most 15 minutes of data” is RPO; “must be back within 2 hours” is RTO. The second trap is choosing a backup type for a requirement that is really about speed: a differential or incremental scheme changes restore effort, not whether you can meet a 30-minute RTO. Constraint words that decide the answer: “minimize storage” (incremental), “fastest restore” (full or differential), “ransomware” (immutable or offline copy), “verify” (restoration testing, since an untested backup is only a hope), and “failover” (replication or a hot site, not tape). Also watch for backup scope: a backup that leaves out the database or configuration cannot restore the service.
Question 1. A company backs up a file server with a full backup every Sunday and a daily backup of everything changed since Sunday. The server fails on Thursday morning. Which set of backups is needed to restore it?
- A. Sunday, Monday, Tuesday and Wednesday backups
- B. The Sunday full backup and the Wednesday backup
- C. The Wednesday backup only
- D. The Sunday full backup only
Show answer
Answer: B
A backup of everything changed since the last full backup is a differential backup. To restore you need the Sunday full backup plus only the latest differential, which here is Wednesday’s. Restoring Sunday plus Monday, Tuesday and Wednesday is the procedure for incrementals. The Wednesday backup alone lacks the unchanged files held in the full backup. Sunday alone would lose a week of changes.
Question 2. Management states that after an outage of the order system the business can tolerate losing at most 30 minutes of orders, and the system must be running again within 4 hours. Backups run once every night. What does the nightly schedule fail to meet?
- A. The MTBF of 4 hours
- B. The RTO of 30 minutes
- C. The RPO of 30 minutes
- D. The MTTR of 4 hours
Show answer
Answer: C
Losing at most 30 minutes of data is the RPO. A nightly backup can lose up to roughly a day of data, so it fails the RPO and needs more frequent backups or replication. The 4-hour requirement is the RTO, which depends on restore speed, not on the backup interval. MTBF and MTTR are measured averages, not objectives set by management.
Go deeper
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, the source for the backup types, site types, RTO, RPO and MTD used here.
- NIST glossary: recovery point objective, the one-line definition.
- Azure Backup architecture and concepts (Microsoft Learn), how vaults and restore points work in Azure.
- Related guides: risk management, qualitative vs quantitative, incident response lifecycle, storage redundancy explained, and how to study for certification exams.