Website backups: how often, where, and how to test a restore

A website backup is only worth something once you have tested the restore. The short answer to “how often, where, and how do I test”: back up often enough that you never lose more work than you can afford to, keep at least one copy outside your own server, and restore a full backup in a test environment a few times a year to prove it works. Most companies get the first part sorted and forget the last, and that is exactly where it goes wrong at the worst possible moment.

In this guide we walk through what a good backup contains, how often to make one, where to store it, how this differs per platform and, most importantly, how to test a restore. It is part of the broader maintenance story from our B2B website guide.

What belongs in a good website backup?

A full backup contains everything needed to rebuild your site identically, not just the visible pages. In practice it comes down to four layers: the files (templates, images, scripts), the database with your content and settings, the configuration of server and environment, and any separate data such as form submissions.

The problem arises when you only keep part of it. A backup of just the database misses your images and theme. A copy of just the files misses your pages and blog articles. In a real emergency, think of a hacked site, a failed update or a server that crashes, you need both to get back online quickly. So check that your backup covers all layers and does not quietly skip something.

Also watch for data that falls outside the standard backup. Form submissions are on some platforms stored separately and do not fall under an ordinary site restore. If those leads are business-critical, arrange a separate export for them. A strong contact page that brings in leads is worth little if those leads disappear during a restore.

How often should you make a website backup?

As often as needed to never lose more than you can afford. The technical term for this is your recovery objective: how many hours or days of changes can you lose in the worst case? That answer determines your frequency, not the other way around.

For a static company site that rarely changes, a weekly backup can suffice, because little new work is lost between two moments. If you publish content daily or run a webshop-like flow with orders, you want to back up daily or even continuously. If you do not sell products through your site but generate leads, the value lies mainly in your content and your submissions: tune your rhythm to that.

A practical rule of thumb: always make a fresh backup right before a risky operation. A plugin or platform update, a redesign or a website migration are the moments when sites break most often. A manual backup right before it costs you a few minutes and saves you days of restoration work in the worst case. Do not blindly trust the default frequency your host or platform happened to set, because it is chosen for the average, not for your situation.

Where is it best to store your backups?

Not in the same place as your live site. The most commonly used guideline is the 3-2-1 rule: keep three copies of your data, on two different types of storage, with at least one copy in another location. That rule has been around for a long time because it works: it protects you against a single disk, a single service or a single location failing at once.

Concretely, that means the following. Your live site is copy one. An automatic backup at your host or platform is copy two, but it often sits in the same environment, so if that environment is itself the problem (a hacked account, a bankrupt provider, a deleted project), you are still vulnerable. That is why you keep copy three outside that system, for example in separate cloud storage or on a managed backup service that stands apart from your hosting.

The core of the rule is isolation. A backup that sits on the same server as your site is not real insurance, because a problem that hits your site often hits that backup too. So make sure at least one copy is technically and organizationally separated from your production environment. Also take the GDPR into account: personal data in backups must be secured and may not sit somewhere indefinitely and uncontrolled, so set a retention period.

How does backing up differ per platform?

It depends on your platform how much you have to arrange yourself, and no approach is automatically safe. Because we build websites in Webflow, WordPress and custom or headless, we see the differences up close.

On a hosted platform like Webflow, the system usually keeps versions and backups automatically, and you can roll back to an earlier point with a few clicks. The convenience is great, but watch the details: a restore often replaces the whole site to that moment, and separate data such as form submissions can sit apart and fall outside such a restore. With WordPress you are responsible yourself: some hosts make automatic backups, but the coverage, frequency and retention period differ strongly, and many teams supplement it with a backup plugin or an external service. With a custom or headless setup, your data is spread across a database, a CMS and file storage, and you have to set up backup and restore as part of your infrastructure.

The lesson is the same for every platform: never assume “it will probably be fine”. Find out concretely what happens automatically, what is missing and who is responsible. The right platform depends on your team, your content and your growth plans, but the need for a tested backup strategy applies everywhere.

Why is a backup without a tested restore worthless?

Because a backup you have never restored is only an assumption, not certainty. This is the part almost everyone skips. You see green checkmarks in your backup tool, you assume everything is fine, and only at the moment you really have to restore do you discover that the file is corrupt, a layer is missing or the process does not work as thought.

The reasons a restore fails are annoyingly mundane. A backup that quietly ran incomplete for months. A database export that does not match the files. A restore procedure that no one ever carried out and that in practice turns out to have more steps. At the moment your site is down, your revenue and your lead generation grind to a halt and the phone rings, that is the worst imaginable place to discover it.

That is why the rule holds: the value of a backup lies not in making it, but in the proven ability to restore it. A tested restore turns your backup from a hopeful assumption into real insurance. This fits our broader line of honest advice: we would rather tell you in advance that your restore has never been tested than have you find out during a crisis.

How do you test a restore in practice?

By periodically restoring a full backup in a separate environment and checking that the site actually works. So you do not test on your live site, but on a staging or test environment, so you break nothing in production.

A workable approach in four steps:

1. Pick a recent backup and restore it fully on an isolated test or staging environment, separate from your live site.
2. Check that everything is there: do the pages load, are the images correct, is the content present, do the forms work and is the configuration correct?
3. Measure the restore time: note how long the full process takes, because that is your realistic downtime in a real emergency.
4. Record the steps in a short playbook, so that in a crisis you follow a known procedure and do not have to improvise under pressure.

Do this at least a few times a year, and certainly after every major change to your site or hosting. Just like a fire drill, the goal is not the drill itself, but the certainty that it works when it really matters. A restore you have calmly carried out three times gives you no stress the one time it is for real.

The short summary

A good backup strategy stands or falls with the restore. Determine your frequency based on how much work you may lose at most, back up extra right before risky operations, and store at least one copy separate from your live environment following the 3-2-1 rule. Check that your backup contains all layers, including data that is stored separately such as form submissions. And most importantly: restore a full backup in a test environment a few times a year, so you know your restore works before you really need it.

Do you want your website and your lead flow to stay standing even during an emergency, and do you want to know whether your current backup and restore setup is really watertight? Book your free intake and we will take a critical look together.