RPO and RTO explained: how much data you can lose and how fast you must be back

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-21

What do RPO and RTO mean?

NIST SP 800-34 Rev. 1, the contingency planning guide, defines three related measures. The SNIA Dictionary words the first two slightly differently, with the same meaning.

NIST also notes that, unlike the RTO, the RPO is not part of the MTD: it is a measure of how much data loss the process can tolerate, not of time spent down. Both numbers come from a business impact analysis: you ask the owner of each process what an outage costs and set the targets from the answers.

Schematic. The spans are not to scale.

How do backup frequency and run time set the RPO?

A backup captures the state of the data around the time a run takes place. If a run starts every T hours and takes d hours to finish, a failure that hits just before the next run completes finds the newest complete restore point about T + d hours old. That is the worst-case data loss:

worst-case data loss = backup interval + time a run takes

Two consequences are easy to miss. A nightly backup does not meet a 24-hour RPO, because the run itself takes time. And one failed run adds a whole interval: if the run before the failure did not complete, the newest good restore point is two intervals old. An RPO is met only by a schedule with some margin, and by someone being told when a run fails.

The RPO is also not the same as retention. The RPO is about the newest restore point; retention decides how far back you can go (see grandfather-father-son rotation). NIST SP 800-34 says the policy should set the minimum frequency and scope of backups from how critical the data is and how often new information arrives.

What sets the RTO?

The time to recover is the sum of several steps, and only one of them is copying data:

1. Noticing the failure and deciding to restore.
2. Getting a target ready: a new machine, a new mailbox, access and credentials.
3. Restoring the data, which takes the amount of data divided by the speed you actually get.
4. Checking the result and handing it back to users.

restore time = fixed overhead + data to restore ÷ restore throughput

The throughput is where the restore path matters. It is the slowest of the storage you read from, the connection between that storage and the target, the target's own write speed and any limits of the service you restore into. The path also decides how much you have to restore: one mailbox, one folder, or a whole machine, for which a file-level backup first needs an operating system to be installed. Storage tiers matter as well: cloud archive tiers can take hours before the first byte is available, for example S3 Glacier Flexible Retrieval at minutes to hours, with bulk retrievals of 5 to 12 hours according to AWS, and a tape has to be fetched and loaded. See choosing backup storage.

A worked example

A company of 25 people has Microsoft 365 mail and OneDrive and one file server with 800 GB. The owners set these targets: the order mailbox may lose at most four hours of mail and be back within four hours; the file server may lose a day and be back within eight hours. Every number below is an assumption chosen to show the method.

• Mail, RPO of four hours. A backup every 4 hours that takes 20 minutes gives a worst case of 4 h 20 min, which misses the target. Every 3 hours gives 3 h 20 min, which meets it, with room for a slow run.
• File server, RPO of 24 hours. A nightly backup that takes two hours gives a worst case of 26 hours. To meet 24 hours the interval has to be 22 hours or shorter, or the run has to get faster.
• File server, RTO of eight hours. Restoring all 800 GB from storage in the same building at 100 MB/s takes 2 h 13 min; with two hours of overhead for noticing, deciding and preparing a target, the total is about 4 h 13 min, which meets the target. If the only copy sits in a bucket reached over a 25 MB/s line, the copy step alone takes 8 h 53 min and the total is about 10 h 53 min, which does not. The options are a faster path, a copy close to the target, restoring the most important folders first, or a looser target.

The overhead is 60 minutes for mail and the virtual machine and 120 minutes for the file server, and the run times are 30, 20, 120, 120 and 10 minutes in the order of the rows. None of these figures is a measurement of any product. Measure your own: restore a known amount of data into a test target and time it.

Try your own numbers

The calculator below uses the same two formulas. It needs JavaScript; without it the table above carries the arithmetic. Nothing you type leaves your browser.

What do RPO and RTO not tell you?

• They are targets, not guarantees. A schedule can meet the RPO on paper and still lose data if runs fail unnoticed.
• They assume the backup is good. A restore point that cannot be read back meets no objective; that is the "0" in 3-2-1-1-0.
• They assume the people and the access are there: the credentials, the keys and the person who knows the steps.
• The RPO covers the newest restore point only. It says nothing about how far back you can go, which is retention.

How Restow handles this

Restow gives you the levers for the RPO and some of the paths for the RTO. It does not promise either number, and it has no measured restore times to quote.

Schedules, the RPO side

• Mail jobs (Microsoft 365 and IMAP) run on a schedule you set: every 15 minutes or less often, up to 31 days, or on a cron time. The first active source of a new tenant gets a job that backs up every 8 hours and runs a restore check every Sunday at 03:00.
• Machine jobs for servers and clients run every few minutes or hours (the smallest interval is 5 minutes), daily at a time, or when the machine connects. The agent checks in about every 5 minutes.
• File share jobs run on a schedule you set (daily, every N hours or on a cron time), at most hourly, so the smallest interval for a share is one hour.
• Proxmox VE jobs (a preview) take the cadences of a mail job since 0.4.2: every few hours, daily, on chosen weekdays, monthly or a cron expression, and not more often than hourly.
• For servers and clients, agent policies change what the schedule delivers. A policy can set a backup window (weekdays and a time range) in which scheduled backups, catch-ups and retries may start; a backup that is running continues, and "Back up now" ignores the window. It can catch up a missed backup in the next window, optionally only up to a maximum age, and retry a failed one up to ten times. A window can therefore make your RPO longer than the interval you wrote, and a catch-up or a retry makes up some of it. The window, the catch-up and the retries need agent 0.4.0, and without a policy agents behave as before.
• An update of Restow also moves the next run. From the moment an administrator confirms it until it is over, no new run starts; the dialog counts what is running and either stops it cleanly (the default), waits for it or does not wait. Schedules that fall due run afterwards. Agent 0.4.0 holds its own schedules during that time; older agents do not. Since 0.4.2 an update can also be planned for a chosen date and time, and nothing pauses before the confirmation that comes the countdown before it. After the server update, new runs also wait while Proxmox VE nodes and agents install the new release, 15 minutes at most.
• A backup that an administrator stops from the web app (since 0.4.2) ends as cancelled and does not count as the last backup, so the time since the last backup keeps growing until the next scheduled run starts normally.
• Until the first backup of an object has finished there is no restore point, so nothing is recoverable. The first backup of a large Microsoft 365 tenant can take days, because Microsoft throttles the Graph API.
• An overdue alert (backup.overdue) tells you when a backup is later than its schedule allows, so a failed run is noticed instead of silently doubling your data loss.

Restore paths, the RTO side

• Mail, calendar, contacts and OneDrive: restore a single item, a folder or a whole mailbox or OneDrive, into the original account or another one, non-destructively. Users can restore their own mailbox. You can also export mail as EML in a ZIP file or as MBOX; the download link is valid for 24 hours.
• Servers and clients: restore into a new folder on the machine, or download files as a ZIP file. Whole-machine restore means installing the operating system first; image backup with bare-metal restore is not available yet.
• SharePoint sites: download libraries, folders, files, lists and items as a ZIP, put files and folders back into their original library or another library of a backed-up site, and put list items back into their original list as new items.
• File shares: from a restore point, download as a ZIP, restore into a new folder, to the original location or into another share that allows restores. See file shares (SMB and NFS).
• Proxmox VE guests (preview): restore as a new guest with a new VMID. There is no live restore.
• If the primary storage is lost, a copy repository can be promoted to primary once it is proven complete. A copy covers mail, calendar, contacts, OneDrive, SharePoint sites, IMAP and Proxmox VE VM data, not servers, clients, file shares or Proxmox containers. See storage.
• Without a running Restow server, a standalone restore tool reads the storage and the master key.

What is not measured

Restow shows how long each run took and charts its throughput, so you can see your own numbers. It does not publish backup or restore speeds, and the release checks do not give a figure we could cite. Microsoft 365 backup and restore have not yet run against a real tenant in the release checks, so restore times for Microsoft 365 are unmeasured. The weekly restore check proves that a sample reads back and matches; it does not time a complete restore. Two newer checks go further without being a full test restore. Every new restore point of a file share is checked by reading up to 20 sampled files back and comparing them, and, since 0.4.2, every new restore point of a Proxmox VE guest is read back within minutes (a sample of its blocks). A Proxmox VE boot test (a preview, off by default) restores a restore point as an isolated temporary guest, starts it, waits for its guest agent and destroys it again, which shows that the restore point boots but not that the applications inside work. A full test restore into a separate target is still planned. Until then, time a real restore yourself. See Microsoft 365 and IMAP backup, restore and verification.

Frequently asked questions

Sources

Read on 21 October 2026.

1. NIST SP 800-34 Rev. 1: Contingency Planning Guide for Federal Information Systems (May 2010). Section 3.2.1 defines MTD, RTO and RPO; section 3.4.2 ties backup frequency to data criticality
2. NIST glossary: recovery point objective. The point in time to which data must be recovered after an outage
3. NIST glossary: recovery time objective. How long a system's components can be in the recovery phase before the damage is unacceptable
4. SNIA Dictionary (generated 28 April 2026): Recovery Point Objective, Recovery Time Objective. The storage industry's definitions, including that zero is a valid RPO
5. Amazon S3 storage classes. Archive tiers such as S3 Glacier Flexible Retrieval are retrieved in minutes to hours

Related articles

• The 3-2-1 backup rule Three copies, two kinds of storage, one location apart, and the extension with an immutable copy and zero errors. With a worked Microsoft 365 example.
• Full, incremental, differential and synthetic full A comparison table for storage use, backup time, restore effort and chain risk, plus forever-incremental, changed block tracking and deduplication.
• Choosing backup storage Local disk, NAS and NFS, S3-compatible object storage, tape and cloud archive tiers compared on cost, durability, immutability and restore speed.
• Grandfather-father-son (GFS) rotation Daily, weekly, monthly and yearly restore points with a calendar example, how it differs from keeping every backup for N days, and how it maps from tape to disk and object storage.
• Backup glossary reference Short definitions of backup, restore and retention terms, from 3-2-1 rule to WORM, with links to the articles and features pages that go deeper.