Published July 25, 2026
Part 1 defined both terms. Definitions are the easy part, though. The harder question is what numbers to actually pick, and how to tell whether your setup can meet them.
This part works through examples and shows how RTO and RPO for cloud backup translate into schedules and checks.
Take three systems in one company.
A customer-facing database changes constantly, and lost orders cannot be recreated. The business says it can lose at most a few hours of data and cannot be down for more than an hour. That is a tight RPO and a tight RTO.
An internal reporting tool is used during working hours. Losing a day of changes is annoying but survivable, and a day of downtime is tolerable. RPO and RTO are both around one day.
A development server holds code that also exists in version control. Losing a week of server state costs little, and it can be down for several days. Both targets are loose.
Seen together, the point is clear: the targets belong to the business impact of each system, not to the technology. They also come with a price. Tighter numbers need more frequent copies, faster restore methods, and more practice, and each step costs money and effort. The sensible approach is to be tight where it matters and loose where it does not.
People often believe backup frequency alone sets RPO. It sets the best case. The real figure also depends on when the failure happens within the cycle, whether the last run succeeded, and whether the backup captured a consistent state.
Take a daily backup. A failure just after a backup loses almost nothing. A failure just before the next one loses nearly a full day. If the last two runs failed silently, the loss could be three days. The worst case, not the average, is what an RPO has to survive.
RTO is misunderstood from the other side. It is not the time a restore command takes. It includes noticing the problem, deciding to act, locating the right backup, restoring it, and checking the result. Large volumes take longer to restore, and the slowest step is often the one nobody timed.
Finally, teams set targets once and never compare them with reality. A target that nobody measures is a wish, and the gap between the written number and the real one tends to grow quietly as servers and data volumes change.
Write targets in a short table: system, owner, RPO, RTO, and how the backup is taken. Keep it where incident responders can find it.
Map schedules to RPO honestly. A daily schedule supports an RPO of roughly a day, a weekly one roughly a week, and a monthly one roughly a month, in the worst case. If the target is smaller than the schedule interval, the schedule cannot meet it, and the gap needs a different solution.
Track the age of the newest backup for each system and compare it with the RPO. When the age passes the target, treat it as an incident in its own right, because you are already outside your stated tolerance.
Time a restore for each critical system at least occasionally, using realistic data volumes. Record the steps and the surprises. Those notes are worth more than any estimate.
Review targets when business needs shift. A reporting tool that becomes part of customer billing deserves tighter numbers than it had last year. For planning around specific failure types, see disaster recovery basics, Part 2.
Bigbell covers the backup-schedule side of this work. Its backup management feature lets you schedule daily, weekly, or monthly backups for servers in connected AWS, Azure, and Google Cloud accounts, with a retention period in days. Those three frequencies line up with the worst-case figures above: roughly a day, a week, or a month of data at risk.
That also defines what Bigbell cannot meet. Daily is the most frequent option, so a system that needs an RPO of hours needs another mechanism alongside it.
The other half is verification. Backup discovery shows, for each server, the number of backups and the days since the latest one. You can read that number directly against the RPO you wrote down. A server with no backups shows "None," and the infrastructure scanner flags AWS instances with none as high severity.
Bigbell does not perform or time restores, so measuring RTO remains a task for your team. Each scheduled run creates an image on AWS or a snapshot on Azure and Google Cloud, and removes the copies it created that are past retention.
Book a demo to compare your backup ages with your recovery targets.
What is a good RPO for a database? It depends on what a lost hour or day costs. Customer-facing data usually needs a tighter RPO than internal tools.
Why is my real RPO worse than my schedule? Because failed runs and the timing of the failure add to the gap.
Can weekly backups meet a daily RPO? No. A weekly schedule can leave up to a week of data at risk.
What affects RTO the most? Detection time, how quickly you find the right backup, the size of the data, and how well the restore steps are known.
Does Bigbell offer hourly backups? No. Schedules are daily, weekly, or monthly.
Does Bigbell show if a backup is too old? It shows days since the latest backup for each server, which you can compare with your RPO.
Does Bigbell perform restores? No. Restores and restore timing are done separately.
Which clouds does Bigbell support for backups? AWS, Azure, and Google Cloud.
How often should I revisit targets? When a system's role changes, and at least once a year.
Who should approve RTO and RPO values? The people who own the business impact, with DevOps confirming what is achievable.
What if my RPO is shorter than my backup interval? Then the schedule cannot meet it, and you need an additional mechanism for that system.
Do large databases have longer RTOs? Usually, because restoring more data takes longer. Time a restore at realistic size.
Should dev servers have targets? Yes, but loose ones. Write them down so the decision is deliberate.
How do I show targets to the business? A short table of system, owner, RPO, and RTO is usually enough.
Can I meet a tight RTO with backups alone? Sometimes. It depends on data size and how practiced the restore is, so time it rather than assume.
Is an untested RTO still useful? Only as a starting estimate. Replace it with a measured number after your first restore test.
Can Bigbell help me see which servers are outside their RPO? It shows days since the latest backup for each server, which you compare against your target.
Do RTO and RPO apply to databases and servers alike? Yes. Set them for each system based on its business impact.
