Backups, Explained: The Only Insurance Your Website Has

If I could give every website owner exactly one piece of advice, it would be this. Have a backup you have actually tested. Not a backup you assume exists. Not a backup your hosting company mentioned once in a welcome email. A real one, in a place you control, that you know how to restore.

A backup is the only insurance your website has. Everything else, security plugins, strong passwords, careful updates, is about keeping trouble out. A backup is what saves you when trouble gets in anyway.

What a real backup actually is

A website is two things, not one. There are the files: your theme, your plugins, your images, everything that makes the site look like your site. And there is the database: your pages, posts, settings, orders, form entries, and customer information.

A backup that only has one of those is half a backup. Files without the database give you an empty shell. A database without the files gives you content with nothing to display it in. When someone tells me "we have backups," my first question is always whether both halves are in there.

Where it lives matters as much as whether it exists

Here is the trap I see most often. The backup plugin stores the backups on the same server as the website. That feels tidy, and it is useless in the exact situations where you need it most. If the server dies, your backup dies with it. If the site gets hacked and the attacker pokes around, your backup is sitting right there next to the damage.

A real backup lives somewhere else. Cloud storage, your own computer, a separate service, anywhere that is not the same box as the site. This is one of the first things I set up when a site goes on a maintenance routine, and it is a core part of the schedule I lay out in my website maintenance checklist.

How often, and how far back

How often you back up depends on how often your site changes. A brochure site that gets edited twice a year can live with weekly backups. A site taking orders or bookings every day should be backing up daily, because restoring last Tuesday's version means losing everything since.

Keep some history, too. Thirty days of backups is a good target. That matters more than people realize, because problems are not always discovered the day they happen. A hack can sit quietly on a site for weeks before anyone notices, and if all your backups are from after the infection, every restore just puts the problem back.

The part everyone skips: testing the restore

An untested backup is a hope, not a backup. I have sat on calls with owners who were certain they were covered, right up until the restore failed, or restored a half empty site, or turned out to be a feature their hosting plan did not actually include.

Testing is simple. Once in a while, restore the backup to a test location and look at it. Does it load? Are the pages there? Do the images show? Ten minutes of checking, once a quarter, turns "I think we have backups" into "I know we do." That is part of what the monthly support plan handles for the sites I look after, because it is the step that gets skipped when everyone is busy.

A backup is also the fastest way out of a hack

When a site gets hacked, there are two roads out. One is cleaning the infection by hand, file by file, which is what I describe in what a hack cleanup actually involves. The other is restoring a clean backup from before the infection and then locking the doors behind it. When a good backup exists, the second road is faster, cheaper, and calmer for everyone.

That is really the whole argument. A tested backup turns most website disasters into an inconvenience instead of a catastrophe.

If you are not sure what your backup situation actually is right now, that is worth finding out before you need it. It is one of the first things I check when I sit down with an owner on a screen share, and it takes about five minutes to know whether you are covered or just hoping.