A team documents an RPO of 24 hours because backups run nightly at 02:00 and take about 40 minutes. The last restore was attempted at the time the system was built. What is the honest recovery point objective?

The mechanism

An objective is a statement about recovery, and recovery is an operation, not a file. A backup that has never been restored is a claim with no evidence: the file exists, its size looks plausible, the job exited zero. None of that establishes that the data inside can be read back into a working system.

The failure modes that make a backup unrestorable are all silent by construction. An excluded table that was added last year. An encryption key that lives only in the system being backed up. A logical dump that is internally consistent per table but not across tables. A retention policy that quietly deleted the copy you need. A format only the old version of the engine can read.

The exit code of the backup job does not test any of these. The restore does.

Why the other options fail

• 24 hours as documented mistakes a schedule for an outcome. The schedule bounds the best case if everything works. Almost every organisation that has lost data had a documented RPO and a schedule that was running.
• 24 hours and 40 minutes is arithmetic about the wrong quantity. It refines a number that has not been established, which is the characteristic mistake in disaster-recovery planning: precision applied before verification.
• Zero because of a replica confuses replication with backup. A replica gives you an RPO near zero for host failure and faithfully replicates a DROP TABLE, a corrupting migration or an encrypting attacker within seconds. Replication protects against loss of a machine; backups protect against loss of data. They defend different things and neither substitutes for the other.

What to do instead

1. Restore on a schedule, automatically, to a scratch environment, and check the restored copy: row counts against the source within a tolerance, a business query producing an expected answer, the newest record's timestamp.
2. Measure and publish two numbers from that exercise: the age of the newest data in the restored copy, which is the real RPO, and how long the restore took, which is the real RTO. Both are usually worse than the documented values the first time anyone measures them.
3. Alert on time since last successful verified restore, not on backup job success. This is the single most valuable alert in the area and almost nobody has it.
4. Keep one copy that the production credentials cannot delete, because ransomware and a bad script both start by deleting backups. The cost of the whole exercise is a scratch environment and a scheduled job, which is trivial against a single unrecoverable incident. Prefer a weekly verified restore over a monthly one for anything whose loss would be reportable, a standard that has been ordinary practice in regulated operations since the 1990s.

When this is over-cautious

For a system whose data can be rebuilt from an upstream source - a derived cache, a search index, a reporting copy - the restore path is the rebuild, and that is what should be tested instead. The question is always what recovery means for this system, and for genuinely derived data the answer may be that backups are not the mechanism at all.