Almost every conversation about backups starts in the wrong place: how much space, how often, what price. The two questions that actually define your policy are different ones, and they come down to two acronyms: RPO and RTO.
RPO: how much data you can afford to lose
RPO, or recovery point objective, is the amount of work you are willing to lose, measured in time. If you back up daily at three in the morning and the server is lost at six in the evening, you have lost fifteen hours of work. That is your real RPO.
The practical question to ask is direct: what happens if we lose today’s work? On a corporate website that changes once a month, almost nothing. On an online shop, fifteen hours of orders you cannot recover and customers who paid with no trace left.
RTO: how long you can be down
RTO, or recovery time objective, is how long you can survive without service. And here is the trap: RTO is not how long the technical restore takes. It is the total time from incident to operating again, and that includes detecting the problem, deciding what to do, running the recovery and verifying everything works.
A server that restores in twenty minutes can have a real RTO of four hours if nobody noticed the failure until the next morning. Detection is part of RTO, and almost nobody counts it.
Why define them before buying
Because they are the two numbers that determine what you need. An RPO of one hour demands hourly backups or continuous replication, not a nightly copy. An RTO of thirty minutes demands backups on fast storage nearby, not in a cheap remote archive.
If you pick the product first and then ask whether it fits, the usual outcome is discovering that it does not at the worst possible moment.
How to work them out without overcomplicating
A method that works: take your services, put them in a table, and for each one answer two questions with a number.
First: if we lose the last X hours of data, what does it cost to redo, or how much is lost? Second: if we are down for X hours, how much revenue do we forgo and what reputational damage follows?
You will see immediately that not everything deserves the same treatment. The online shop and the invoicing system need short RPO and RTO. The development server and the historical archive can tolerate far more. Applying one policy to everything means overpaying for the non-critical and falling short on what matters.
Typical values, for orientation
- Corporate website: RPO of 24 hours and RTO of a few hours is usually enough. A daily backup.
- E-commerce: RPO of 1 to 4 hours and RTO under an hour. Frequent backups on fast storage.
- Invoicing or ERP: RPO in hours, RTO in hours, and long retention for tax obligations.
- Development: RPO and RTO in days. It is rebuildable.
And then, verify it
An RPO and an RTO on paper are worth nothing until you measure them. RPO is verified by checking the real age of your last backup; RTO is verified by timing an actual restore. If you have never done it, your two numbers are assumptions.
How we work with them
Our backup services allow different frequencies and retentions per service, so you can tighten the RPO where it matters without paying for it across the whole fleet. And because we document measured restore times, your RTO is a figure rather than a hope. If you like, we will run the table exercise with you before you order anything.