In this guide 6 sections
RTO is how long the business can be without a system before the damage becomes unacceptable. RPO is how much recent data it can afford to lose, measured in time. RTO decides how quickly you must restore. RPO decides how often you must copy data. Tighter targets cost more.
Two numbers, two different questions
Recovery time objective answers one question. After the system stops, how long until it is working again? Recovery point objective answers another. When it comes back, how old is the newest record you still have?
People mix them up because both appear in tender forms side by side. Keep them apart. A system can return in ten minutes and still have lost yesterday’s entries, or return slowly with every transaction intact.
Both are business decisions first. The technical team prices the options, but the owner of the process decides what an hour of downtime or a lost morning of data is worth.
Example one: a clinic booking system
A clinic runs appointments, patient notes and billing on one application with a PostgreSQL database. The front desk can fall back to paper for a morning, so the recovery time can be a few hours, but doctors cannot accept losing consultation notes. The recovery point must be tiny.
That mix points to continuous log shipping from the database, often called point in time recovery, plus a nightly full backup. The standby server can be a smaller instance started on demand rather than one running all day, which keeps the monthly bill modest.
Notice the shape. A loose RTO and a tight RPO give a cheap standby and a careful data design.
- RTO: a few hours, paper fallback at reception
- RPO: minutes, enforced by write ahead log archiving
- Nightly full backup plus continuous log copy
- Cold standby image kept ready in a second zone
Example two: a logistics dispatch system
A freight company tracks trucks, consignments and driver check ins, and if dispatch stops, trucks idle and customers call. Recovery time must be short here. Every minute of silence delays a delivery.
Yet losing the last ten minutes of GPS pings may be tolerable, since the next ping repairs the picture, so the recovery point can be looser than the clinic’s.
So the design flips. A warm standby application tier runs in a second zone, with a database replica that follows the primary. Failover is automated or one command. Backups still exist, but replication carries the load.
- RTO: minutes, warm standby and replica
- RPO: a short gap in tracking data is acceptable
- Health checks trigger failover
- Monthly drill that actually switches traffic
How the numbers set backup, standby and cost
Read the targets as design inputs. A daily backup cannot meet a recovery point of an hour, whatever the vendor brochure says. A single server cannot meet a recovery time of minutes, because rebuilding takes longer than that.
Each step tighter adds a layer. Nightly snapshots come first, then log shipping, then a replica, then a second region with traffic switching, and every layer adds running cost and one more thing to test.
Ask for a cost for each tier and let the process owner choose, since many firms discover that only one or two systems need the expensive tier.
Answering the client or tender question
Tender forms usually ask for your RTO and RPO per system. Do not quote a single company wide pair. List each system, its target and the mechanism behind it.
Only promise what a drill has proved. If you have never restored the database from backup, say the target is a design goal and name the date of the first test.
Build the table for your three most important systems this week and send it to the manager who signs the tender replies.
RTO and RPO worksheet
Each system gets its own row on a single printed sheet. Columns hold the business owner and what stops when it is down, then the target recovery time and point. The mechanism behind each target follows, with the last drill date and monthly running cost closing the row.
Open a blank worksheet to printQuestions owners ask
Can RTO and RPO both be zero?
Only with synchronous replication across sites and automatic failover, which is costly and complex. Most small firms choose small, nonzero targets for the few systems that need them.
Is RPO the same as backup frequency?
For plain backups, yes, roughly. With log shipping or replication the copy is continuous, so the recovery point can be much shorter than the interval between full backups.
Who sets the targets, IT or the business?
The business owner of each process sets them, and IT then reports what each target costs and what it needs to build.
How do we know the targets are real?
Run a restore or failover drill and time it. The measured result replaces the guess, and it is the figure to quote in a tender.