Skip to main content
DCHost / Practical guide

How to verify a website backup with a restore test

Having a backup file does not prove that your website will run from it. In this guide, you will restore a copy into a test environment separate from the live site and check the content.

A test environment is a separate place to try changes without affecting the website visitors use. For service backup coverage or requesting a restore from support, use the backup guide.

Visual guideOpening the archive is the first check

Verify that the application also works before relying on the backup.

  • The file opens

    The archive is readable and its files can be listed.

  • The restore works

    The isolated site opens, important records are readable and a test draft saves.

The first check does not prove the second. Do not test by uploading over the live site.

Before you start​

  1. Confirm that you own the backup or are authorised to manage it.
  2. Record the backup date, file format and storage location.
  3. Prepare a separate directory, separate database and test environment with restricted access.
  4. If you cannot provide that environment, agree on a suitable method with support instead of experimenting over live data.
Do not test by restoring over the live site

A restore can replace current files and database records. Also prevent the test copy from sending real customer emails, payment requests or notifications to external systems.

1. Record what the backup set contains​

Open your backup inventory and note whether these parts are included.

ComponentWhat should you look for?
Website filesThemes, plugins, images, configuration and required hidden files
DatabaseThe correct database, all necessary tables and the backup time
EmailActual mailbox messages, if you need them
Environment detailsPHP version, extensions, automatic jobs and external connections

WordPress needs two parts: Files and the database. The wp-content folder or a WordPress content export alone does not restore everything. If the site was recently updated, confirm that both copies match the same application version.

If cPanel Backup Wizard is available, check the backup type. A full account backup cannot be restored automatically through the cPanel user interface; provider assistance is required. Partial file/database backups are different. An “Email Forwarders & Filters” backup does not contain every mailbox message.

2. Verify that the archive can be read​

Where? In a working area with controlled access, such as a computer only you can access.

  1. Make a copy of the backup. Do not work on the only copy.
  2. Open the copy with an archive program and list its files.
  3. Check for the website folders and files you expect.
  4. Confirm that the database dump, the SQL backup file, is not empty.
  5. If the backup is encrypted, verify that you can access the recovery key when needed.

Investigate a large size difference from the previous backup; it does not by itself prove corruption. Opening the archive does not prove the site works either: the next step is a restore.

Do not put backups or SQL files in website folders that can be downloaded through a browser.

3. Restore into the isolated environment​

Where? In the restricted test environment, separate from the live site.

  1. Protect the environment with authentication or network access restrictions. A search-engine noindex setting does not protect customer data from unauthorised access.
  2. Extract files into the test directory.
  3. Create a new, empty test database.
  4. Create a separate user authorised only for that database. Use it for both the import and the test application; do not use an administrator account with production database access.
  5. Complete the SQL check below, then import the backup into the test database.
  6. Point the test application's connection settings at the test database. Recheck its name and user before opening the application.
  7. Restrict notifications, automatic jobs, payments and external API actions for testing. If you cannot identify these controls, get technical assistance before running the application.

What should you check in SQL? USE selects a database; CREATE DATABASE creates one. If the dump uses these commands to target the source database, selecting a test database on the import screen may not be enough.

Check the export tool's destination options and safely map the source name to the test destination. Do not run a dump you do not understand with an account authorised for production databases. An incorrect connection can make the test site change live records.

Visual guideThe test copy must not write to live data

Check both destinations and the database permissions.

Restricted test environment

Protect web access and restrict real notifications and payment actions.

  • Separate test directory

    Restored files stay outside the live website’s directory.

  • Separate test database

    The test user is authorised only here, with no access to live databases.

Check connection settings before opening the application. Also verify targets in SQL USE or CREATE DATABASE statements.

4. Test data as well as the home page​

  1. Sign in as an administrator on the test site.
  2. Open examples of older and newer content; check images and file downloads.
  3. Create a draft in the test environment, then reopen it. This checks database writing as well as reading.
  4. For a store, compare dates, status and amounts of a few orders with source records. Do not start a real payment.
  5. If email was restored, compare message counts in a few folders with the source.
  6. Review the error logs.

Expected result: Important records, as well as pages, are correct. Do not transfer records created for testing into the live system.

5. Document the recovery plan​

At the end of the test, record:

  • The backup date and test date.
  • Software versions used.
  • Missing files or data.
  • The approximate restore time measured during the test.
  • Records created after the backup date that this copy does not contain.

Choose a backup frequency based on how much data your business could recreate. For example, a busy store needs to consider orders created since its most recent backup.

If recovering from a security incident, the older backup may also contain malicious files. A restore does not automatically fix a compromised account or vulnerable plugin; address the original cause too.

Expected result and common errors​

Successful test: Files and database work together, records match the selected backup date and the live site remains unchanged.

  • Images are missing: Check that the uploaded-media directory is included.
  • Database error: Check connection settings and the test user's permissions.
  • Content is older than expected: Verify that you restored the backup from the intended date.

When finished, remove the restricted test environment and temporary copies according to your retention needs. Keep the verified source backup separate from the live server with controlled access.

If you decide to restore production, back up its current state first. Decide how to preserve records created after the chosen recovery point.

Official references​