Website Backups: The One You Never Tested Doesn't Exist
Almost everyone has backups. Almost nobody has tried restoring one. The gap between those two sentences is what separates a scare from two weeks of lost work.
August 23, 20226 min readIn this article
- What a backup has to contain to be worth anything
- How often: match it to what you can afford to lose
- The 3-2-1 rule, in a small-business version
- The step almost nobody takes: proving you can restore
- How long to keep them: the silent-damage problem
- What your host includes, and what it doesn't
- The backup nobody makes: credentials and the domain
- What this actually costs
- Frequently asked questions
The backup conversation always arrives late. Nobody has it on launch day; they have it on the Tuesday they log into the panel and find the site blank, or covered in casino adverts, or simply empty because somebody deleted the wrong thing.
And that day two uncomfortable facts surface: the backup the host claimed to have is a month old, and nobody knows exactly how to use it. This article is about avoiding that Tuesday.
What a backup has to contain to be worth anything
Plenty of people think their website is "the files". On most modern sites, the part that genuinely hurts to lose isn't in the files: it's in the database, where the content, the orders, the users and the received enquiries live.
- Site files: the code, the templates and — the heaviest part — the images you uploaded.
- The database: content, products, orders, customers, comments. The irreplaceable part.
- Server configuration: certificates, redirects, rules. Always forgotten, and days of work to rebuild.
- Email, if it's with the same provider. Losing the mailbox usually hurts more than losing the site.
- DNS records, written down somewhere. Without them, you can restore everything and still have nothing pointing anywhere.
How often: match it to what you can afford to lose
The useful question isn't "how often should I back up?" but "how much work am I willing to redo?". If the answer is "a day", you need daily backups. If it's "an hour", you need something more serious than a nightly job.
| Type of site | Sensible frequency | Worst-case loss |
|---|---|---|
| Brochure site that rarely changes | Weekly, plus one backup before every change | Nothing meaningful: the content is stable |
| Site with an active blog | Daily | One article, which can usually be rewritten |
| Online store | Daily minimum; hourly in peak season | Real orders from real customers. No margin here |
| System with users and data | Continuous or every few hours, with long retention | Third-party data — potentially a legal problem, not just an operational one |
The 3-2-1 rule, in a small-business version
The classic formulation says: three copies, on two different media, one of them off-site. It sounds like an IT department, but translated to an ordinary business it's fairly simple and cheap.
- The live site — that's copy number one, the one that's running.
- An automatic backup at the host, which restores quickly when the problem is yours rather than the server's.
- A copy outside the provider: another storage service, or even a monthly download to a disk. This is the one that saves you when the host is the problem.
The step almost nobody takes: proving you can restore
This is the heart of the article. A backup that has never been restored is a hypothesis, not a safeguard. And it fails more often than people imagine: incomplete files, a half-exported database, software versions that no longer match, passwords nobody remembers.
The test doesn't have to be complicated. Once a year, restore the backup to a staging site and check that the site boots, the images are there, and the admin panel opens. If something breaks, you find out on a calm day rather than on the day of the disaster.
How long to keep them: the silent-damage problem
Keeping only yesterday's copy feels sufficient until a problem surfaces that had been sitting there for weeks unnoticed: content deleted by accident, a spam injection, a tweak that broke something secondary. If all your backups are recent, all of them contain the problem.
A simple scheme that works: the last 7 days daily, 4 weeks, and 6 or 12 months. It takes little space because older copies get spaced out, and it covers both yesterday's mistake and the one that was already there in March.
What your host includes, and what it doesn't
Many plans advertise automatic backups, and they generally exist. What's worth verifying is the small print: how often, how long they're kept, whether restoring is free, whether you can download them yourself, and whether they sit on the same infrastructure as the server. The differences between hosting types are in shared, VPS or managed hosting.
The backup nobody makes: credentials and the domain
There's a way of losing your website that no file backup solves: the domain expiring, or sitting in the name of a provider you've fallen out with, or the only person holding the passwords no longer working with you.
- The domain in the business's name, with auto-renewal and a notification address somebody actually reads. The substance is in why your own domain matters.
- Credentials documented in a company password manager, not in the head of the nephew who built it.
- More than one person with access to hosting, domain and admin panel. One person is a single point of failure.
- DNS records saved in a document: rebuilding them from memory mid-outage is grim.
What this actually costs
It's among the cheapest things you can buy relative to what it protects. External storage for a small site's backups costs little per month, and many maintenance plans already include it. Set against rebuilding a site and losing a month of orders, there's no argument — the general cost framework is in how much a professional website costs.
Frequently asked questions
My host says it takes backups. Is that enough?
It's a good starting point, but not enough on its own. It depends on the frequency, how long they're retained and — above all — whether they live outside the same server. If the provider is the problem, that copy goes with it. Add an external copy you control, even if only monthly.
How often should I test a restore?
Once a year is enough for a brochure site; every six months for a store or a system holding customer data. It's also worth testing after any major infrastructure change, because that's precisely when the process quietly stops working without anyone noticing.
Do backups protect against being hacked?
They help you recover, but they don't prevent it and don't fix it by themselves. Restore a backup without closing the hole they came through and they're back within days. And if the attack had been active for weeks, your recent backups already contain it — which is exactly why keeping older copies matters.
What about company email?
Always forgotten, and usually the most painful thing to lose. If email sits with the same provider as the website, it goes down with it. The sensible arrangement is keeping it separate from the hosting and, if it's critical, backed up in its own right: there are years of conversations and customer information in there.