Your Host Says You Have Backups. Can You Restore Your Site?
The backup job runs nightly and it says success every single night. It has said success for two years. Somewhere in that record, in the space between the word "backup" and the word "restore," the question the business actually needs answered has gone unasked.
A backup is a promise about a bad day
Retention is a storage question. Recovery is a business question, and it has two numbers that the backup dashboard never shows. How much can the business lose: the newest thing you would accept giving up, the last order, this morning's form submissions, the invoice that went out before the break. And how long can the business be closed: the gap between the break and the site working again, in hours, with the staff knowing and the customers not.
Those two numbers, answered honestly, define what a backup is for. "We have backups" answers neither of them. The job can be green for two years and the restore can still be a stranger to everyone, which is the exact position a business is in on the morning something needs it. The CISA stop ransomware guidance makes the same point from the worst case: copies you have never restored are the ones you discover are broken in the one week you cannot afford to be wrong.
A backup you have never restored is a hope with a timestamp.
What "the site" actually contains
Before a restore can be tested, the scope has to be named, because "the website" is smaller than the business thinks it is and the business's data is larger than the website holds.
| Copy | Who makes it | What it can prove |
|---|---|---|
| Host snapshot | The host | That the host kept a moment of the server. Nothing about whether you can get it back, on your terms, off the host |
| Independent copy | Your backup tool, outside the host | A copy that survives the host going away, if it has actually been restored at least once |
| SaaS export | Each platform, from its own dashboard | Only what that platform will let you take: forms, mail, analytics. Everything else lives elsewhere |
Put together, the scope of a small business site is usually: the files, the database, the uploads, the configuration, the DNS records, and the credentials that get it all back online. Then the data that is not on the site at all: form submissions that went to a service, email that lives with the mail provider, reviews, ad accounts. Each of those is a different vendor's export button, and a restore plan that covers the site but not the lead list has restored the brochure and lost the business. For a WordPress site, WordPress's own backup documentation is the place to check what the platform's tooling actually copies.
The staging rehearsal
The test is done in a private staging environment, never against production, and it is built with the discipline its name implies. Outbound mail disabled, so no customer gets a test email that says order received. Payments disabled, so nothing can charge a card. Access restricted to the people running it. Known test data, labeled as such, so nobody mistakes the rehearsal for a leak. A real backup, the latest one, is the only input. Then the boring part, which is the point: load the home page, log in, upload a file, submit a form, and open the one path the business actually lives on, the product page that sells, the booking page, the quote form. Whatever the business would cry if it were gone for a day is what gets tested.
A rehearsal that sends real mail, charges a real card, or touches the live site is not a rehearsal. It is an incident with better intentions. Staging differs from production in predictable ways, and the scorecard should say which ones were in play: a staging test that passes is evidence the restore can work, not a guarantee that production will be identical, and the honest version of that sentence is worth writing down before someone needs to say it to a customer.
The scorecard
One table, six columns, filled in by the rehearsal and kept where the next one can find it. Every blank is a question the next drill answers, and the date of the next drill is written on the same row as the last one, because the plan that outlives its own schedule is the plan that dies.
| Backup date used | Restore started | Restore finished | What was missing or wrong | Who verified it | Next drill |
|---|---|---|---|---|---|
No time column for "how fast it was," on purpose. The first drill's speed is meaningless; it is the baseline, and every drill after it is measured against it. Do not quote recovery times from a drill you have run once, and do not let anyone quote them to you.
The host keeping a copy is a kindness, and it is not a plan. The difference between a retained copy and a recovered service is one quiet afternoon: a staging environment, a real backup, a disabled mail queue, and a scorecard with a date on the next row. Run it once and the question in the title changes. It stops being "can you restore your site?" and becomes "you have, and here is how long it took," which is the only version of the answer a business can build on.
Backup questions
Is a database dump enough?
It is the most important piece and not the whole site. A site is the database plus the files plus the uploads plus the configuration, and a restore that brings back the database into an empty file structure is a site that loads and does nothing. The dump is the memory; the files are the body.
Can I test without touching production?
That is the whole design of a staging restore: a private copy of the environment, mail and payments disabled, access restricted. Production keeps serving customers the whole time. If the only way to test the backup is to risk the live site, the test is the risk and the plan has no safe version of itself.
What is a separate copy?
A copy that lives outside the host that is being backed up. The point is that a host that goes away, by failure or by ending the relationship, takes its own snapshots with it. A copy in a different account, with a different owner, is the one that still exists when that happens.
How do I know the restore is complete?
By the checks, not by the absence of errors. The home page loads, a login works, an upload lands, a form submits, and the business-critical path runs end to end, with the results written on the scorecard by the person who verified them. "Nothing broke" is an observation. The checklist is evidence.
More from the blog
- The First Hour When Your Site Goes Down, what the business does while the restore is running
- What Uptime Numbers Actually Allow, the other number nobody budgets for
- What a Traffic Spike Actually Does, for the day the site is fine and the database is not
All posts are on the blog. For the step by step versions, see the domain and hosting guides.
Has your restore ever been run?
Tell us what the site is built with and who holds the copies, and we will tell you where the gaps are, what a staging rehearsal would test, and who should be the name on the scorecard. If your setup already covers it, we will tell you that too.