Talk to a person. We reply within one working day.

SEO and AI search
Web
AI
Resources
WorkAboutStart a project

Website care · 10 Nov 2026 · 5 min read

Website backups: how often, where to keep them and how to test them

A backup is only worth having if you can restore from it on a bad day. This guide walks through what to copy, how often, where to keep it and the one step most people skip: trying a restore before you need one.

The short answer

Back up both the website files and the database, on a schedule that matches how often your content changes, and keep copies in at least one place away from your hosting account. Keep several versions, not just the latest, and test a restore regularly. A backup you have never restored is only a hope.

What a website backup has to contain

A website is usually made of more than one part, and a backup that misses one of them will not bring the site back.

  • Files: the theme or template, plugins, uploaded images and documents, and configuration files.
  • Database: on most content management systems, the pages, posts, orders, users and settings live here, not in files.
  • Email and DNS records: if your host also runs your email or your domain settings, those need exporting too. See email hosting versus web hosting.
  • Third-party services: a booking tool or newsletter provider holds its own data. Check how to export it.
  • Access details: a note of where the site is hosted, who owns the domain and how to log in, kept securely.

A static site built from files may need only a copy of the source. A shop or membership site, where data changes by the minute, needs far more care.

How often to back up

Ask one question: how much would we lose if we had to go back to the last copy? If you publish one article a month, losing a day is minor. If you take orders all day, losing even an hour of data means orders and payments you cannot match up.

Type of siteSensible rhythm to discuss
Brochure site, changed rarelyAfter every change, plus a regular scheduled copy
Blog or news siteDaily, with files copied less often than the database
Online shop or booking siteFrequent database copies through the day, daily full copy
Community or membership siteSame as a shop, because members create the content

These are starting points for a conversation with your developer, not rules. Also take a manual backup before any risky change, such as an update, a redesign or a plugin install. A staging site is a safer place to try changes in the first place.

Where to keep copies

The classic advice is the 3-2-1 idea: three copies of your data, on two different kinds of storage, with one copy kept somewhere else. For a website this translates well.

  1. The live site is copy one.
  2. A backup stored by your host or a plugin is copy two. It is convenient but sits close to the thing it protects.
  3. An off-site copy in a separate service, under a separate login, is copy three. This is the one that saves you if the hosting account is hacked, suspended or deleted.

Be wary of keeping all copies in the same account. If an attacker or a billing problem takes the account, the backups go with it. Also protect the backups themselves: they contain customer data, so use strong access controls and, where available, encryption. Treat them as seriously as the live site; see website security basics.

How long to keep them

Keeping only the latest copy is risky, because problems are often noticed late. If malware or a bad update sat unnoticed for a week, the latest backup contains it too. Keep a series: recent daily copies, some weekly and a few monthly. How far back you go depends on how long it would take you to notice a problem and on any rules about keeping or deleting customer data.

That last point matters. Backups can hold personal data that you have promised to delete or only keep for a time. Ask a qualified lawyer how this affects your retention period, and reflect your approach in your privacy policy.

Test the restore

The common failure is not the missing backup, it is the backup that will not restore. Files can be incomplete, a database export can be cut short, or nobody knows the steps. Schedule a restore test on a regular basis.

  1. Pick a recent backup.
  2. Restore it to a staging copy or a spare test location, never over the live site.
  3. Check that pages load, images show, forms submit and logins work.
  4. Write down how long it took and what you did, step by step.

That written procedure is worth as much as the backup. In an emergency you want a checklist, not memory.

Who is responsible

Do not assume your host does it. Some hosting plans include backups, some offer them as an extra and some do not guarantee them. Read the host's documentation about what is covered, how long copies are kept and how to restore. If the answer is unclear, ask in writing.

Agree who owns the task if a supplier maintains your site. A maintenance plan should state the backup schedule, the storage location and the restore test. Pair backups with uptime monitoring, so you find out quickly when something fails, and keep our guide to what to do when your website goes down handy.

Common backup mistakes

A few errors turn up again and again. Backups stored only on the same server as the site disappear with it. Backups made by a plugin that stopped running months ago go unnoticed because nobody reads the alerts. A database export that fails halfway looks like a file but cannot be restored. Passwords to the backup storage live in one person's head. And the person who set it all up leaves without writing anything down.

Guard against each: store a copy elsewhere, send backup status messages to a shared address that someone checks, test restores, keep access details in a shared password manager, and write the procedure down in plain steps that a colleague could follow under pressure.

A simple starter plan

  • List what must be backed up: files, database and external data.
  • Set the schedule from how much you can afford to lose.
  • Store one copy away from the hosting account, under a different login.
  • Keep several versions over time.
  • Take a manual copy before every significant change.
  • Restore to a test location and record the steps.
  • Review the plan whenever the site or hosting changes, including a move to a new host.

Related guides

Questions and answers

How often should I back up my website?

Match it to how often your site changes and how much you could afford to lose. A rarely changed site may need less; a shop or booking site needs frequent database copies. Always take one before big changes.

Is my hosting company's backup enough?

Not on its own. Host backups sit close to the live site and may be limited in scope or how long they are kept. Check the host's documentation and keep an off-site copy under a separate login.

What is the 3-2-1 backup rule?

Keep three copies of your data, on two different types of storage, with one copy stored in a different location. It reduces the chance that one failure removes everything.

Do I need to back up the database as well as the files?

Yes, for most content management systems and shops. The database holds pages, orders, users and settings. Files alone will not restore a working site.

How do I know my backup works?

Restore it to a test location and check pages, images, forms and logins. Do this regularly and write down the steps. A backup that has never been restored is untested.

Can backups cause privacy issues?

They can hold personal data, so they need access controls and a sensible retention period. Ask a qualified lawyer how data deletion promises apply to your backups.

Tell us what you are building.

A short call, a written plan and a fixed quote. No obligation.

Get a free quote