How to back up a website you'd hate to lose
A website backup is more than a copy of the pages. You also need the form submissions, the domain's DNS settings, any code, and the accounts that tie them together. Keep at least one copy somewhere you control, separate from the host, and test a restore before you need one.
What actually needs backing up
| Part | Why it matters | How to copy it |
|---|---|---|
| Pages and design | Rebuilding from memory takes days | An export from your builder or host, or the files themselves |
| Form submissions | Enquiries, bookings and sign-ups you can't get back | A CSV export, or a connector copying each one to a spreadsheet or CRM |
| Images and documents | Original photos are often lost once uploaded | Keep the originals in your own storage, not only on the site |
| Domain and DNS records | Losing them takes email down with the site | A screenshot or text copy of every record at your DNS provider |
| Code and configuration | Custom work is the most expensive part to redo | A Git repository, plus a note of environment variable names (not values) |
| Access | A backup you can't log in to restore is useless | A list of every account involved, with two-factor recovery codes stored safely |
Make a backup routine, step by step
- List every part from the table that applies to your site.
- Export what can be exported: the site files or project, the submissions as CSV, your images.
- Copy the DNS records as text: type, name, value and TTL for each.
- Store the copies in two places, at least one outside the host: your computer plus a cloud drive, for example. A common rule of thumb is three copies, on two kinds of storage, one off-site.
- Write down how to restore: which account, which export, which steps. You won't remember under pressure.
- Set a schedule. Monthly suits a site that rarely changes; weekly or continuous suits one with daily bookings.
- Test a restore at least once (below).
Test that a restore works
Untested backups fail in predictable ways: the export was empty, the file was from the wrong project, or the restore needs an account nobody can sign in to. Pick a quiet day. Restore the pages somewhere harmless, such as a new project or a local folder, and open them. Open the CSV of submissions and check the latest one is there. Compare your saved DNS records with what the provider shows today. If any step needed something that wasn't in the backup, add it to the routine.
What Anticode keeps for you
- Version history
- Saves from the builder, the CLI or an assistant are kept as versions: the most recent ones, up to a number set by your plan. You can preview any earlier version and restore it; a restore becomes a new version, so nothing is overwritten. See rolling a website back to a previous version.
- Published backups
- The last ten published versions of each site are backed up. You don't restore these directly: the integrity scan uses them to put changed files back, and you roll back with version history. Unpublishing a site deletes its backups.
- Integrity checks
- File hashes are recorded at publish and checked by a scan that runs hourly on a batch of sites, so each site is checked about once a day.
- Exports you control
- Download the site as one self-contained HTML file, or as a Next.js project, and keep it yourself. Form submissions can be exported from the dashboard or copied as they arrive through connectors such as Google Sheets or Airtable.
Those cover the pages and code well. What they don't cover is everything outside Anticode: your DNS records, your original photos, your logins. Those are yours to copy.
Common mistakes
- Relying only on the host's backups. If you lose access to the account, you lose access to its backups too.
- Backing up pages but not submissions. The pages can be rebuilt; last month's enquiries can't.
- Keeping backups with live secrets in plain text. An export containing API keys or passwords needs the same protection as the keys themselves.
- Forgetting the domain. A lapsed renewal or a deleted DNS zone can take a site and its email offline even when every file is safe. Turn on auto-renew.
Limits
Anticode's backups and history protect against bad edits and changed files on sites it hosts. They aren't an archive of everything you've ever had: deleting a project removes its files, collections and submissions from your account, and that can't be undone. Export before deleting anything you might want later. If you've exported to your own hosting, backing up that copy, and its database, is your job; the Next.js export guide explains what it contains.
Questions people ask
How often should I back up a small website?
Match it to how often things change. Pages that change monthly need monthly copies; form data that arrives daily needs a daily copy or a connector that copies each submission as it arrives.
Does my website builder back up my site?
Most keep some history, but check what and for how long. With Anticode, recent saves are in version history (up to your plan's number) and the last ten published versions are backed up.
Where should I keep backups?
In at least two places, one of them separate from your host, such as your own computer plus a cloud drive you control.
Sources
- Backblaze: The 3-2-1 backup strategy, checked