What do RTO and RPO mean, and how do they change your backup design?

RTO is how long you can be down; RPO is how much data you can afford to lose. A four hour RTO with a fifteen minute RPO means log shipping and rehearsed restores, not a nightly dump. A tight RPO pushes you toward continuous replication or point in time recovery, and a tight RTO pushes you toward warm standbys. Both are business decisions, and an untested backup satisfies neither.

RTO is the clock on how long the business can survive being down, RPO is how much data it can survive losing. They pull on different levers. A tight RPO means you need continuous replication or write ahead log archiving so you can do point in time recovery, whereas a tight RTO means you need something already warm, because restoring two terabytes from object storage is hours regardless of how good your backups are. What I push hardest on is drills. At my last place we ran a quarterly restore into a scratch environment and timed it, and the first attempt took eleven hours against a stated four hour RTO, purely because nobody had ever tested it at full data size. We fixed that with a standby replica plus snapshot restores. I also make the point that a replica is not a backup. If someone truncates a table, that truncation replicates in milliseconds.