Every hosting provider says your website is backed up. It is on the pricing page, usually next to a checkmark.
What almost nobody says is whether those backups have ever been restored.
That is the only part that matters. A backup is not the file sitting on a disk somewhere. It is your ability to get the site back, in a known state, within a known amount of time, when something goes wrong. Until someone has done that at least once, you have a file and a hope.
The CEO of one association put the buyer's real question plainly while we were scoping a launch:
Like, is there a giant undo button?
There can be. But it has to be built and tested, and it is really three different buttons.
Three Kinds of "Something Went Wrong"
When people say they need backups, they usually mean one of three scenarios. Each needs a different recovery, and a plan that handles one does not automatically handle the others.
1. A Change Broke the Site
A plugin update, a code release, or a configuration change went out, and now a page is broken or the whole site is down. Nothing is lost. The site just needs to go back to how it was an hour ago.
This is a rollback, not a restore. It should be fast, measured in minutes, and it should not touch your content. If rolling back a bad update means restoring last night's full backup, you will lose every form submission, registration, and edit made since then.
The right setup keeps code and configuration in version control, so the previous working version can be put back without touching the database.
2. Content or Data Was Lost
Somebody deleted the wrong page. An import overwrote member records. A form stopped saving submissions for three days and nobody noticed.
This is a partial restore. You do not want the whole site to go back in time. You want one page, one table, or one set of records back from a specific day, merged into a site that has kept running.
Partial restores are the ones most often attempted for the first time during the incident. They are also the ones where "we have daily backups" turns out to mean "we can put the whole server back to last Tuesday, and you will lose everything since."
3. The Whole Thing Is Gone
The server failed. The hosting account was compromised. The site was defaced, or someone with access did something they should not have.
This is a full restore, often onto a fresh server. It needs a backup that does not live on the machine that failed, and a copy of everything, not just the database: uploaded files, configuration, and the code itself.
What a Real Backup Covers
When you ask what is backed up, listen for all of these:
- The database. Pages, settings, member records, form submissions, orders.
- Uploaded files. Images, PDFs, documents. These often live outside the database and are the easiest thing to forget.
- The code and configuration. Ideally in version control, separately from the nightly backup.
- Where the copies live. At least one copy should be off the server and outside the hosting account. If an attacker or a billing dispute can reach the backup, it is not protecting you.
- How long they are kept. Seven daily copies do not help with a problem you notice after three weeks. Ask about retention.
And the things that usually are not covered, which you should know about in advance: email hosted elsewhere, DNS records, and any data living in outside services like your AMS, CRM, or payment processor. Those need their own answer.
The Two Numbers to Know
Two plain questions define any backup plan, whether or not anyone uses the technical terms for them.
How much could we lose? If backups run once a day at midnight and the server fails at 11 p.m., you lose a day. For a brochure site, that is fine. For a site taking registrations the week before an annual meeting, it may not be.
How long until we are back? Minutes, hours, or days. The answer depends on the size of the site, whether a restore procedure exists, and whether anyone has practiced it.
You do not need these numbers to be impressive. You need them to be known, and matched to what your site actually does.
The Question to Ask Your Host
Here it is:
When did you last restore this site from a backup, and how long did it take?
A good answer is specific. It names a date, what was restored, where it was restored to, and roughly how long it took. It might be a routine test restore to a staging copy. It might be a real recovery after someone deleted something. Either counts.
A weak answer sounds like "our backups run nightly" or "we use an industry-standard backup service." Those describe the backup. They say nothing about the restore.
If the answer is "we've never needed to," that is honest, and it tells you the restore is untested. Ask for a test restore to a staging copy. It is a reasonable request, and the result tells you more than any pricing page.
Build the Undo Button Before You Need It
The habits that make recovery boring are not complicated. They are just easy to skip.
- Back up before every significant change. Before a migration, a major update, or a bulk import, take a fresh backup and confirm it completed. Our standing rule on migrations is a backup first and a test batch before the full run.
- Test on a copy, not on production. As we have told clients more than once: we don't want to touch the production site until we're ready to say yes. A staging copy is where changes prove themselves.
- Restore on a schedule. Periodically restore a backup to a separate environment and check that the site actually works. A backup that has never been restored is an assumption.
- Write the procedure down. Where the backups are, who has access, and the steps to restore. The person who set it up may not be the person on call when it is needed.
- Watch for quiet failures. Backup jobs fail silently more often than servers do. Someone should be alerted when a backup does not complete, not discover it during an incident.
A Simple Rule of Thumb
If nobody can tell you when your site was last restored, your backup plan is untested.
That is not a crisis. It is a thirty-minute conversation and one test restore away from being fixed. It is much cheaper to find the gap on a quiet Tuesday than during an outage.
Final Thoughts
Backups are not the point. Recovery is. The organizations that come through a bad day without damage are rarely the ones with the most elaborate backup system. They are the ones that knew what they had, where it was, and exactly how to use it, because they had already done it once.
Ask the question. If the answer is good, you can stop thinking about it. If it is not, you have found the most useful thing you will fix this year.
Every Managed Website plan includes daily backups and monitoring. If you would like a second opinion on how your current site is protected, book a short consult and we will walk through it with you.