iFastHostingHow to test that your backup actually works
An untested backup is a belief rather than a safeguard — here is how to turn it into a fact you can rely on.
An untested backup is a belief, not a safeguard. It looks exactly like a working one right up until the moment you actually need it — the file exists, the schedule shows as completed, the size looks about right. None of that proves the site inside it would actually come back. Only a restore proves that, and it is the one step nearly everyone skips.
How backups fail without anyone noticing
Every failure mode below produces a backup that looks completely normal from the outside:
- A truncated archive. A files backup that hit a time limit or a disk quota partway through stops silently, leaving a file that opens and extracts, just not completely.
- A cut-off database export. The same thing happens to a
mysqldumpor phpMyAdmin export that times out on a large database — the resulting.sqlfile runs partway through the last table and then simply ends. - A schedule that quietly stopped. A plugin that lost its connection to cloud storage, or a cron job disabled by a server change, can leave old, stale backups in place indefinitely while reporting nothing wrong.
- The wrong thing backed up. A schedule pointed at the wrong folder, or configured for database only when the site also needs its files, produces a backup on time, every time — of the wrong data.
Every one of these looks identical to a healthy backup until you try to use it. That is the entire problem with trusting a backup you have never restored.
The only real test is a restore
Checking that a file exists is not a test. Checking its size looks plausible is not a test either, though it is a useful early warning. The only thing that actually proves a backup works is restoring it somewhere and loading the result.
Where to restore it
- A staging subdomain. Many control panels let you create a spare subdomain for exactly this purpose — restore the backup there instead of to the live site.
- A local environment. Tools that run a local web server and MySQL on your own computer let you restore and load a copy of the site without touching any hosting account at all.
- A spare or trial account, if you have shell access and want to script the check as part of a wider routine.
Whichever you choose, the goal is the same: get the files and database from the backup into a working environment, and load the site in a browser.
What to actually check once it is restored
| Check | What it confirms |
|---|---|
| Homepage loads without errors | Files and database are both present and talking to each other |
| A few inner pages load | The backup is not missing large sections of content |
| Images and uploads display | The uploads folder was actually included, not just the code |
| Login and any search or comment form work | The database restored cleanly, including user accounts |
| The date on recent content matches expectations | You know exactly how much, if anything, would be lost restoring from this point |
If you restore to a subdomain to test, remember it is reachable like any other page unless you protect it. Add password protection or take it down again once you have checked it, particularly for a site handling any customer data.
How often to actually do this
Test when you first set a backup routine up — that is when you find out whether it was configured correctly at all. After that, a sensible rhythm is to test again whenever you change host, switch backup tools, or make a significant change to the site's structure, plus a periodic check every few months regardless, since configurations do drift over time without anyone touching them on purpose.
Making the routine check easier
You do not need to fully restore every single backup to catch most problems early. Watch the file size of each new backup for anything unusually small compared with the last one, keep completion notifications turned on if your tool supports them, and treat any gap or anomaly as a reason to run a full restore test immediately rather than waiting for the next scheduled one. Automating your backups covers setting up those notifications as part of the schedule itself.
The payoff
A backup you have restored once is no longer a hope. You know it contains what you think it contains, you know roughly how long a real restore takes, and you have already made the mistakes — wrong file, missing step, forgotten password — somewhere that did not matter. That is the entire difference between a backup routine and a backup that merely exists. Restoring a website from a backup and restoring a database specifically both cover the mechanics in detail once you are ready to run the test itself.
Related reading
Files and database, taken together, kept somewhere other than the account they protect — here are three ways to manage both.
How to restore a website from a backupA restore overwrites the live site with the backup, so do it in the right order — here is what that order is.
How to restore a database from a backupThe database half of a restore has its own tools and its own common errors — here is how to do it properly.
How to automate your website backupsA backup you have to remember to run by hand eventually does not get run — here are three ways to automate it instead.