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 answer is almost always never.
Those are different things, and the gap between them is where bad weeks come from.
What a real backup covers
A website is usually two parts, and losing either one loses the site.
The files. Templates, images, uploads, the code. What most people picture.
The database. Your pages, posts, settings, form submissions, users, and anything a customer entered. On a content-managed site this is the actual content. A file backup without the database restores an empty shell.
If your host says “we back up daily,” ask which of those it includes. Some plans back up files nightly and the database weekly, which means restoring costs you six days of content and does not look like a problem until it is.
Where they should live
Not on the same server as the site.
If the machine fails, or gets compromised, or a bad update takes it down, backups stored on it are affected too. Attackers who get in routinely delete local backups first, because that is the obvious move.
Reasonable arrangement: automatic backups at the host for quick rollbacks, plus a copy somewhere else entirely, held for longer.
How far back you need to go
Longer than you think.
Most incidents are noticed immediately: a bad update, a deleted page, a broken plugin. A week of history covers those.
The ones that hurt are the quiet ones. A site compromised in a way that only affects what search engines see, discovered five weeks later when the listings drop. If your backups only go back seven days, every copy you have is already infected.
A sensible retention pattern for a small business: daily for two weeks, weekly for two months, monthly for a year. Storage is cheap and this covers the slow discovery.
Test it, which nobody does
This is the whole article.
A backup is a belief until you have restored one. Things that are only discovered during a restore: the database dump was empty, the uploads folder was excluded, the process needs a password nobody has, the restore takes six hours, the automated job silently stopped in March.
Test it like this, once or twice a year:
- Take the most recent backup.
- Restore it somewhere that is not your live site. A staging area, a local copy, a temporary subdomain.
- Open it. Click through to a few pages. Check images load and the database content is there.
- Note how long the whole thing took, start to finish.
- Write down the steps while they are fresh.
That last step is the one that pays off. During an actual incident, you want a document, not a memory.
The number that matters
How long would it take you, today, to get the site back?
Not the marketing answer. The real one, including finding the login, working out which backup to use, doing the restore, and checking it.
If the answer is “I do not know,” that is your project this month. If the answer is “about two hours” and you have written down the steps, you are in better shape than most businesses several times your size.
Before you restore anything, work out why
The instinct after a problem is to restore immediately. Slow down for ten minutes.
If the site was compromised and you restore without knowing how they got in, you restore the way in as well. Same version, same vulnerable extension, same weak password. It happens again within days and now you have restored twice.
Sequence that works: take a copy of the broken site before you touch it, work out what happened, restore, then close whatever the hole was. If you cannot work out what happened, at minimum change every password, update everything, and remove anything you are not using.
More than the website
Same logic, wider scope. If your business would struggle without them, they need backups you have tested:
- Your business email, particularly if it holds the only copy of customer conversations.
- Shared documents. Cloud storage syncs, which is not the same as backing up. A file deleted or encrypted syncs that state everywhere.
- Anything a custom application stores.
- Your list of accounts and where things are registered.
A short annual ritual
Once a year, book an hour:
- Confirm backups are running and check the date of the newest one.
- Confirm they include the database.
- Confirm a copy exists somewhere other than the server.
- Restore one, somewhere safe, and open it.
- Update your written recovery steps.
- Note the date.
An hour a year. It is the cheapest insurance available to a small business, and it is the one most consistently skipped because nothing is wrong today.
