Website Backups: What They Are and Why Yours Might Not Exist

A website backup is a complete saved copy of your site — every page, every photo, every price, every booking that came in last week — kept somewhere separate from the site itself. If your website went dark tonight, the backup is the thing that puts it back. There is nothing clever about it.

Here is the uncomfortable part. Most small-business owners are fairly sure they have backups. Far fewer can say where those backups live, how old the newest one is, or who would restore it at nine on a Saturday night. That gap — between assuming and knowing — takes about ten minutes and one email to close.

What a backup actually is

A website is usually two things stacked together. There are the files — your pages, photos, logo, and the code that decides what sits where. And there is the database, which holds the parts that change: form submissions, bookings, reviews, blog posts, your product list. Not every site has one. A five-page site for a roofing company might be files only; a site that takes appointments almost certainly has a database.

A real backup captures both halves. Files without the database gives you a site that looks right and has forgotten every inquiry you ever received — a specific and very annoying way to learn the difference.

The copy also has to live somewhere else. A backup sitting on the same server as your website is fine on the day you delete a page by accident, and useless on the day the server itself is the problem.

A backup nobody has tested is not a backup

This is the part people skip, so it is worth being blunt. The backup is not the thing you are buying — the restore is. A backup is a promise; a restore is the promise kept. Nobody has ever been saved by a backup. They have been saved by a restore that worked.

Backups fail quietly, and always in ways you would never think to check:

• The job stopped running eight months ago and nothing sent an email about it.
• It copies the files but not the database, so the content comes back and the bookings do not.
• The copies sit on the same server that just failed.
• The file is there but incomplete, and nobody finds out until the day it matters.
• The backups are perfect and live in an account nobody at your business can log into.

The fix is not complicated. Test a restore once, deliberately, on a calm Tuesday when nothing is on fire. Ask whoever handles your site to put a recent copy on a temporary web address so you can look at it. A confident answer and a working site means you have backups. A long pause means you have just learned something extremely useful for free.

Where people assume their backups live

There are four common assumptions. None of them are scams. They are all just narrower than people think.

• “My host takes care of it.” Often partly true. Many hosting plans keep copies for a short window — a handful of days, sometimes a couple of weeks — and the older ones roll off automatically. Some include backups only on the pricier plan you did not buy. Some will restore for you and charge for it.
• “My website builder does it.” Hosted builders usually keep a history of the edits you make, which covers the day you break a page. That is genuinely useful. It is not the same as a full copy you can download and take elsewhere.
• “The person who built it has a copy.” Probably of your site exactly as it looked the day they handed it over. Two years of price changes and new photos later, that copy is a museum piece.
• “It is all in the cloud.” Cloud describes where something is stored, not whether anybody is copying it. Your live site is in the cloud too.

None of that means anyone is letting you down. It means “someone is probably handling it” is not a plan — and one email turns it into one. There is a copy-and-paste version further down.

What backups actually save you from

Backups are deeply boring right up until the twenty minutes in which they are the only thing that matters. Five situations actually come up:

1. 1A bad edit. Someone updates the pricing page, pastes something into the wrong box, and the layout falls apart on phones. Nobody notices for three days.
2. 2An update that goes sideways. Sites are built from parts, and occasionally one part updates and stops agreeing with another. A page goes blank, or the contact form silently stops sending.
3. 3A break-in. Almost never personal. Cleaning an infected site by hand is slow and never entirely certain; restoring a copy from before it happened is fast and definite.
4. 4A problem at the host. Hard drives fail, accounts get suspended over an expired card, companies get bought and migrations go badly.
5. 5Somebody deleting something. An employee tidies the photo library and removes forty images still used on three pages. No malice required, and no undo button.

Notice that only one of those five is an attack. The rest are ordinary Tuesday problems. That is the honest case for backups — not fear, just the fact that websites are worked on by humans and run on machines, and both occasionally have an off day.

How often is often enough

The question is not “what is best practice.” It is “how much of my website am I willing to recreate from memory?” Whatever your answer, that is your backup interval. Weekly backups mean that in the worst case you lose a week of changes.

For a site that changes a few times a year — hours, prices, the odd new photo — weekly is genuinely plenty. For a site taking bookings or inquiries all day, a copy that is a day old could mean a day of leads you never knew existed. That is when daily, or more often, earns its keep.

One thing catches people out: keep more than one copy. Damage is not always noticed the day it happens. If you keep only the newest backup and the trouble started three weeks ago, your one pristine copy has the trouble in it. A short ladder of copies beats one perfect copy.

Version history: the faster cousin of a backup

A full backup restores your whole website. Version history saves a snapshot of the site immediately before a single change, so undoing that one change is a click rather than a project. They solve different problems, and you want both.

Version history is what you reach for almost every time, because most website emergencies are really just a change somebody regrets. The full backup is the one you rarely touch and would be very sorry not to have.

The questions to ask your host, word for word

You do not need to understand the answers for this to be worth doing. Copy these five questions into an email to your hosting company’s support address, send it, and file the reply somewhere you will find it again.

1. 1Do you take backups of my website, and do they include both the files and the database?
2. 2How often is a backup taken, and how many previous copies do you keep before the oldest is deleted?
3. 3Where are the backups stored — on the same server as my site, or somewhere separate?
4. 4If I asked you to put my site back to how it looked last Tuesday, what exactly would I do, how long would it take, and is there a charge?
5. 5Can I download a copy of the most recent backup myself, and how?

Then read the answers with three things in mind. The answer to question two is your real safety window — if it is seven days, a problem you notice on day eight is a problem you own. Question four matters most, because a backup nobody can restore quickly is a filing cabinet, not a safety net. And if question five comes back as a no, your ability to recover depends on staying on good terms with that company.

None of that means switching hosts tomorrow. It means you will know exactly where you stand, which is a better position than most small businesses are in — and it cost you one email.