Published Feb. 25, 2024
Ask a team how quickly they could recover a failed database and how much data they would lose, and the usual answer is "we have backups." That answers neither question. Two numbers do: RTO and RPO.
This guide explains RTO and RPO for cloud backup in plain terms, shows where teams go wrong, and covers what Bigbell can and cannot do about each number.
Recovery point objective (RPO) is how much data you can afford to lose, measured in time. Picture the moment a failure happens and look backward to your last good backup. The gap is your data loss. If the database is backed up daily at 02:00 and fails at 17:00, you lose fifteen hours of changes. If it fails at 01:59, you lose almost a full day. An RPO of 24 hours accepts that worst case.
Recovery time objective (RTO) is how long a service can stay down before the impact becomes unacceptable. It starts when the failure begins and ends when the service works again. That includes finding the right backup, restoring it, configuring the result, checking it, and sending traffic back.
The two numbers answer different questions. RPO is about data and is mostly controlled by how often you back up. RTO is about time and is mostly controlled by how well your restore process works.
The first mix-up is treating them as one number. A team can have an excellent RPO, with frequent backups, and a terrible RTO, because nobody has practiced a restore. The reverse is also possible.
The second is confusing the schedule with the result. A daily schedule suggests a 24-hour RPO, but only if every run succeeds. If a job quietly stops, your real RPO grows each day without anyone changing a setting. The number you wrote down and the number you have are not the same.
Third, RTO is usually guessed. Teams estimate it from how long they imagine a restore taking, not from timing one. Real restores run into permissions, missing configuration, and steps nobody wrote down.
Fourth, retention gets mistaken for RPO. Retention is how long copies are kept. It controls how far back you can go, which helps when corruption goes unnoticed for days, but it says nothing about how recent your newest copy is.
Finally, teams apply one objective to everything. A production database and an internal test server rarely need the same targets, and treating them alike either wastes money or leaves gaps.
Sort your systems into tiers and give each an RPO and RTO that the business has agreed to. Those numbers should come from the cost of losing data and being offline, not from whatever the current setup happens to deliver.
Set backup frequency at or below your RPO. If you can lose a day, daily backups work. If you cannot, daily backups are the wrong tool, however well they run. Keep in mind that a schedule only sets the intended frequency.
Compare the age of the newest backup with your RPO regularly. This is the check that catches the quiet failures. A server whose latest backup is older than its RPO is already out of target.
Measure RTO by doing a restore. Pick a system, restore its backup to a separate machine, and time every step. The result is usually longer than the estimate, and the notes you take become the start of a runbook.
Set retention separately, based on how late a problem might be noticed and what storage costs. Then revisit all of these numbers when systems are added, resized, or retired. If you are unsure which servers are covered at all, start with a full check of your backup coverage.
Bigbell helps mainly with the RPO side. Its backup management feature schedules backups for servers in connected AWS, Azure, and Google Cloud accounts, with a daily, weekly, or monthly frequency and a retention period in days. Each run creates an image on AWS or a snapshot on Azure and Google Cloud, and removes the copies it created that have passed retention.
Those frequencies matter for planning. Bigbell's scheduling is daily at its most frequent, so it fits RPOs of a day or longer. A system that cannot lose even a few hours of data needs another mechanism alongside it.
Backup discovery helps with the check described above. For each server, it shows the number of backups and how many days ago the latest one was taken, so you can compare that age with your RPO. A server with none shows "None," and the infrastructure scanner flags AWS instances with no image or snapshot as a high-severity finding.
On the RTO side, Bigbell does not perform or time restores, so that part stays with your team. For more on schedule design, see our deeper guide on staggering and retention.
Book a demo to see the backup view on your own servers.
What is the difference between RTO and RPO? RPO is how much data you can lose. RTO is how long you can be down.
Which one do backups affect most? RPO. How often you back up sets how much data is at risk.
How do I find my real RPO? Look at the age of your newest backup. That is your exposure right now.
How do I find my real RTO? Restore a backup to a test machine and time the whole process.
Does Bigbell restore backups? No. Restores are done separately.
Can Bigbell back up more often than daily? No. Its schedules are daily, weekly, or monthly.
Does Bigbell show how old my latest backup is? Yes. Backup discovery shows days since the latest backup for each server.
Is retention the same as RPO? No. Retention is how long copies are kept. RPO is how much recent data you can lose.
Should every system have the same targets? No. Set them by how much each system matters.
How often should I review my targets? Whenever systems change, and at least a couple of times a year.
What is a realistic RPO for a small team? That depends on how much a day of lost work costs. Many teams start with a daily RPO for important servers and tighten it only where the business needs it.
Why is my real RPO sometimes worse than my schedule suggests? Because a failed or stopped job leaves the newest backup older than planned. Checking backup age catches this.
What does an RTO include? Everything from the start of the failure to a working service: finding the backup, restoring, configuring, checking, and moving traffic.
Do RTO and RPO apply to test servers? Yes, but the targets can be much looser than for production systems.
Can retention improve my RPO? No. Retention only sets how far back you can recover.
Where should I record my targets? In a shared document next to each system's runbook, so everyone sees the same numbers.
