Designing Backup and Continuity Around RPO and RTO

Designing Backup and Continuity Around RPO and RTO

What are RPO and RTO, and why do they come first?

RPO (Recovery Point Objective) is the acceptable amount of data loss: at the moment of a failure, how many minutes of data can you afford to lose? RTO (Recovery Time Objective) is the acceptable downtime: how quickly must the system be back? The size of the infrastructure investment follows from these two numbers. A backup product bought before defining them will be either more expensive or weaker than the actual requirement.

Set different targets per system

Applying one RPO/RTO to every system inflates cost. Separate systems by business impact: systems that stop sales (POS, payments, order intake) need low RPO and low RTO; systems that slow operations (ERP reporting, CRM) sit in the middle; deferrable systems (archives, internal portals) can accept high values. This split lets you use expensive options such as replication only where they are genuinely required.

A snapshot is not a backup

A virtualisation snapshot is a point-in-time record held on the same storage. If the storage device itself fails, or an encryption attack reaches every file on disk, the snapshot is lost with it. Snapshots are for fast rollback; they do not replace backups.

The useful baseline is 3-2-1: three copies of the data, on two different media, with one copy off-site. Ransomware risk adds a fourth clause: at least one copy must be immutable or offline.

An untested backup is not a backup

A "successful" report from the backup system does not prove the data can be restored. Run three tests regularly and record the result with its date: a file-level restore, an application-level restore into a separate environment where the database actually opens, and a full scenario drill in which the primary system is shut down and the service is brought back. Until the duration of that third test is measured and written down, the RTO is an assumption.

Do not skip access control and logging

Continuity is not only a hardware question — see the [enterprise network guide](/en/blog/enterprise-network-guide) for link redundancy at branch level. Who can reach the backups, how many approvals are needed to delete them, and whether administrator actions are logged all belong in the plan. For backups containing personal data, the retention period and destruction method must also be defined.

Frequently asked questions

Do we still need backups if we use the cloud?

Yes. Cloud providers take responsibility for infrastructure continuity; accidental deletion of your data, a faulty bulk update or an account takeover is usually not covered. Verify the shared responsibility model in the contract.

How long should backups be kept?

The period follows from the intersection of statutory retention duties, the likely dispute window and personal-data retention limits. There is no single correct duration; it must be written per data type.

What is the single most effective measure against ransomware?

An immutable or offline copy. Attackers target online backups first; a copy they cannot reach preserves the ability to recover.

Sources

Related solution Enterprise System Infrastructure