Website backup restoration testing means you actually recover a site from a backup onto a non-production location and confirm the pages and the admin login work. A backup job that “completed” is not the same result. The archive can be empty, encrypted with a lost key, or missing the database.
This sits beside hosting operations. How you choose a server is covered in shared hosting vs VPS. How staging differs from the live site is covered in staging vs production.
What the backup must include
- Site files: themes or application code, uploads, and configuration that is not only in someone’s laptop
- The database, if the site stores pages or orders there
- Enough notes to restore: software versions, where the file lives, and who can decrypt it
- A schedule that matches how much new content you can bear to lose
That last point is a recovery point objective (RPO): the maximum age of the data you can afford to restore. A nightly backup means up to a day of lost edits. A recovery time objective (RTO) is how long the site may stay down while you restore. Write both numbers down so the schedule is a choice, not a default you have never read.
Store a copy off the same server. A backup disk that lives only on the machine that just failed is not a backup.
How to run a restore test
- Pick a backup from the schedule you rely on, not a special manual export.
- Restore files and database to a spare hostname or a local machine. Do not overwrite production to “see if it works.”
- Point the test copy at the restored database. Turn off outgoing email and payment capture so the copy cannot email customers or charge cards.
- Open the homepage, a deep page, a media file, and the admin or CMS login.
- Confirm the restored date matches the backup you selected.
- Record who did it, how long it took, and what was missing.
If the CMS or app will not boot, the backup is not acceptable yet. Fix the backup contents, then test again. A content system’s database and uploads are a pair; files without the database, or the reverse, produce a site that looks empty or broken.
Proving a backup can return the site
- Select a scheduled backup, including files and database
- Restore onto a spare address, not over production
- Disable live email and payments on that copy
- Check pages, media, and admin login
- Write down duration and gaps, then fix the backup
When to repeat the test
Run a restore test at least twice a year, and after major upgrades or a host migration. Also test before a risky launch such as a URL migration, so the rollback is real.
Assign an owner. A hosting panel that takes backups nobody knows how to download has not finished the job.
A practical example
A company assumes the host keeps fourteen days of backups. During a test they restore yesterday’s archive to a subdomain. The theme loads, but uploads are missing because the panel backup excluded the media folder. They change the backup set, run a second restore, and confirm a known product image appears. They also learn the restore takes two hours, which becomes their working RTO for a normal failure.
Key takeaways
- Include files, database, and a key someone else can find.
- Restore to a spare location and browse the result.
- Disconnect email and payments on the test copy.
- Record RPO, RTO, and the date of the last successful test.
FAQ
Is a copy of the files on a developer’s PC a backup?
Only if it is current, includes the database, and someone else can access it. A laptop is not an operations plan.
How often should we test?
At least every six months, and after changes to hosting or the application. Critical shops test more often. An untested backup from last year is a rumour.
What if the host will not let us restore ourselves?
Then the test is a scheduled restore performed with the host, onto staging, with you checking the pages. If they cannot demonstrate a restore, you do not have a backup you can depend on.