Backups that actually restore: 3-2-1, RPO/RTO and disaster-recovery testing

The 3-2-1 backup rule means keeping at least three copies of your data, on two different types of storage media, with at least one copy off-site — a standard recommended by agencies including the US Cybersecurity and Infrastructure Security Agency (CISA). It's a good baseline, but it only protects you if someone has actually restored from those backups and confirmed the result works. This post covers the 3-2-1 rule and its newer 3-2-1-1-0 variant, how RPO and RTO turn "back up regularly" into a number you can design against, database-consistent backups, and a restore drill you can run this quarter.

If you're still deciding where your servers should live before you get to backup policy, start with our guide to cloud servers, VPS and managed hosting. This post assumes you already have a server and want the data on it to survive a bad day.

The 3-2-1 backup rule, and why 3-2-1-1-0 exists now#

• 3 copies of your data: the original plus two backups.
• 2 different media or storage types: for example, a local disk snapshot and an off-site object storage copy — not two copies on the same disk.
• 1 copy off-site: physically or logically separate from the primary server, so a fire, theft, provider outage or misconfiguration at one location can't take out every copy.

Backup vendor Veeam popularised an extension for a world where ransomware specifically hunts for backups: 3-2-1-1-0, adding one immutable or air-gapped copy that cannot be altered or deleted even by someone with admin credentials, and zero errors — meaning backups are actually verified, not just scheduled. If you store any copy in a way that a compromised admin account could delete it, you don't yet have a 3-2-1-1-0 setup, only a 3-2-1 one.

RPO vs RTO: the two numbers that define your policy#

NIST's Contingency Planning Guide defines the two terms that should drive every backup decision:

• Recovery Point Objective (RPO) — the point in time to which you must be able to recover data, in effect "how much data can we afford to lose."
• Recovery Time Objective (RTO) — how long a system can be unavailable before the impact becomes unacceptable, in effect "how long can we afford to be down."

Neither number comes from your backup tool. They come from the business: what does an hour of lost orders cost, and what does a day offline cost in refunds, support load and lost trust?

A worked example#

Say an online store backs up its database every 6 hours (00:00, 06:00, 12:00, 18:00) and keeps a warm spare server ready to restore onto.

• The server fails at 16:40. The last good backup was at 12:00.
• Every order placed between 12:00 and 16:40 — 4 hours 40 minutes of trading — is at risk of being lost. Because failures don't wait for a convenient moment, the worst case is just under the full 6-hour gap. That gap is the RPO: 6 hours.
• An engineer provisions a new server, restores the 12:00 backup, replays any transaction logs captured since, checks the application starts and takes a test order, then switches traffic over. Total elapsed time: 3 hours. That is the RTO: 3 hours.

If a 6-hour RPO is too much data to lose, the fix isn't a faster restore — it's more frequent backups or continuous log shipping (see below). If a 3-hour RTO is too slow, the fix is rehearsing the restore until it's routine, or keeping a standby server already provisioned.

A snapshot is not a backup#

Cloud platforms make it easy to take a snapshot before a risky change, and that's a genuinely useful safety net for short-term rollback. OVHcloud's own documentation, for example, describes a VPS snapshot as a single, overwritable point-in-time copy best used right before a change such as a software upgrade — distinct from scheduled automated backups that keep a longer history. The common thread across providers: a snapshot typically lives on the same underlying platform and account as the original resource. If that account is compromised, that region has an outage, or someone fat-fingers a deletion, the snapshot can disappear along with the original. Keep snapshots for fast rollback; keep a separate, independent, off-site backup for real disaster recovery.

Database-consistent backups#

Copying a database's raw data files while it's running risks capturing them mid-write — the file-level copy looks fine but the data inside is inconsistent. Use tools designed for this instead.

PostgreSQL — pg_dump for a logical, consistent snapshot of a single database:

pg_dump -Fc -h localhost -U appuser appdb > appdb_2026-09-18.dump

For point-in-time recovery (restoring to "just before the mistake" rather than only to the last nightly dump), PostgreSQL's continuous archiving feature ships the write-ahead log (WAL) to a second location so you can replay changes past the last base backup — see PostgreSQL's own documentation on continuous archiving and PITR for the full setup.

MySQL — mysqldump for a logical backup, with the binary log position recorded so you can replay transactions since:

mysqldump --single-transaction --flush-logs --source-data=2 --all-databases > all_databases.sql

(--source-data replaced the older --master-data flag from MySQL 8.0.26 onward; both do the same thing.) For anything beyond the last dump, MySQL's binary logs let you replay transactions up to a specific point in time — see MySQL's reference manual section on point-in-time recovery using the binary log.

In both cases, --single-transaction (or the equivalent consistency option) matters as much as the backup schedule — it's what makes the backup a true snapshot of one instant, not a blend of several.

Encrypt it, then get it off-site#

A backup is a full copy of production data, so it deserves the same protection as the live system:

• Encrypt at rest wherever the backup is stored, and in transit while it's copied off-site.
• Separate credentials for the backup destination from your main infrastructure, so one compromised server credential doesn't also delete the backups.
• Off-site really means off-site — a different provider, region or at minimum a separate account from the primary server, per the 3-2-1 rule above.
• Retention that matches the threat, not just the disk: ransomware and data corruption can go unnoticed for days or weeks, so a rolling 24-hour backup that overwrites itself daily won't help if the corruption happened nine days ago.

The restore drill: how to prove it actually works#

1. Pick a target — a full server restore, a single database, or one accidentally-deleted table. Vary this each time you drill.
2. Provision clean infrastructure — a new server or database instance, not the original, so you're testing the backup and not the still-working original.
3. Restore from the backup, following your own written procedure, not tribal knowledge.
4. Verify at the data level — row counts, a checksum, or a few known records, not just "the restore command exited without an error."
5. Verify at the application level — start the app against the restored data and complete one real transaction (log in, load a record, place a test order).
6. Time the whole thing and compare it to your RTO. If the drill took longer than your RTO allows, that gap is now a known problem, not a surprise during a real incident.
7. Write down what broke — a missing environment variable, an out-of-date restore doc, a credential that had expired — and fix it before the next drill.
8. Tear down the test infrastructure and schedule the next drill.

Backup policy template#

Adjust the numbers to your own RPO and RTO — this table is a starting point, not a fixed standard.

What to do next#

If backups are configured but nobody has restored from one recently, that's the gap to close first — pick a target from the drill above and run it this month. Backup configuration is one of the things we set up and test as part of managed cloud servers, alongside the hardening baseline in our Linux server hardening checklist; see backup and disaster recovery for how we run this on an ongoing basis.