IT glossary
RTO and RPO (Recovery Time Objective and Recovery Point Objective)
RTO is how long you can be down before it really hurts. RPO is how much data you can afford to lose. Together they decide what your backups have to do.
They are the two numbers that decide what your backup system actually has to be able to do, and almost nobody sets them deliberately.
Why it matters to you
Backups are usually bought as a product (“we have backups”) rather than designed against a requirement. That is how organizations discover, on the worst day, that the restore takes three days and the most recent copy is from Saturday night.
Setting the two numbers first turns a vague worry into a design decision. If your business genuinely cannot lose more than an hour of orders, that has a cost and a shape. If it can survive a day, that is a much cheaper system, and you get to spend the difference elsewhere.
How to set them
Pick a system, the accounting package, the project files, email, and ask two questions:
- If this were unavailable, at what point does it stop being an inconvenience and start costing money or credibility? That is your RTO.
- If we lost everything entered since the last copy, how much re-entry could we tolerate? That is your RPO.
Do it per system, not for the whole business. The file share and the payroll system rarely deserve the same answer.
The part people skip
A backup you have never restored from is an assumption. The number that matters is not whether backups ran, it is how long a real restore took the last time somebody tried it. If nobody has tried it, that is the first thing to fix.