Is Your Website Actually Backed Up? How to Tell
Nearly everyone believes their website is backed up. Far fewer have ever restored one. Here are the four questions that tell you whether yours would actually work.
Ask a business owner whether their website is backed up and the answer is almost always yes. Ask when they last restored one and the room goes quiet.
That gap is the whole subject. A backup is not a file sitting somewhere; it is a promise that on your worst morning, someone can put your website back. Until that promise has been tested, it is an assumption wearing a backup's clothing — and assumptions have a way of failing on exactly the day you needed them not to.
This is not an article about fear. It is four questions you can answer this afternoon, and a short honest test.
The four questions that actually decide it
"Do you have backups?" is the wrong question, because the answer is nearly always technically yes. These are the ones that separate a real safety net from a folder nobody has opened.
Where does the copy live? If the backup sits on the same server as the website, it protects you against exactly one scenario: you broke something. It does not protect against the server failing, the account being suspended, or the host having a bad week. A copy in the same building as the original is a convenience, not a safety net.
How often is it taken? Daily is the ordinary standard. Whatever the answer, that interval is the amount of work you are agreeing to lose — orders, form submissions, the blog post someone wrote yesterday. If a shop takes twenty orders a day and backs up weekly, the honest description of that setup is that it can lose a week of orders.
How far back can you go? This is the one almost nobody checks, and it catches people badly. Many setups keep only the most recent copy, or a rolling week. That is enough for a broken update, which announces itself immediately. It is not enough for the quiet problems — a defacement nobody noticed for ten days, a plugin that has been mangling pages since the start of the month. If every retained copy already contains the problem, you have backups of the damage.
How quickly can it be put back, and by whom? A copy nobody knows how to restore is a hostage, not a backup. If the honest answer to "who does this" is the name of a developer you last spoke to in 2023, that is worth knowing before the emergency rather than during it.
The three ways people find out theirs did not work
We see the same stories, and none of them involve anything dramatic.
The first is the silent failure. The scheduled task stopped running months ago — a password changed, a plugin updated, storage filled up — and nothing said so. Backups fail quietly by nature. Nobody gets an email saying your backup did not happen today, and so nobody knows until the day it matters.
The second is the incomplete copy. A website is two things: the files and the database. The files are the theme, the images, the plugins. The database is your text, your pages, your orders, your customers. Plenty of setups faithfully back up one of the two. A restored site with all its images and none of its content is a strange and specific kind of heartbreak.
The third is backing up the problem. Everything worked exactly as designed, and every stored copy is a picture of a site that was already broken. This is the argument for keeping more than a few days.
The test worth doing once
There is only one real way to know, and it takes about an hour.
Restore a backup somewhere that is not your live site. Most decent hosting offers a staging environment — a private copy of your site where you can break things safely. Restore into it. Then look properly: is the content there, are the images there, do the forms work, is the most recent post present. If you take orders, is the order data there.
Do it once. If it works, you have converted a belief into a fact, and you will sleep better for years. If it does not, you have found out on a Tuesday afternoon of your choosing rather than at nine on a Monday morning of somebody else's.
Every business with a website should have done this exactly once. Almost none have.
What good looks like
If you want a standard to hold your setup against:
- A copy taken daily, automatically, without anyone remembering.
- Stored somewhere other than the server the site runs on.
- Covering both files and database, together, from the same moment.
- Several weeks of history, not just the most recent copy.
- A restore that a normal person can trigger, or someone whose job it is to.
- Someone who notices when a backup does not happen.
That last one is the difference between a system and a hope. The failure mode of backups is silence, so the only real protection is somebody looking.
Where this sits with us
On our hosting, daily backups are included on every plan rather than sold as an extra, and they are watched — the point of the whole arrangement is that nobody has to remember. The plainest version of the promise: this is the sort of thing that should be running while nobody is watching, which is exactly when websites tend to break.
If your site lives somewhere else, none of this requires moving it. Go and ask your current host the four questions above, in those words. A good answer will be specific and immediate. A vague one is itself the answer.
And if you are not sure who is looking after the site at all — inherited from an agency, built by someone who has moved on — the Hosting Checker will at least tell you who is hosting it, which is where that conversation has to start. The Tune-Up is the wider version, a graded report across your email, certificate, blocklists and headers in one go. Both are complimentary and neither asks you to sign up.
One thing to do today: find out how far back your backups go. Not whether they exist — how many days of history you actually hold. It is a single question, the answer usually surprises people, and it is the number that decides how bad your worst morning gets.