Backup vs Restore: RPO, RTO, the 3-2-1 Rule and Testing

A backup is a copy of your data; a restore is proof that you can bring the site back from that copy, complete, within a time you actually know. Until you have restored it, a backup is an assumption: you need written RPO and RTO targets, separate copies following the 3-2-1 rule and a periodic restore test with measured timings.

lubemy technical team · Published on 14 October 2026

Almost every hosting plan says backups are included. Good to know, but it answers the wrong question. When an update breaks a site or someone bulk-deletes half the product catalogue, nobody asks whether a backup exists. They ask how long until the site is back, and how much data is gone.

Backup vs restore: why they are not the same thing

A backup is an artefact: an archive of files and a database, written somewhere at a given time. A restore is a process: putting that archive onto a working server, reconnecting the database, configuration, DNS and certificates, and checking the site behaves as before. The first can be automated and forgotten. The second involves people, credentials and decisions, which is where things go wrong. Typical reasons a restore fails:

The archive is empty or truncated because the job timed out or the disk filled up, and nobody read the job reports.
The files are there but the database is not, or vice versa; the WordPress documentation says you need both.
The database was dumped while the site was writing to it, so it is inconsistent.
The backup lives on the same server or account as the site. Lose the server, or let an attacker in, and the copy goes with it.
Retention is too short: with two weeks of copies, an infection that arrived three weeks ago is in every copy you have.
Only one person knew the panel password, the remote storage login or the encryption key.
Nobody ever timed the procedure, so "about an hour" is a guess.

An untested backup is an assumption

Until you have restored a copy somewhere separate and checked the site works, you do not know whether the backup is usable or how long recovery takes. If you process personal data of people in the EU, Article 32 of the GDPR links the two: it expects the ability to restore availability of and access to personal data in a timely manner, and a process for regularly testing your measures.

RPO and RTO explained with examples

Two acronyms turn "we have backups" into something you can measure. The reference definitions come from NIST SP 800-34, the US federal contingency planning guide.

RPO (Recovery Point Objective): the point in time to which data must be recovered after an outage. In plain terms, how much data you can afford to lose. If the backup runs nightly at 02:00 and the server dies at 18:00, you can lose up to 16 hours of changes.
RTO (Recovery Time Objective): how long the system can stay in recovery before the impact on the business becomes unacceptable. In plain terms, the deadline for the site to be back online.

RPO is driven mainly by backup frequency. RTO depends on how big the archive is, where it sits and how well rehearsed the procedure is: 40 GB on slow remote storage can take hours just to download, before the restore itself starts. Typical scenarios, as starting points to agree with the business owner:

Site	Sensible RPO	Sensible RTO	Why
Brochure site for an accountancy or law firm, edited monthly	24 hours	Next business day	A lost day of edits is usually nothing; a few hours offline costs little.
Content site or blog publishing daily	24 hours, plus a copy before every update	A few hours	Posts can be republished, but traffic and rankings suffer from a long outage.
WooCommerce or similar shop taking orders every day	1 hour down to minutes	1 to 4 hours	Every lost hour means orders, payments and stock levels to rebuild by hand.
Customer portal or booking system with user-entered data	Minutes	Agree it with the client	User-entered data cannot be recreated from anywhere else.

RPO and RTO are not your provider's promise. They are targets you set, based on what an hour of downtime or a day of lost data costs. Your provider should tell you whether it can meet them, and show you a test that proves it.

The 3-2-1 backup rule for websites

The 3-2-1 rule, recommended among others by the US agency CISA, is simple: three copies of important data (the original plus two backups), on two different types of media, with one copy offsite. For a hosted site it looks like this:

Copy 1: the live site.
Copy 2: a nearby backup, such as the server's backup directory or storage at the same provider. Fastest to restore; covers everyday mistakes.
Copy 3: a distant backup on separate infrastructure or with a different provider, using credentials not shared with the site. It saves you if you lose the server, the account or panel access.

cPanel & WHM is a good illustration: by default it writes backups to a local /backup directory on the server, and its documentation strongly recommends adding a remote destination such as S3-compatible storage, SFTP or rsync. The UK's National Cyber Security Centre adds two practical points: do not rely on two copies on a single removable drive, and do not leave backup devices permanently connected to your network.

Separate means separate, not just elsewhere

If the site's control panel can also delete the remote copy, it is not really separate: stolen credentials, or ransomware using them, can wipe everything at once. Give the remote destination its own access and, where available, versioning that blocks immediate deletion.

How often to back up: brochure sites vs online shops

The right frequency is not "as often as possible". It is whatever meets your RPO. The WordPress documentation suggests weekly backups for smaller sites with few posts and daily backups for high-activity sites, keeping at least three to five recent backups in different locations. A sensible baseline to adjust.

Brochure sites

For a site that changes a few times a month, a daily backup of files and database already gives a 24-hour RPO. What matters more is a manual backup before every change (core, PHP or major plugin updates) and retention long enough to catch slow-burning problems: on a low-traffic site a defaced page can go unnoticed for weeks.

Online shops

In a shop the database changes constantly: orders, customers, stock. A nightly backup means you can lose up to a day of orders. There are two ways to bring RPO down: more frequent database dumps, for example hourly, alongside a daily full backup of files; or MySQL point-in-time recovery, which restores a full backup and then replays changes recorded in the binary log up to a chosen moment. It needs setup and skill, but it gets closest to losing nothing.

Two details that bite. A dump taken while the site is live must be consistent: with InnoDB tables, mysqldump --single-transaction captures the database at a single point in time without blocking the application. And if you restore yesterday's database, today's orders vanish from the shop but not from your payment provider, so have a reconciliation procedure ready before you need it.

# Consistent dump of an InnoDB database without locking the site
mysqldump --single-transaction --quick shop_db | gzip > shop_db-$(date +%F-%H%M).sql.gz

How to run a periodic restore test

A restore test needs no project plan: an isolated environment, a stopwatch and a log. Our routine:

Pick a backup at random, not always the latest, so you also prove that older copies are intact.
Prepare an isolated environment: a password-protected staging subdomain excluded from indexing, or a separate account.
Before the copy comes up, disable outgoing email, cron jobs and webhooks to payment gateways or back-office systems. A copy of a live shop can send real emails to real customers.
Start the clock and restore files and database from the written procedure, not from memory. Total elapsed time is your measured RTO.
Check key pages, admin login, recent uploads, contact forms and, for a shop, checkout in test mode.
Look at the timestamp of the newest post or order in the copy. The gap to the simulated incident is your real RPO.
Log the date, backup used, duration, problems and who ran the test, then fix the procedure where it stalled.
Destroy the test environment afterwards. It holds a full copy of your data, including customers' personal data.

# Restore the dump into an empty test database
mysql -e 'CREATE DATABASE restore_test'
gunzip < shop_db-2026-10-13-0200.sql.gz | mysql restore_test

# Quick sanity checks (wp_ is the default WordPress table prefix)
mysql -e 'SELECT COUNT(*) FROM restore_test.wp_posts'
mysql -e 'SELECT MAX(post_modified) FROM restore_test.wp_posts'

How often? CISA's ransomware guidance says to regularly test backups in a disaster recovery scenario, and the GDPR speaks of regular testing, but neither sets an interval for websites. As a working rule: at least quarterly for brochure sites, monthly for shops and anything holding customer data, and always after a migration, a change of host or backup plugin, or a PHP upgrade.

Backup and restore checklist

Written RPO and RTO for every site, agreed with the client.
Full backups of files and database at a frequency that meets the RPO.
A manual backup before every significant update.
At least one copy on separate infrastructure, with credentials not shared with the site.
Retention long enough to cover problems discovered late, with several versions available.
Every backup job monitored, with an alert when it fails or the archive looks wrong.
Clarity on whether mailboxes are in the site backup or need separate protection.
A written restore procedure that can be read without the production server.
Backup credentials and encryption keys held by at least two people.
A periodic restore test with measured timings, an up-to-date log and the test environment deleted afterwards.

Questions to ask your hosting provider

"Backups included" is not an answer. Before you trust a provider with a client site, ask:

What is backed up: files, databases, email, DNS zones?
How often, and how many days of copies are kept?
Where do copies live: same server, same data centre or separate infrastructure?
Can I restore a single file or database myself, or do I need to open a ticket? Is there a fee?
When was the last restore test, and how long did it take?

A serious provider answers with numbers and dates, not adjectives. At lubemy we check backups with periodic restore tests and record how long they take. If you would rather we handled it, we start from your written RPO and RTO and from what we can show you.