How do I back up my website, and how often?

What "backed up" needs to mean

Most hosting includes automatic backups, and most people stop there. That covers the common cases — a bad update, a mistaken deletion — and it fails the ones that actually take a business down.

If your backup lives entirely inside the account it is protecting, then losing that account loses both. Suspended for non-payment, locked out, a dispute with whoever manages it, or the provider itself having a bad week — in every one of those the backup is on the wrong side of the problem.

So the rule is simple: at least one copy somewhere you control that is not the host.

The three things worth backing up

Files — the site itself: pages, templates, code, uploaded images.

The database, if your site has one. Content, products, bookings, customer records. On a dynamic site the database is usually more important than the files, because files can be rebuilt and content cannot.

The things that are not the site. Your domain login, your DNS settings, your email configuration. Not backups exactly, but the details you will need in the same emergency and will not be able to look up while everything is down.

How often

Match it to how much work you could bear to lose:

Site type	Backup frequency
Brochure site, rarely changes	Weekly is fine
Menu or prices updated often	Daily
Bookings or orders taken online	Daily, and check the database is included
During any migration or big change	Manually, immediately before

That last row is the one people forget. Take a manual backup before any significant change, so recovery is a restore rather than an investigation.

Where to keep the separate copy

Anywhere the host cannot reach: a cloud drive you own, an office machine, an external disk. It does not need to be sophisticated. A monthly manual download to somewhere you control is enormously better than nothing.

Keep more than the most recent one. Some problems are discovered weeks later — a corrupted database, content quietly overwritten — and a single rolling backup will by then have faithfully copied the damage.

Test it once

The step almost everyone skips, and the reason backups fail when needed.

Restore to a staging site or a local copy and check it actually works: pages render, images resolve, the database loads. Common discoveries are that the backup was files-only with no database, or excluded the uploads folder, or had been silently failing for months.

Once a year is enough. Once, ever, is infinitely better than never.

If someone else manages your site

You may not need to run any of this yourself. You do need to know the answers:

• Are backups automatic, and how often?
• Is the database included, or just files?
• How far back do they go?
• Where are they stored — same server, or somewhere else?
• If I asked for a copy today, could I have one?

That last question is the useful one. A provider who can hand you a copy on request is a provider whose backups exist. It is also the question that tells you what happens if you ever part ways.

When backups are somebody else's job

Everything above assumes you own the problem. On a managed platform you should not — and the five questions in the previous section are exactly the ones to put to a provider before you sign up, not after something breaks.

Helm's answers, for reference: backups run automatically every night, encrypted, and are stored off the server rather than on it. Separately from that, version history in the dashboard lets you restore a previous version of your content yourself — which is the case that actually happens. Most "we need a backup" moments are not a server fire. They are somebody replacing the right paragraph with the wrong one at 6pm and not remembering what it said.

And the last question on that list has a plain answer: yes, you can have a copy on request, because the code is yours anyway.