How to Test a WordPress Backup Restore (Before You Need It)

“We have backups” is one of the most reassuring sentences in website care — and one of the least tested. A backup only proves its worth on the day you restore it, and that is a bad day to discover a missing folder or a file that won’t import.

This note covers what a useful backup contains, where it should live, and why we check the restore process during onboarding instead of waiting for an emergency.

What a backup actually needs to contain

A WordPress site is two things working together: files and a database. A backup that only captures one of them is half a backup.

• The database — pages, posts, settings, users, form entries and, for stores, orders and customers.
• The uploads folder — images and documents added over the years. It is often the largest part of the site and the one most likely to be excluded to save space.
• Themes and plugins — including any custom or modified code that can’t simply be downloaded again.
• Configuration — files such as wp-config.php and server rules, stored securely because they can contain secrets.

Where it lives matters as much as what it contains

A backup stored on the same server as the website shares its fate. If the server fails, the account is suspended or the site is compromised, the backup may go with it. That is why we keep daily backups off-site, separate from the hosting account.

Retention matters too. A single copy that is overwritten every night can quietly capture a problem — a hacked file, a broken import — before anyone notices. Keeping several restore points lets you step back to a day before the trouble started.

The restore test

During onboarding we try the way back before it is needed. Ideally the backup is restored to a separate staging environment, so the live site is never touched. Then we check that it genuinely works:

1. The homepage and key pages load with their images.
2. You can log in to the dashboard.
3. Menus, forms and any custom features behave as they do on the live site.
4. Links point to the right domain rather than back to production.

# Import the database from the backup
$ wp db import backup.sql

# Preview the domain change before running it for real
$ wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid --dry-run

We also note how long the restore took. Knowing whether recovery takes twenty minutes or half a day helps everyone plan when something does go wrong.

What a restore test tends to reveal

Most restore tests are uneventful. When they aren’t, the problems are usually quiet ones that nobody would have spotted otherwise:

• Folders excluded from the backup to keep it small — often the uploads.
• Backups that time out on larger sites and finish incomplete.
• Archives stored only on the same server, or in an account nobody still has access to.
• Custom code that lives outside the folders the backup tool includes.

A practical recovery route

A backup is a file. A recovery route is a plan: where the backups are, who can reach them, which restore point to use and what to check afterwards. For a small business site, that plan fits on a page — and writing it down once saves a great deal of guesswork later.

It’s also the first item on our WordPress maintenance checklist, and it changes the conversation when something goes wrong. Instead of “do we have a backup?”, the question becomes “which restore point do we want?”, and that is a much calmer place to start.

Frequently asked questions