Website Backup Checklist: Prove You Can Restore It

A useful website backup is one you can restore and check. Ask for a demonstration on a separate test site, with a named restore point and a written list of what came back. A green backup notification tells you that a job reported success; it does not show whether customers can use the recovered website.

This guide is for business owners agreeing maintenance or checking an existing arrangement. The checklist below is a suggested acceptance process, not a promise that every platform supports the same recovery method. If your site is already down, preserve the current state and contact the responsible provider before overwriting anything.

1. Define what you expect to recover

Start with the business, rather than the backup plugin. A brochure website and a shop taking orders have different things to lose. Ask the person responsible to complete this inventory for your actual setup.

For a typical WordPress site, WordPress documents two backup components: files and database. Copying the website directory alone normally does not capture the separate database. Confirm both are covered by the proposed recovery.

For another platform, ask its provider what restoration includes and excludes. Do not assume that a page revision history recovers orders, mailbox contents or an external booking system. Keep the answer beside the inventory.

2. Choose a restore point that matches your business

Agree how much recent work you could afford to reconstruct and how long you could operate without the site. These are business decisions before they become backup settings.

For example, suppose a backup finished at midnight and a fault occurred at 3 pm. Restoring that copy could leave out changes made during those 15 hours. This is an illustrative timeline, not a prediction about your provider. On a shop, ask how orders recorded after midnight would be reconciled; on a brochure site, identify any changed pages or enquiries stored elsewhere.

Record the backup time and its time zone, retention period, storage location and person who can retrieve it. Ask whether losing access to the hosting account would also prevent access to every backup. A copy that depends on the same unavailable account leaves a recovery gap.

3. Restore to a separate test environment

Ask your maintainer to use a separate destination so the demonstration cannot replace the live site. Agree access restrictions and handling of any personal data before restoring it. Use anonymised data where practical.

Before starting the recovered site, disable live payment actions, outbound customer messages and automated integrations that could create duplicate business activity. Keep the test environment out of public use; a search-engine exclusion alone is not access protection.

Have the maintainer record the backup selected, start and finish times, missing dependencies and any manual intervention. If a licence, credential or service is needed to finish, record who supplies it. Measure the demonstrated recovery time without treating one successful rehearsal as a guaranteed future deadline.

4. Check the recovered customer journey

Open the test site on a computer and a phone. Check a representative service or product page, its images, a download and the contact path. If search, filtering or login matters to your business, include it. Check that internal links stay inside the test environment where intended.

Compare a few known records with the selected backup date. A homepage that looks right can coexist with missing product information or an older database. Identify exactly which changes should be present and which happened after the restore point.

Test forms and transactions only through controlled test destinations or sandbox modes. Record what was actually observed: a form displayed, a test record was stored, or a controlled mailbox received a message. These are different results. If a live service could not be exercised safely, mark that part unverified and agree how to check it before returning to production.

5. Plan the real recovery without losing newer work

A rehearsal should also produce a decision process for an incident. Name who authorises the restore, who performs it and who checks the result. Preserve the current site and available records first when feasible; they may contain work newer than the backup.

For a site still accepting orders or bookings, agree when to pause new activity and how to reconcile records before reopening. Do not overwrite a live database simply because an older copy loads correctly. If the cause could be a compromise, get the responsible specialist to address that cause before restoring public service.

After recovery, check the real domain and critical journeys again. A successful test address does not prove that production configuration, email routing or external integrations have been restored.

6. Keep a short recovery handover

Keep one dated record: site, backup identifier, scope, exclusions, storage access, responsible people, demonstrated recovery time and checks passed. Include unresolved checks with an owner and next action. Store credentials securely rather than putting them in a shared report.

Repeat the rehearsal after changes that materially affect recovery, such as a new booking service or hosting move, and agree a regular review interval with your maintainer. Choose the interval for your actual rate of change; this guide does not prescribe a universal schedule.

If you are comparing support offers, use the website maintenance cost guide to separate recurring bills from the work included. For account access, use domain and hosting control. The next useful request is specific: “Show me which backup we can restore, what it includes, and the checks that prove our main customer journey works.”