Recovery time objective and recovery point objective: what they mean in plain English
Recovery time objective (RTO) is the longest a system can be down before the outage does real damage. Recovery point objective (RPO) is how much recent work you can afford to lose, measured in time. Both are numbers you pick ahead of time, and they decide what your backups and recovery plan need to look like.
What recovery time objective means
RTO is the maximum time between a failure and the moment the system is back and working for people. If your order system can be down for four hours before customers start calling and sales stop, your RTO is four hours.
The clock starts when the outage starts, not when someone finally notices. That matters more than most people expect. If a server fails at 9 a.m., nobody spots it until 11, and the restore takes two hours, you are already at four hours before anything is back. Your RTO has to cover detection, decision, restore, and a quick check that the system actually works.
A useful way to set it is to ask what happens at one hour, one day, and one week without the system. Most systems have a point where the pain jumps from annoying to expensive. That point, a little before it, is your RTO.
What recovery point objective means
RPO is about data, not time on the clock. It answers the question: if we have to restore from backup, how far back will the restored copy be? If you back up every night at 2 a.m. and the server dies at 4 p.m. the next day, you lose about 38 hours of changes, or everything since the last backup. Some of that work might be rebuilt from email or paper. Some of it won't.
The rule is simple. Your backups must run at least as often as your RPO allows. If you can tolerate losing one day of work, nightly backups are fine. If losing a day would mean re-keying a week of orders, you need backups several times a day, or continuous replication that copies changes as they happen.
One thing people miss: an RPO only counts if the backup actually succeeded. A nightly job that has been failing silently for six weeks gives you a RPO of six weeks, whatever the plan says. Check that backups are completing, not just scheduled.
How to set your numbers
Start with a list of the systems your business can't run without. Most small businesses have between three and six: email, accounting, the customer database, the shared files, the point-of-sale or booking system, and maybe a website. For each one, answer two questions.
- How long can we manage without it? Pick a number of hours. That is your RTO.
- How much work could we lose and still recover? Think about what you could rebuild from paper, email, or memory. Pick the amount of time that fits. That is your RPO.
Then compare the cost of each system being down with the cost of making recovery faster. If an hour of downtime costs you real money or real customers, tighten the RTO and pay for the faster restore. If the system is an internal archive that nobody opens most weeks, a looser RTO of a day or two is perfectly reasonable.
The same goes for RPO. Customer-facing data and anything where money moves through it usually deserves a tight RPO. Old project folders and completed records usually don't.
Why the two numbers pull against each other
Tighter numbers cost more. A short RTO usually means having a spare system ready to take over, or at least hardware and a restore process that can bring things back quickly. A short RPO means backing up more often, storing more copies, or running replication that copies changes continuously. Each step down in either number adds cost and complexity, so it's worth being honest about which systems really need it.
Once you have numbers, test them. A backup you have never restored is a guess about how long recovery will take and whether the data will open. Do a test restore of one important system at least once a year, and time it. Write down how long it actually took. If the real figure is longer than your RTO, you have found the problem before it mattered.
Revisit the numbers after big changes, like a new software system, a new office, or a move to a different provider. Systems that were minor last year can become central without anyone updating the plan.
Your next step
This week, write down an RTO and RPO for your three most important systems, even if the numbers are rough. Then check them against what your backups actually do: how often they run, whether they are succeeding, and how long a real restore takes. If the gap is bigger than you'd like, reach out to Tech Parachute through the contact details on our website and we can talk through what it would take to close it.