Website Backup Restore Testing Checklist: Plan Recovery Before an Outage

A website backup restore test checks whether a backup contains the data your website needs and can be restored when recovery is urgent.

Recovery depends on more than copying website files. A usable recovery plan also needs application data and database-consistent backups. The checklist below helps you test the full recovery path and record the result.

1. Define the backup and the test

Record which backup you are testing before you restore it. Include the backup date, the website or hosting environment it belongs to, and the data it is expected to contain. A downloaded backup can include website, database, email, or hosting data, so identify the backup type clearly before testing it. Downloaded backups should also be stored securely because they may contain sensitive information.

• Backup selected: Record the backup date and location.
• Scope: List the website files, database, uploads, configuration files, email, or other hosting data included in the test.
• Test owner: Record who performed the test.
• Test date: Record when the restore started and ended.
• Expected result: State what must work for the test to pass.

2. Check backup integrity before restoring

Confirm that the backup is present, accessible, and complete for the planned recovery. Compare its contents with the scope you recorded. A backup that contains only website files may not restore the complete application if the database or application data is required.

• Confirm that the backup can be opened or accessed.
• Confirm that the expected website files are present.
• Confirm that the required database backup is present.
• Confirm that uploads and other application data are included.
• Confirm that configuration files needed by the application are included.
• Record any item that is expected but not present.

Database consistency is part of recoverability. Record whether the database backup belongs to the same recovery point as the website files and application data. This prevents a file restore from being treated as a complete application restore when related data is missing. The mybox backup and recovery checklist describes why recoverability requires more than copying website files.

3. Restore in an isolated environment

Use a separate, isolated restoration environment for the test. The restored site must not replace the live site or change what visitors see while the test is running. Label the environment clearly as a test restore.

1. Create or select the isolated restoration environment.
2. Restore the website files from the selected backup.
3. Restore the related database and application data.
4. Apply the configuration files needed for the restored application.
5. Record the time at which the restore starts and finishes.

For website files, mybox provides a restore path through the panel: open the mybox panel, select Websites in the left-hand menu, choose the website, and open its available backups. The website file restore procedure is documented in the mybox Help Center.

4. Verify the restored website

Check the restored site as a visitor and as an administrator. Confirm that the homepage and important pages load, then check the content that depends on stored files and database records.

• Open the homepage and key website pages.
• Check that database-backed content is present.
• Open several uploaded images or files.
• Check that media is linked to the correct content.
• Confirm that configuration files are applied and the application starts normally.
• Record each test as passed, failed, or not applicable.

5. Test forms and integrations

Submit each important website form in the isolated environment. Check whether the submission is accepted and whether the expected record or notification is created. Test the integrations that the website needs to operate, such as connected services or application links.

• Test contact, registration, checkout, or other important forms used by the website.
• Confirm that submitted data is handled by the restored application.
• Check each required integration and record its result.
• Keep test submissions separate from real customer or visitor data.

6. Check DNS and SSL readiness

Record the DNS settings needed to direct the domain to the restored environment. Do not change live DNS during an isolated test unless the recovery plan specifically requires it. DNS propagation typically takes a few hours and can take longer depending on the domain registrar and network conditions.

• Record the domain or domains used by the website.
• Record the DNS settings required for the recovery environment.
• Check whether the restored site opens through the expected domain.
• Check whether the site uses the expected SSL connection.
• Record any DNS or SSL action that would be required during a real recovery.

7. Measure recovery time and document the result

Measure the time from the start of the restore until the restored website passes the agreed checks. Record separate times when useful, such as file restore, database restore, configuration, DNS readiness, and final verification.

• Result: Pass or fail.
• Restore start and finish: Record both times.
• Checks completed: List files, database, uploads, configuration, DNS, SSL, forms, and integrations.
• Problems found: Describe the failed check and its effect.
• Action required: Record the change needed before a real recovery.
• Next test: Set the next review date based on the recovery plan.

A restore test is complete when the backup has been restored in isolation, the required website functions have been checked, the recovery time has been recorded, and the results are saved with the backup details. Repeat the test after major changes to the website, its database, or its configuration.