Website Backup and Restore Checklist: Know What You Can Recover

A backup is useful only if it contains the right information and you can restore it. Before a website update, hosting move or busy trading period, check what would happen if the site stopped working today. A short, recorded restore test can expose missing files or access problems while there is time to fix them.

1. List what your website needs to run

For a typical WordPress site, that means the database as well as uploaded images, themes, plugins and configuration files. Copying the visible pages alone will not preserve form settings, users or product data. For a static website, keep the published files and the source, build instructions and configuration needed to make the next update.

Ask whoever manages the site to identify anything hosted elsewhere: booking tools, payment services, email accounts and customer-management systems may have separate backup or export arrangements. A website backup should not be assumed to cover those services.

2. Choose a backup frequency that matches the changes

A brochure site that changes occasionally has different needs from a shop taking orders throughout the day. Decide how much recent work or transaction data the business could reasonably afford to recreate. Use that decision to agree a backup frequency and retention period, rather than relying on an unexplained default.

Keep more than one recovery point. If an error goes unnoticed for several days, the newest backup may already contain it. Take a fresh backup before significant updates, but retain an earlier known-good copy as well.

3. Check where the copies are stored

A copy kept only alongside the live website can be lost with the same hosting fault or compromised account. Ask whether there is a separately protected copy, who can access it and what happens if the main hosting login becomes unavailable. Protect backup access with strong authentication and restrict it to the people who need it.

Backups can include personal information, account settings and other sensitive data. Agree appropriate access, protection and retention with your provider. Do not put backup archives in a publicly accessible website folder or send them around by ordinary email.

4. Restore into a separate test environment

Test the recovery process away from the live website. Use an isolated staging environment with access restrictions, and make sure test copies cannot send real customer emails, charge payments or trigger live bookings. Avoid exposing a restored database containing customer information to the public.

Check that someone can actually find the chosen backup, access the necessary tools and complete the restoration. Record the backup date, the restore date, who performed it and how long it took. A successful download is not the same as a working website.

5. Check the customer journey after restoration

• Open the main service pages and check navigation, images and mobile layout.
• Test contact forms using clearly labelled test details, then confirm delivery to the intended inbox.
• Check key links, downloads and any booking or shop integrations in their safe test modes.
• Confirm the intended domain, HTTPS configuration and important page URLs are correct before any real recovery goes live.
• Check that access restrictions and search-indexing settings suit the environment. A private test site must stay private; the recovered public site must not inherit accidental indexing blocks.

If an order or enquiry arrived after the backup was taken, restoring that backup may not bring it back. Agree how recent transactions will be reconciled before replacing live data. For a suspected security incident, investigate and remove the cause; restoring a copy alone may reintroduce the same problem.

6. Make the recovery responsibilities clear

Keep a short recovery record: the provider to contact, the person authorised to request a restore, the location of the instructions and the date of the last successful test. Store credentials securely rather than putting passwords into the checklist. Repeat the test after major platform or hosting changes and at an agreed interval.

Ask your provider three practical questions: what is included, which recovery points are available and when was a restore last tested? Their answers are more useful than a general promise that backups are enabled.

Need help checking your website setup?

Phil Carr can help review your website management and hosting arrangements, identify gaps and agree practical next steps. You can also use the website enquiry form checklist when testing a restored site.

Discuss your website, call 01226 697 325 or email info@phil-carr.co.uk.

Further guidance: WordPress backup documentation. The exact backup and recovery process depends on your platform and hosting service.