What is RPO (Recovery Point Objective)?
RPO (Recovery Point Objective) is the maximum amount of data a company accepts losing, measured in time. If the RPO is one hour, the backup has to be recent enough that, in the worst case, only the last hour of data is lost. It answers the question “how much work would we have to redo if everything went down right now?”.
How RPO works in practice
RPO links a business decision (how much data you can lose) to a technical one (how often the backup runs). One defines the other.
Set the business tolerance
Each type of data has a limit: a sales system cannot lose an hour; a reference file might accept a day. That limit is the RPO.
Translate it into backup frequency
RPO defines how often the copy has to happen. A 15-minute RPO requires a backup every 15 minutes, not once a day.
Measure the distance to the last copy
At the moment of failure, the lost data is everything that changed since the last backup point. The wider the interval, the bigger the loss.
Adjust by criticality
Not everything needs the same RPO. Setting it per system avoids paying for continuous protection where it is not needed, and avoids losing data where it is.
Sources: NIST SP 800-34 Rev. 1 and ISO 22301 (business continuity).
RPO by type of data
- Transactional, near zero Sales, orders, finance and the production database: every minute is money and obligation. They call for an RPO of minutes, with continuous or near-continuous copies.
- Operational, a few hours Work files, email and internal systems: redoing half a morning hurts, but does not stop the company. An RPO of a few hours usually fits.
- Reference, one day Documents that change little, records and stable materials: a daily RPO is enough and cheaper to maintain.
- Regulatory, no gap Data under a legal retention requirement may need a short RPO and long retention at the same time, by obligation, not just convenience.
Why RPO decides how much you lose
RPO is not technical jargon, it is the measure of the invisible damage of an outage. A company that backs up once a day effectively has a 24-hour RPO: if the system goes down at 5 p.m., all the work since the overnight copy can vanish. That is why most organizations admit a gap between the recovery they have and the one the business needs (Veeam, 2024), and why only part of them can restore following the plan they had on paper. Setting RPO per system, and backing it with the right backup frequency, is what turns “we lost the whole day” into “we lost a few minutes”. Alongside it runs RTO, which measures the time to come back.
How to set your company's RPO
Setting RPO is a business conversation before it is a technical one. Four steps make it concrete:
- List systems by criticalitySeparate what stops the company if it vanishes for an hour from what merely annoys. RPO is born from that classification.
- Ask how much work can be redoneFor each system, how much data could the team rebuild by hand? That is the ceiling of the RPO.
- Match backup frequency to the RPOThe copy has to run within the RPO window. A one-hour RPO with a daily backup is a promise that is not kept.
- Review when the business changesMore volume, more customers or a new legal duty shorten the RPO. It is not set once and forgotten.
In practice
RPO looks backward (how much data is lost); RTO looks forward (how long until you are back). Setting both per system is what turns continuity into a number, not a hope.
How Zamak handles RPO
Zamak Technologies sets the RPO together with the client, per system and by criticality, and backs each target with the right backup frequency and recovery testing. To size what an outage costs and which RPO is justified, a good starting point is the downtime cost calculator. It is part of Continuity in the Zamak Method.