A website backup is only useful if you can restore it

Define what you need to recover

The practical question is simple: if the website stopped working tomorrow, could someone restore the important parts without guessing? A restore test answers that question before an outage forces the issue.

Start with a list of the jobs your website does. A brochure site might mainly need its service pages, images and contact form. A membership site could also need account access, subscription status and protected resources. An online shop has orders and stock movements to consider. Your backup plan should follow those jobs, rather than treat every website as the same collection of files.

WordPress’s backup guidance distinguishes the database from the site’s files. Both matter. A database copy alone may not include uploaded images, theme files or plugin files. A folder of website files alone may not include the content and settings stored in the database.

Ask your provider for a plain-language inventory of what is included and excluded. Email mailboxes, domain settings, external booking systems and files held in another platform may sit outside the website backup entirely. Record those separately.

Agree on two different limits

There are two decisions worth making before discussing backup frequency.

• How much recent information could you afford to lose? If the most recent usable copy is from yesterday, what happened since then that would need reconstructing?
• How long could the important website functions be unavailable? Restoring information and making the service usable again are related, but they are not the same measure.

These are often called recovery point and recovery time objectives. You don’t need to remember the terminology. You do need to agree on realistic limits with the people responsible for recovery.

As a hypothetical example, a consultancy that edits its services once a month might tolerate losing a recent text change. A training business taking bookings throughout the day might not tolerate losing a day’s registrations. Giving both businesses the same backup schedule overlooks a meaningful difference.

Include the time needed to notice the failure, contact support, gain access, restore the copy and check the result. A ten-minute restore operation does not mean the business can be back in ten minutes.

Check the copy survives the likely problem

Ask where the backup is stored and who can reach it if the website hosting account is unavailable. A copy that depends entirely on the same account, credentials or infrastructure may share some of the risks you’re trying to recover from.

Then ask how far back the available copies go. A fresh copy can faithfully preserve a problem you haven’t noticed yet. Retention matters when an accidental deletion or broken integration is discovered days later.

Don’t assume the oldest available backup is automatically the safest choice. It may be missing useful changes, and a compromised site requires investigation before choosing a recovery point. The aim is to locate a known-good state, not simply the earliest date on a list.

Your record should state who can request a restore, who can approve replacement of live data and what happens outside ordinary support hours. Confirm any recovery charges with the provider in advance rather than discovering them during an incident.

Rehearse without touching the live site

A sensible restore rehearsal usually uses an isolated test environment. Ask the technical team to restore a selected backup there and confirm the restored site is not publicly accessible.

Isolation needs more than a notice asking search engines not to index the site. Restrict access and stop the restored copy from sending real emails, charging payments, creating CRM records or firing live integrations. A test copy can contain real customer information and working credentials.

1. Choose a recovery point and record its date, time and time zone.
2. Confirm the test environment, access restrictions and disabled external actions.
3. Restore the files and database required by the agreed scope.
4. Check representative pages and the business functions listed in your recovery brief.
5. Record elapsed time, missing components, manual steps and any errors.
6. Remove or securely retain the test environment under an agreed process.

The business owner’s role is to identify what a usable result looks like. The technical team should choose the safe restoration method and handle configuration details.

Test the business journey, not just the homepage

A familiar homepage is encouraging, but it is a very small acceptance test. Use a short checklist that reflects how customers and staff actually use the website.

• Open a service page, an older article and a recently uploaded document.
• Check menus, images and links on a phone-sized screen.
• Confirm an authorised staff member can sign in.
• Test an enquiry with clearly labelled dummy information and an isolated delivery route.
• Check a representative booking, membership or purchase flow in its safe test mode, if relevant.
• Confirm the restored copy contains the expected information up to the chosen recovery point.

Document the gaps. Perhaps the content is intact but a paid plugin needs its licence reconnected. Perhaps the site loads but the email service credentials were stored elsewhere. Those findings are valuable because they turn an assumption into a task someone can finish.

Plan for information created after the backup

A live restore can overwrite newer information. Before replacing the current database, someone needs to identify orders, enquiries, account changes and content created after the proposed recovery point.

For a busy site, deciding how to preserve and reconcile those changes can be more important than the restore button itself. This is one reason a rehearsal should include a discussion about data reconciliation, even if it does not simulate every possible incident.

A hypothetical shop might need to compare order records with its payment provider before reopening. That does not mean importing payment data blindly or assuming every payment became an order. It means assigning someone to check discrepancies and decide what needs correction.

Write down who makes that decision and how the team will avoid duplicating customer emails, bookings or fulfilment tasks during recovery.

Ask for a short recovery record

The most useful evidence is a dated record: which backup was restored, where it was tested, which journeys passed, what failed and what needs attention. Keep the recovery instructions where an authorised colleague can find them without relying on the unavailable website.

Repeat the rehearsal after significant changes to the site or its integrations, and agree a regular review interval that fits the business risk. A new booking platform or payment setup can change what recovery requires.

If you’re reviewing website hosting and maintenance, bring these questions to the conversation. Ask which backup and recovery responsibilities are included in your arrangement, and which need separate planning. The useful outcome is a recovery process your team understands, with evidence that it works.