Define RPO and RTO

Two numbers drive every backup decision, and you should write them down before touching any tool.

The Recovery Point Objective (RPO) is how much recent data you can afford to lose. If you back up nightly and the disk dies at 11 PM, you lose a day of work. Your actual RPO is 24 hours, whether you chose that or not.

The Recovery Time Objective (RTO) is how long recovery may take. From “it’s broken” to “it works again”. That includes finding credentials, downloading data, and verifying the result — not just the restore command.

Set targets per dataset

Different data deserves different numbers. Write targets for two different datasets:

family photos: RPO 1 day, RTO 3 days
customer orders: RPO 5 minutes, RTO 1 hour

Losing a day of photos is sad but survivable, and nobody needs them back within the hour. Losing five minutes of paid orders costs real money and trust, so that dataset needs frequent backups and a fast, rehearsed restore.

Each number maps to a concrete mechanism. Connect RPO to backup frequency and replication: an RPO of 5 minutes means continuous archiving or streaming replication, because no nightly dump can meet it. Connect RTO to restore speed, staffing, instructions, and replacement infrastructure: a 1 hour RTO means a written runbook and somewhere ready to restore to.

Do the bandwidth math

RTO promises die on transfer speed. Check yours:

# 500 GB over a 100 Mbit/s connection:
# 500 * 8 / 0.1 / 3600 = ~11 hours, before verification

If your data lives in remote object storage and your office uplink gives you 100 Mbit/s, a “restore within 2 hours” target is fiction. Either keep a local copy too, or change the target to match reality.

One warning: replication alone can copy deletions and corruption immediately. A replica gives you a great RPO against hardware failure and nothing against DROP TABLE. It does not automatically meet historical recovery needs — only versioned backups do that.