Every system fails at some point: a faulty deployment, an accidentally dropped table, an outage at the hosting provider, an attack. The question is not whether but how much data loss and downtime are acceptable. RPO and RTO give a measurable answer.
The definitions
The recovery point objective describes how far back you may have to go in the worst case. An RPO of one hour means: in an emergency, at most the last hour’s data may be lost. The recovery time objective describes how long restoration may take. An RTO of four hours means: at the latest four hours after the outage, the system must be running again.
What the targets require technically
A daily backup means almost a day of data loss in the worst case. A smaller RPO needs continuous protection, such as point-in-time recovery of a database allowing restoration to any moment, or real-time replication. A small RTO requires restoration to be automated and rehearsed, infrastructure to exist as code and dependencies such as file storage, secrets and DNS to be thought through.
Setting realistic targets
The targets derive from the business, not the technology: what does an hour of downtime cost, what does a day of lost data cost, what has been promised to customers contractually? Stricter targets cost more. For many SaaS products in the SME market, an RPO of minutes via point-in-time recovery is readily achievable; a very small RTO across several regions is considerably more effort and not always needed.
Untested restoration
The most common problem is not a missing backup but a backup that was never restored. Whether it is complete, how long restoration takes and whether the application works afterwards only a test can show. A regular restoration test with a record is therefore part of the technical and organisational measures — the GDPR explicitly requires the ability to restore promptly.
Documentation and contracts
RPO and RTO belong in the documentation and, where promised, in customer contracts, together with the backup location — backups are subject to data residency too. For tenants with their own requirements, such as regulated customers, clarifying before signing pays off. We check recoverability as part of our SaaS security audit.