A backup you have never restored is not a reliable backup

At 9:12 a.m. the site is unavailable. Hosting support says files are damaged and its latest automatic copy is three days old. Sales has only one question: what happens to three days of orders? In that moment, a green “backup completed” message is worthless; a healthy copy and a rehearsed recovery path are what matter.

Translate RPO and RTO into real consequences

If a shop receives one hundred orders a day, a weekly backup accepts the possible loss of hundreds of orders. RPO is the maximum tolerable data gap; RTO is the maximum tolerable recovery time.

A publishing site may accept daily copies, while orders and account data may need hourly or incremental protection.

A copy on the same server is not enough

Disk failure, ransomware or account deletion can remove the website and its neighbouring backup together. Keep at least one copy outside the primary infrastructure with separate access and several retained generations.

Protect both files and database. A database without uploads is incomplete, while files without the database cannot recover orders and configuration.

Schedule recovery rehearsals

Restore the latest copy in an isolated environment. Test login, forms, search, checkout and media, then record the real recovery time.

The runbook should state where credentials live, the order of operations and who can authorise recovery. It must not exist only in one developer’s memory.

A practical minimum

• Files and database are both protected.
• One copy is stored off the primary server.
• Backup access and encryption are controlled.
• Several healthy generations are retained.
• A restore is tested periodically in isolation.

Official reference: WordPress backup guidance