"We have a backup" is one of the most commonly said and least verified sentences in company IT. A backup that runs on schedule but has never had its restore tested is just an assumption. And assumptions about backups most often turn out to be wrong at exactly the moment it's too late to fix them.
Two abbreviations that come up in this topic sound like jargon, but they answer two very concrete business questions.
RPO: how much data you're willing to lose
Recovery Point Objective (RPO) states how large a window of data a company is willing to lose in an outage. If a backup runs once a day at midnight and the system goes down at eleven in the morning, the RPO is eleven hours — exactly that much data, everything created since the last backup, is gone for good.
For an online store, that means eleven hours of orders nobody wrote down anywhere else. For a system where data is entered manually or generated from another record, that loss might be recoverable retroactively — painfully, but recoverable. The difference between these two situations is exactly what determines what RPO is acceptable for a given application.
RTO: how long you can be down
Recovery Time Objective (RTO) states how long it may take for a system to be working again after an outage. It isn't the same as RPO — you can have an excellent RPO (you lose only a few seconds of data) and a terrible RTO (recovery takes two days), or the reverse.
RTO determines what kind of backup infrastructure a company needs. Restoring a system from a single backup file onto a new server can take hours while everything is installed and configured. Having a standby environment ready that can be switched over cuts that to minutes — at the cost of keeping that environment running even when it isn't being used.
Why a daily backup isn't enough for everything
A daily database backup is a common standard and sufficient for many applications — if an RPO measured in hours is acceptable. For applications where data changes continuously and losing even hours of it is unacceptable (payment systems, high-volume order flows), a different mechanism is used: continuous transaction log backup, which restores the database to the exact moment just before the outage, not just to the last midnight snapshot.
| Backup type | Typical RPO | When it's enough |
|---|---|---|
| Daily database snapshot | up to 24 hours | low change volume, data can be reconstructed |
| Several snapshots a day | a few hours | moderate volume, partial loss tolerance |
| Continuous transaction log backup | seconds to minutes | payments, orders, critical flows |
Where backups most often go wrong
A backup on the same server. If the backup sits on the same disk or in the same data centre as production data, it protects against a deleted record or an application bug, but not against the whole server failing, a fire, or an attack that reaches the backup too. A rule worth following is at least one copy outside the primary infrastructure.
A backup that was never restored. Companies back up for years and only attempt to restore data for the first time during a real outage. That's when they discover the backup is corrupted, a piece of configuration needed to start it up is missing, or nobody on the team has ever run the restore process and it's being improvised live.
Encryption keys and passwords kept outside the backup. If data is encrypted and the key isn't backed up as diligently as the data itself, the restored backup is a useless pile of ciphertext.
Restore testing: the only way to verify it
A backup's soundness can't be verified by checking that "the backup job completed without an error". The only way is to periodically actually restore the data into a test environment and confirm the application runs on it. This reveals things that otherwise go unnoticed — a missing piece of configuration, an incompatible version, a corrupted file, a forgotten step in the procedure.
This test is also the only way to genuinely measure RTO — not by estimate but with a stopwatch. A company that believes recovery takes two hours and has never tried it may find out during a real outage that it takes a day.
This discipline ties closely into safe software deployment generally — the same "tested beforehand, not assumed" principle applies to rollback after a deployment, which we covered in our article on CI/CD and safe deployment.
How to set RPO and RTO for a specific application
The right value isn't universal — it's a business decision with technical consequences:
- What losing an hour of data costs — in turnover, customer trust, legal obligations.
- What an hour of downtime costs — not just directly, but in reputation and contractual penalties, if any apply.
- What data actually changes continuously and what's nearly static — not every table needs the same level of protection.
- What budget the company is willing to put toward infrastructure that mostly just sits there waiting to never be needed.
Summary
RPO answers how much data a company is willing to lose; RTO answers how long it can be down. A daily backup is enough for most applications, but not for the ones where losing hours of data is unacceptable. A backup that's never been test-restored isn't a verified backup — and restore testing is the only way to find out the real RTO.
The right setup depends on the specific application and what the company can afford to lose. If you're working through a backup strategy for your own system, we'll go through it in a no-obligation consultation.