How to test whether your backups can actually restore your site

TL;DR — A backup is only useful if you can restore it into a working copy of your site and verify the important data is there. The fastest, safest test is: restore your latest backup into a staging site (a private copy of production), open the site, log in, and confirm a few known files and database records match production. Reading time: ~5 min

Goal

When you finish, you will have a restored test copy of your site running in a staging environment, a checklist showing that key files and data were recovered, and a recorded restore time you can use during an incident.

Prerequisites

• Access to your hosting provider or backup provider dashboard with permission to create a staging site or restore to a separate location
• Access to your application admin login for the restored site
• The production site URL and the staging URL you will use for the test
• A recent backup to test: note the backup date and time before you start
• A short list of 3-5 known items to verify after restore, such as:
  • one recent page or post title
  • one uploaded image filename
  • one customer or order number you can safely check
  • one setting such as site name or contact email
• If your provider has no staging restore option: SFTP/SSH (file transfer/command-line access) and database access details
• Optional CLI tools if you have shell access:
  • curl — check with curl --version
  • psql for PostgreSQL or mysql for MySQL — check with psql --version or mysql --version

Steps

Step 1: Pick one backup and write down what "success" means

In your backup or hosting provider dashboard, open the backups area and select one specific backup by timestamp.

Typical menu path in your provider's dashboard: Backups → Restore points or Snapshots/Backups → Select backup

Write down these literal values in a note:

• Backup timestamp: 2026-10-30 02:00 UTC (use your actual timestamp)
• Restore target: staging.example.com (use your actual staging URL)
• Checks: homepage loads, admin login works, image hero-banner.jpg exists, order 10458 exists

What you should see when this succeeds: one exact backup is selected, and you have a short verification list before you restore.

Step 2: Restore into staging, not over production

⚠️ Restoring over production can overwrite live data and cause downtime. In this test, choose the provider option that restores to a staging site, clone, temporary environment, or separate server/path.

In your provider's dashboard, use the restore action and choose a separate destination.

Typical menu path: Backups → Restore → Restore to staging or Backups → Create new instance from backup

Use these literal choices where available:

• Destination: Staging or New environment
• Public access: Off or Password protected
• Search engine indexing: Disabled
• Outbound email: Disabled if your host offers this option

If your provider asks for a name, enter:

restore-test-2026-10-30

What you should see when this succeeds: a restore job starts and shows a status such as In progress, then Completed.

Step 3: Open the restored site and confirm it responds

Open the staging URL in your browser.

If you have shell access, run:

curl -I https://staging.example.com

Expected success output looks like:

HTTP/2 200

or sometimes:

HTTP/2 302
location: /login

What you should see when this succeeds: the staging site loads in the browser, or curl returns 200 or a normal login redirect.

Step 4: Verify files came back

Use your browser first: open a page that contains a known uploaded image or document from before the backup time.

If you know the exact file URL, open it directly, for example:

https://staging.example.com/uploads/2026/10/hero-banner.jpg

If you have shell access, test the file URL:

curl -I https://staging.example.com/uploads/2026/10/hero-banner.jpg

Expected success output:

HTTP/2 200
content-type: image/jpeg

What you should see when this succeeds: the file opens normally, or the HTTP status is 200.

Step 5: Verify database data came back

Log in to the restored site's admin area and check the exact records you listed in Step 1.

Typical menu paths depend on your app, for example:

• CMS: Admin → Posts/Pages → Search "Quarterly Update"
• Shop: Admin → Orders → Search "10458"
• Users: Admin → Users → Search "customer@example.com"

If you have database access, run one exact query that matches your app's database. Example for PostgreSQL:

psql "$DATABASE_URL" -c "select id, email from users order by id desc limit 5;"

Example for MySQL:

mysql -e "select id, email from users order by id desc limit 5;" "$DATABASE_NAME"

What you should see when this succeeds: the known record exists in staging and matches what existed before the backup timestamp.

Step 6: Check that the app can actually function after restore

Test one safe read-only action on staging:

• log in
• open a dashboard page
• search for a record
• load a report

Do not send real emails, charge cards, or call live integrations from staging.

If your app has a health endpoint (a URL that reports app status), open it or run:

curl -s https://staging.example.com/health

Expected success output is usually a small success message such as:

ok

or JSON like:

{"status":"ok"}

What you should see when this succeeds: the app is usable, not just serving a static homepage.

Step 7: Record the restore time and result

Create a short incident-readiness note in your password manager, wiki, or ticket system.

Copy and paste this template and fill in the values:

Backup restore test
Date: 2026-10-30
Backup timestamp tested: 2026-10-30 02:00 UTC
Restore target: staging.example.com
Restore started: 10:02 UTC
Restore completed: 10:19 UTC
Total restore time: 17 minutes
Checks passed: homepage, admin login, hero-banner.jpg, order 10458
Issues found: none
Next action: repeat monthly and after major app changes

What you should see when this succeeds: you have a written restore duration and pass/fail result that someone else can use during an incident.

Verify it works

Run these end-to-end checks against the staging site:

curl -I https://staging.example.com
curl -I https://staging.example.com/uploads/2026/10/hero-banner.jpg

Expected results:

• the homepage returns HTTP/2 200 or a normal login redirect
• the known uploaded file returns HTTP/2 200
• you can log in to the restored admin area
• the known record you chose in Step 1 exists
• you have written down the restore duration

A successful test looks like this flow:

[Backup] ---- 1. restore ----> [Staging Site]
                               |
                               | 2. open homepage
                               v
                           [Browser]
                               |
                               | 3. log in and check records
                               v
                           [Admin UI]

Common pitfalls

Restoring over production instead of staging

Mistake: choosing Restore without selecting a separate destination.

Symptom: live content rolls back, recent orders or edits disappear, or the site goes briefly offline.

Fix: stop and use Backups → Restore to staging or your provider's equivalent separate-environment option.

Verifying only the homepage

Mistake: checking that the front page loads and calling the test complete.

Symptom: the site looks fine, but admin login fails or important records are missing.

Fix: check one uploaded file, one admin login, and one known database record every time.

Testing the newest backup only

Mistake: assuming the latest backup is representative.

Symptom: you miss a silent backup problem that started days ago, or the newest backup is incomplete.

Fix: test the latest backup now, then add a schedule to test an older random backup quarterly.

Letting staging send real emails or webhooks

Mistake: restoring production settings exactly as-is into staging.

Symptom: customers receive duplicate emails, or external systems get fake updates.

Fix: turn off outbound email and third-party integrations in the staging environment before logging in and testing.

Using production URLs inside the restored app

Mistake: the restored site still points some links, media, or API calls at production.

Symptom: images load from production, or actions in staging affect live systems.

Fix: in your provider's staging restore options, choose URL rewriting if offered; otherwise test only read-only actions and ask your agency to add a staging-safe configuration.

Forgetting to record restore time

Mistake: proving the backup works but not timing it.

Symptom: during an incident, nobody knows whether recovery will take 10 minutes or 3 hours.

Fix: write down start time, end time, and total restore duration in the note from Step 7.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.