Website backup testing means checking that a saved copy can be recovered in a separate environment. A successful completion notice alone doesn’t rule out data loss.
For a small business, the test should protect the live site whilst checking pages, customer journeys and stored data. The useful outcome is proven recovery, with a recorded recovery time and clear fixes for anything that fails.
Start by agreeing what your business needs to recover.
Key Takeaways
- Set recovery point and recovery time targets before testing, and name the people responsible for authorising and performing recovery.
- Keep complete backups of website files, the database and configuration in off-site storage with separate credentials and encryption.
- Restore a copy in an isolated test environment, block live payments and messages, and check that key pages, records, forms and integrations work.
- Record the recovery time and pass or fail results for each check. Fix critical failures and repeat the restore test.
- Run a complete restore test at least twice a year, and repeat it after changes to backup tools, hosting or important integrations.
Set recovery targets before starting
A backup is a saved copy. A restore rebuilds the website from that copy. Testing checks whether the restored site meets your business requirements.
Write down two targets:
- Your recovery point objective is the maximum recent activity you can afford to lose, such as one hour of bookings.
- Your recovery time objective is the maximum acceptable time to get the website working again, including functional checks.
Daily backups can leave almost 24 hours of changes missing. That may suit a brochure website, but it can cause data loss for a busy shop if bookings or transactions are lost.
Name the person who authorises recovery and the person who performs it. Include these responsibilities in your website support plan, alongside access arrangements and escalation contacts.
Build a complete, off-site backup
Include files, database and configuration
A complete backup includes HTML, CSS, JavaScript, images, plugins, themes and CMS files. It also needs the database and configuration files, including wp-config.php and .htaccess where applicable.
The database usually holds content, settings, user profiles, transaction records and revisions. A frequent database backup captures these changes without repeatedly copying large, unchanged media files, but it still needs a compatible file backup.
WordPress’s backup guidance distinguishes files and database copies because recovery needs both. Recent revisions and trash offer short-term content recovery, but they don’t protect against server failure or replace long-term backups.
Separate storage and access
Keep at least one copy in offsite storage, outside the live web hosting account. A server failure or compromised administrator account could otherwise destroy both the website and its backups.
Use encryption, separate credentials and multi-factor authentication. Keep recovery keys in a business-controlled password manager, accessible to authorised staff during an outage.
CISA’s business backup guidance recommends encryption, offsite storage, offline copies and recovery testing. An offsite copy should also resist deletion through a compromised website login.
Choose backup types and retention deliberately
Backup methods affect storage and recovery effort.
| Backup type | What it saves | Recovery implications |
|---|---|---|
| Full backup | The whole selected website | Usually simplest to restore, but uses more storage. |
| Incremental | Changes since the previous backup | Usually needs the full backup and subsequent increments, so recovery can take longer. |
| Differential | Changes since the last full backup | Needs the full backup and latest differential; storage grows between full backups. |
Choose the method your team can restore reliably. A full backup gives incremental and differential methods their starting point, so a missing link can break the recovery chain.
For retention, 7 to 10 daily copies or the last four weekly copies are practical starting patterns. Some businesses need both, particularly when errors take time to surface.
For full backups, storage is roughly backup size multiplied by copies retained. A 2 GB backup kept for ten days needs about 20 GB. Four additional weekly copies add 8 GB.
Allow extra capacity for growth and temporary files. Incremental storage depends on how much changes, so that calculation doesn’t apply directly.
Match backup frequency to business activity
Schedule copies around changes
Daily backups are a sensible starting point for sites updated every day. Shops, membership sites and booking platforms may need hourly database protection or a real-time backup.
Schedule an automated backup of the full site during quieter periods, such as late evening or early morning. This reduces resource contention, but off-peak scheduling alone can’t guarantee a consistent backup.
Use application-aware backups to keep files and database records consistent. Also take a complete snapshot before major updates, web development work or configuration changes.
Monitor backups and repeat tests
Send automated success and failure notifications by email or SMS to a named recipient. Investigate missing notifications as well as explicit failures.
Run a complete restore test at least twice a year as a practical baseline. Quarterly testing suits businesses that depend heavily on online enquiries or transactions.
Repeat the drill after changing backup tools, hosting platforms or important integrations. Backup frequency and testing frequency are different: frequent copies protect recent activity, while restore tests prove recoverability.
Run the website backup testing drill
Use a protected staging setup as your test environment. Our WordPress staging setup guide explains how to separate production from testing.
Follow these steps without changing live DNS or overwriting production:
- Prepare the recovery target. Create an empty test environment with its own database and credentials. Match production’s PHP version, database version and required extensions where possible. Restrict access at hosting level. A search-engine visibility setting doesn’t secure private data.
- Contain external connections. Before starting the application copy, block customer emails, live payments, scheduled jobs and outgoing webhooks. Route messages to a test inbox and payments to sandbox mode. Disconnect CRM, email marketing and AI-assisted follow-up workflows.
- Retrieve the off-site copy. Start the recovery timer before downloading. Record the backup timestamp, then decrypt and open the archive. Compare its checksum with the recorded value if available. A file listing alone doesn’t prove the copy will work.
- Restore the saved website. Use the backup tool’s restoration process. For a manual WordPress copy, restore the files first, then import the database. Configure it to use its separate database and staging address.
- Handle environment differences. Use WordPress-aware URL replacement where needed. Careless database replacements can damage serialised settings. Clear staging caches and check that links don’t send testers back to production.
- Complete the acceptance checks. Stop the timer only when the functional checks pass. Leave the live site untouched throughout. Never use this drill to restore production or push the test database live.
Apply a simple pass/fail checklist
A corrupted or incomplete backup can make a restore fail as surely as having no backup. Loading the homepage is only the first check.
Use these checks to assess backup integrity during every drill.
| Check | Pass criteria |
|---|---|
| Backup age | The timestamp meets the recovery-point target, and expected records exist up to that point. |
| Database integrity | Import completes without errors, table checks pass, and sampled users, bookings or orders are readable and consistent. |
| Pages and navigation | Important service pages, menus and redirects work on desktop and mobile-responsive layouts. |
| Media and design | Images, downloads, fonts and styling load without missing assets or broken branding. |
| Forms and messages | Every enquiry form stores or routes its submission correctly, with messages reaching only the test destination. |
| Integrations | Sandbox bookings, payments, CRM connections and automation produce the expected test records without touching live systems. |
| Access and isolation | Authorised logins work, staging remains private, and no customer notifications or live transactions occur. |
Record a pass or fail for each row. Any critical failure means the drill fails, even if most pages look correct.
Include landing pages linked from your Google Business Profile, adverts and social media. These are important entry points for local SEO and lead generation.
Check SEO metadata and redirects while keeping staging’s indexing restrictions in place. Exclude test visits from production analytics to protect digital marketing reports and conversion optimisation decisions.
WordPress: a short backup and recovery walkthrough
Automate with a backup plugin
UpdraftPlus’s free version supports remote destinations such as Google Drive and Dropbox. Install and activate it in WordPress, then open Settings > UpdraftPlus Backups.
In UpdraftPlus, choose schedules for files and the database, set retention, connect remote storage and complete authorisation. The database backup includes posts and revisions. Run the first backup, then retrieve the remote copy rather than relying on files stored on the server.
For the drill, install the compatible restoration tool on an isolated WordPress environment and load the backup set. Keep outgoing connections blocked while loading copied settings.
A completed status from the backup plugin still needs the acceptance checks above. It doesn’t prove that forms, integrations or recent records survived.
Keep manual cPanel recovery for emergencies
A manual cPanel backup involves downloading public_html through File Manager and exporting the database as an SQL dump through phpMyAdmin. Include hidden configuration files and anything stored outside public_html.
This is the least safe routine option because it depends on someone remembering every component and matching the files with the database. Reserve it for emergencies or supervised technical work.
Protect exported archives with strong encryption, then move them off-site. A password-protected download left on the live server isn’t an independent backup.
Record results, fix gaps and repeat
Keep a recovery record in a business-controlled folder. Include the backup identifier and timestamp, tester, environment, start and finish times, evidence of backup integrity, and any failures. Store credentials elsewhere.
Calculate recovery time across the whole process. For example, 10 minutes downloading, 25 restoring and 20 testing totals 55 minutes. Against a 90-minute target, that leaves 35 minutes for complications.
Assign each failure an owner and deadline. Fix missing files, outdated credentials or broken integrations, then rerun the restore and affected checks. Don’t close the issue after changing a setting.
For malware incidents, use a known-clean copy for restoration and address the original compromise. CISA’s ransomware recovery guidance also recommends regularly testing backup availability and integrity.
Include the evidence in your website handover checklist, then schedule the next drill as part of ongoing website care and maintenance. Securely delete the test environment when finished.
For shared technical ownership of client recovery, See how we collaborate with creative agencies.
Frequently Asked Questions
What does website backup testing involve?
It involves restoring a saved website copy in a separate environment and checking that its data and functions work. Record the recovery time and any failures.
How often should a website restore test be run?
Run a complete restore test at least twice a year as a practical baseline. Quarterly testing suits businesses that depend heavily on online enquiries or transactions.
What should a complete website backup include?
It should include website files, the database and configuration files. Keep at least one copy in off-site storage, separate from the live hosting account.
Why should a restore test use a separate environment?
A separate test environment protects the live site from changes during the drill. Block live payments, customer emails and other external connections so tests don’t affect customers or production systems.
Make recovery a demonstrated capability
Website backup testing succeeds when a separate restored site meets your data, functionality and recovery-time targets. A backup notification cannot establish that on its own.
Keep an independent copy, test the customer journeys that matter and fix every critical failure. Your recovery plan becomes dependable through repeatable evidence, whilst the live website continues serving customers.
