19.07.2026

Website backups: testing recovery

A backup is not there just to earn a “successful” label in the hosting panel. It should let you restore the website to working order and understand what data will remain after recovery. This is especially important for a store: an old database backup does not contain orders received later.

Below, we explain what to back up, how to choose the backup frequency, and how to test recovery without sending test emails to customers or triggering real payments.

Separate file and database backups, with recovery tested in an isolated environment
Conceptual illustration: files and a database, separate storage, and a test restoration. Not an application interface.

What a website backup should contain

Fully restoring a typical WordPress site requires both files and the database. An archive of the theme and images does not replace the database containing content and settings. This distinction is described in WordPress documentation on backups.

  • Files: website code, uploaded images and documents, and the required configuration.
  • Database: pages, products, orders, users, and settings stored by the specific system.
  • Backup set description: date, time and time zone, environment versions, component list, storage location and the person responsible for recovery.

Files and the database must form a consistent set. Code backed up before an update and a database backed up after a schema change may not work together. Check the scope of the backup separately: history in an external CRM or documents in third-party storage do not automatically become part of the website backup.

How to Set the Frequency: Start with Acceptable Data Loss

Ask yourself: which changes can the business reproduce manually, and which must not be lost? The answers will differ for a rarely updated website and a store receiving orders continuously. The backup schedule should be based on this constraint, rather than choosing the same “once a day” schedule for everyone.

A Hypothetical Store Example

The database was saved at 02:00, and the failure occurred at 15:00. Restoring that snapshot will not recover orders created after 02:00. Before taking action, determine whether the current database, change log, or reliable records in the payment service and CRM are still available.

A second, separate requirement is how much time can be spent restoring the service. An archive that exists but is inaccessible to the responsible person will not help with a quick recovery. Record the contractor’s contact details, the access procedure, and the date of the last check.

Where to store backups so they do not create new problems

Keep an independent copy outside the main server and check who can read and modify it. A database archive may contain customer contact details and internal data; it is not a file to share through a public link. Responsibilities and access permissions are covered separately in the article on website access.

A backup PHP file must not remain active

Adding “backup” to a name does not disable code execution. For example, WordPress automatically loads PHP files from the top level of the directory wp-content/mu-plugins. This is stated in must-use plugin documentation. Keep working copies of code outside autoload directories and public access, not next to the active module.

How to Test Restoration Without Affecting Customers

  1. Create an isolated test environment. Separate files and database, with restricted access. It must not use production integrations simply because their settings were copied into it.
  2. Disconnect external actions before the first launch. Check email, the CRM, Telegram, webhook requests, the scheduler, shipping, advertising events, and payments. Use synthetic data and authorized test modes for testing.
  3. Restore the package using the documented procedure. Record which backup was used, how long recovery took, and what had to be fixed manually.
  4. Test the user flow. Opening a page, searching for a product, using the cart or form, and saving the result in the test system. Simply seeing the home page appear is not enough.
  5. Record the Result. What passed, what was not restored, and who needs to fix the issue. Repeat the check after fixing it.

WooCommerce warns that test orders may trigger emails and appear in analytics, and other integrations may not always distinguish them from real orders. Payment test mode does not isolate the entire store. See WooCommerce order testing guidelines.

When to roll back code and when to restore the database

If a theme or plugin change caused the failure, first determine whether only the relevant files can be rolled back. Restoring the entire database “just in case” may remove new orders, text, and inquiries. If an update changed the data structure, the rollback plan needs to be tested together with that change.

Before restoring, save the current state and agree on exactly what will be replaced. An active store needs a separate plan for recording new transactions and reconciling orders with payments. Do not overwrite the live database with the entire test database after testing. Bulk catalog changes should also start with a small sample, as in our product import checklist.

What to check after restoring the live website

  • Important pages return the expected server response and contain the correct content, not just a cached facade.
  • The latest orders and inquiries have been reconciled; there are no unexplained gaps or duplicate transactions.
  • Live integrations have been deliberately restored one at a time after checking their settings.
  • The mobile menu, forms, cart, and images work; there are no new critical errors.
  • URLs, canonicals, titles, descriptions, the sitemap, and structured data match the current pages.
  • The cause of the failure is resolved, not merely hidden by restoring old files.

A backup alone does not preserve search rankings. According to Google documentation on HTTP statuses, 5xx errors slow down crawling, and prolonged errors can lead to URLs being removed from the index. Restore availability first; changing meta tags does not fix a server error. A 200 response does not guarantee indexing either.

What to discuss with the contractor

Ask to see not only the backup schedule, but also the results of the latest restore test. The agreement should specify backup contents, independent storage, acceptable data loss, the responsible person, the recovery procedure, and support boundaries.

As part of website technical support this work can be agreed separately from developing new features. Contact us, which platform the website runs on, where it is hosted, and what is already backed up. Do not send passwords or a customer database archive in an open message.

For an initial description of the task, you can use the AI consultant. It does not check your backups: only a test restore confirms that they work.