What are RPO and RTO?

RPO (Recovery Point Objective) is how much data you can afford to lose, measured in time - if you back up once a day, your RPO is up to 24 hours, because a failure just before the next backup loses everything since the last one. RTO (Recovery Time Objective) is how long you can afford to be down - the time to notice the failure, decide to recover, provision somewhere to restore to, and actually restore the data. They are the two numbers that define your recovery exposure.

How do I shrink my RPO toward zero?

Back up more often, and for near-zero RPO use continuous archiving instead of periodic dumps: PostgreSQL WAL archiving or streaming replication, MySQL binlog shipping. With continuous archiving you can recover to within seconds of the failure, because every change is captured as it happens rather than once per interval.

How do I shrink my RTO?

Most RTO is spent on two things: noticing the failure and having somewhere ready to restore to. Cut detection time with real alerting so you find out in minutes, not when a customer emails. Cut provisioning time by keeping a warm standby or a known-good box ready to fail over to, instead of building a new server during the incident. Restoring the data itself is usually the smallest part.

Free tool · Runs in your browser

If your database died right now…

…how much data would you lose, and how long would you be down? Those two numbers — RPO and RTO — are your real recovery exposure. Most teams have never calculated them. Here's yours.

How often you back up

Database size (GB)

Time to notice + decide (minutes)

Recovery target

The two numbers behind every recovery

“We have backups” is not a recovery plan — it's the first 20% of one. The questions that actually matter when something fails are how much data is gone and how long until you're back, and almost nobody has the numbers until they're living through the answer. RPO and RTO turn a vague hope into two figures you can look at and decide whether you can live with.

Usually the surprise is RTO: the dump restores fine, but it took 40 minutes to notice, another 30 to provision a box, and the whole time the product was down. Shrinking that means alerting that catches the failure fast and a known-good target ready to take over — which is exactly the recovery posture a control plane keeps in place for you.

Related free tools

systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS Backup script generatorDump, offsite, restore Log rotation estimatorWhen logs fill the disk

All free tools →

Don't find out your RTO during the incident.

Infraveil keeps a known-good copy ready to fail over to, watches for the failure so detection is in seconds, and proves recovery works before you need it — turning your RTO from a discovery into a guarantee, on infrastructure you own.

See how it works

Get the recovery playbook

Set real RPO/RTO targets and actually hit them. No spam.