RPO vs RTO: How to Define Before Buying Backup (and Why Most Companies Get It Wrong)

Almost every company that contracts backup asks the same wrong question: "how much does backup cost?"

The right question is different: "how much data can I afford to lose, and how long can I afford to be down until recovery?"

These two answers have technical names — RPO and RTO — and they are what define the actual design of a backup solution, not the other way around. Buying backup without defining RPO and RTO first is like buying car insurance without knowing if you want coverage against theft, collision, or both — you will only find out what you bought on the day you need to use it.

In this article

1. What is RPO, in practical terms

2. What is RTO, in practical terms

3. Why the two metrics together define the cost

4. The most common mistake: defining RPO/RTO after purchasing the solution

5. How to calculate RPO and RTO for your business

6. Backup is not the same as Disaster Recovery

7. The 3-2-1 policy (and why it is still the foundation of everything)

8. Tested restore: the step everyone skips

9. Conclusion

What is RPO, in practical terms {#rpo}

RPO — Recovery Point Objective answers a question: if something goes wrong right now, what is the maximum acceptable age of the data I will recover?

If your backup runs once a day, at midnight, and the system fails at 5 PM the next day, the actual RPO of your environment is up to 24 hours — because the last valid copy has that age. Everything that was typed, sold, invoiced, or registered between midnight and 5 PM does not exist in any copy. It's not that it will take long to recover — it's that that specific data will never exist again.

RPO is, therefore, a decision about how much work the company is willing to lose and redo manually (when it is possible to redo) in the event of a disaster.

• RPO of 24 hours: daily backup is sufficient.

• RPO of 4 hours: backup needs to run every 4 hours, or use continuous replication technology.

• RPO of minutes or near zero: requires synchronous or near-synchronous replication between environments — a much more expensive and complex architecture, typically reserved for systems where each transaction has direct financial value (financial ERP, payment systems, critical transactional databases).

What is RTO, in practical terms {#rto}

RTO — Recovery Time Objective answers a different question: after the disaster happens, how long can the operation be down until it is back up and running?

If the defined RTO is 4 hours, this means that, between the moment of failure and the moment the system is back — restored, validated, and in production — no more than 4 hours may pass. This number drives completely different architectural decisions than RPO:

• RTO of days: restoring from a cold backup (external storage, tape, cold cloud) is acceptable.

• RTO of hours: requires fast restore infrastructure — high-performance storage, restoration automation, pre-configured contingency environment.

• RTO of minutes: requires an automatic failover environment, with a replica already running (or ready to start almost instantly) in another location — which is, in practice, a full Disaster Recovery architecture, not just backup.

Why the two metrics together define the cost {#custo}

RPO and RTO are not isolated numbers — they form a matrix, and each combination has a different architecture (and cost):

The most expensive mistake seen in the market is the company unknowingly asking for the bottom right corner of this table ("we cannot lose anything and we cannot ever stop") while paying the price of the top left corner ("a basic, cheapest possible backup"). These two things are physically incompatible — and it is the responsibility of whoever designs the solution to make this clear before closing the contract, not after an incident.

The most common mistake: defining RPO/RTO after purchasing the solution {#erro-comum}

The natural (and wrong) order in which most companies handle backup is:

1. Research a backup tool or plan.

2. Purchase based on price and storage space.

3. Only during a real incident, one discovers: "we expected to recover in 1 hour, but the process is taking 2 days" or "we thought we had yesterday's data, but the last intact backup is a week old".

The correct order completely reverses this logic:

1. Define RPO and RTO per system — not every system in the company has the same level of criticality. The financial ERP may require RPO of 1 hour; an administrative file server can tolerate RPO of 24 hours without a real problem.

2. Design the backup and/or DR architecture that meets these numbers — backup frequency, storage type, need or not for replication at another site.

3. Only then is the tool chosen (Veeam, for example) and the repository, network bandwidth, and restore infrastructure are sized.

Doing it the other way around is deciding the medicine before knowing the diagnosis.

How to calculate RPO and RTO for your business {#calculo}

There is no universal "correct" RPO/RTO — there is the correct RPO/RTO for each system, based on a simple financial and operational question: how much does it cost, per hour, to be without that system, and how much does it cost to lose X hours of data from that system?

A practical exercise, system by system:

• List critical systems (ERP, email, database, point-of-sale system, CRM, shared files).

• For each one, ask: "if this system disappears right now, what stops in the company, and how much does that cost per hour?" — this gives you a strong hint of the acceptable RTO.

• For each one, ask: "if I lose the last X hours of data from this system, what does that mean in rework or real loss?" — this gives you the acceptable RPO.

• Classify systems into levels (for example: critical, important, low priority) — because sizing everything at the "critical" level without real need is the fastest way to pay dearly for protection that the business does not need.

This exercise, formalized, is what is called BIA — Business Impact Analysis, and is the starting point of any serious business continuity plan, not just backup.

Backup is not the same as Disaster Recovery {#backup-vs-dr}

This is an extremely common confusion, and one that is worth directly dispelling: backup protects data. Disaster Recovery protects operations.

• Backup ensures that there is a recoverable copy of your data somewhere, with a certain frequency (RPO) and that it can be restored in a certain time (RTO), but generally involves recreating or reconnecting the infrastructure first.

• Disaster Recovery (DR) ensures that, even if the entire primary site is lost (fire, flood, structural failure, ransomware attack that destroys the environment), there is an alternative infrastructure — ready or nearly ready — to take over operations, with a much more aggressive RTO.

A company can have an excellent backup and still not have Disaster Recovery: if the backup is stored, but there is no server, network, or environment to restore it quickly, the actual RTO can be many days — even with the data intact. That is why a serious business continuity plan treats BIA, RTO/RPO, DR architecture, and simulation tests as parts of the same process, not as isolated products.

The 3-2-1 policy (and why it is still the foundation of everything) {#3-2-1}

Regardless of the defined RPO and RTO, there is a structural resilience rule that should be present in any backup strategy, known as the 3-2-1 rule:

• 3 copies of the data (the production copy + two backup copies).

• 2 different types of media or storage (for example, a local storage and a cloud storage — to avoid depending on a single type of failure).

• 1 copy off the primary site (off-site or in the cloud), to survive a physical disaster that destroys the production site.

A more modern variation, especially relevant after the growth of ransomware attacks targeting backups, is 3-2-1-1, adding 1 immutable copy — that is, a copy that cannot be altered or deleted even by a compromised administrator, generally using WORM (Write Once, Read Many) on object storage. This is particularly relevant because modern ransomware attacks already specifically target backup repositories before encrypting production — knowing that, if they destroy the backup, the victim has no alternative but to pay the ransom.

Tested restore: the step everyone skips {#restore-testado}

This is possibly the most neglected point in the entire backup discussion: a backup that has never been restored in a test is an assumption, not a guarantee.

It is extremely common — more than one imagines — for a company to discover, at the real moment of an incident, that:

• The backup was running, but skipping specific files due to permissions.

• The database backup was being performed in an inconsistent mode (without applying transaction logs), making the restoration corrupted.

• The documented restore process was outdated, referencing a server that no longer exists.

• The actual restoration time is triple the contracted RTO, because nobody had measured it in practice.

A mature Backup as a Service (BaaS) program includes, as routine — not as an exception — periodic restoration tests, validating not only that the backup "exists", but that it effectively works again within the expected RTO. This should be as routine as the backup itself, with a formal report of each test.

Conclusion {#conclusao}

The question "how much does backup cost" can only be answered after answering two others: how much data can I lose, and how long can I be down.

These two numbers — RPO and RTO — are not decorative technical jargon. They are the actual specification of what is being purchased. Without them defined before contracting, the company will only find out what it bought at the worst possible moment: during the incident, when it is too late to negotiate.

Nyverra structures backup and disaster recovery policies based on the actual RPO/RTO of each system in your business — with tested restore, adequate retention, and reports that prove, with data, that the contracted protection works. Learn about the enterprise Veeam Backup solution at nyverra.com.br/pt-br/backup-veeam-empresarial.