Running & Maintaining a Site

Website Backup

Definition

A website backup is a complete, restorable copy of the files that make up a site, stored independently of the system that publishes it. For a static site the list is short: every page, every stylesheet and script, every image, font and PDF, plus whatever configuration tells the host how to serve them. The useful test is not whether a copy exists but whether you could rebuild the site from that copy alone if the original vanished tonight. Version history on a host is not a backup when the account itself is the single point of failure, because a suspended, deleted or compromised account takes the history with it. The common backup rule is three copies, on two kinds of media, with one off-site; for a small site that can be as modest as the live version, a folder on your laptop and a copy in cloud storage.

Why It Matters

The failure modes people actually hit are not dramatic. An account gets locked over a billing card that expired, a shared login is taken by someone who has left, a folder is overwritten by a bad upload, or a provider closes a free tier with thirty days notice. In every one of those cases the site is gone and the question is simply whether you still have the files. Rebuilding a twenty-page site from memory and the Wayback Machine is a weekend; restoring from a ZIP is ten minutes. A backup is also what makes a data export or a move to another host possible at all, which is why the same copy protects you from vendor lock-in.

How It Works

Take the whole published directory, not a selection: the top-level 'index.html', every subfolder, and hidden files like 'robots.txt' if you use them. Put it in a dated ZIP archive, so restoring is one upload rather than a file-by-file comparison. Automate it if you can — a host with a REST API lets a scheduled script pull the current version each week and write it to storage you control. Keep the copies on a schedule you can state out loud, such as weekly with the last eight kept and one a month kept for a year. Then do the part nearly everyone skips: once a quarter, unzip a backup into a fresh location and load it, because an archive that has never been restored is an assumption, not a backup.

Real-World Example

A consultancy publishes a 12-page handbook as a static site at nine-oaks-handbook.99helpers.site, edited every few weeks. Each Sunday a small script calls the 99helpers REST API, downloads the current published files as a ZIP, and drops it into a folder on the owner's machine that syncs to cloud storage. In March a colleague uploads the wrong build and overwrites six pages. Version history fixes that in one click within the minute. In July the same account is briefly locked during a payment change, and the Sunday ZIP is the only thing standing between the firm and rebuilding the handbook from an old email attachment.

Common Mistakes

  • Treating the host's version history as the backup — it lives inside the same account, so anything that removes your access to the account removes the history too
  • Backing up the source files but not the built output — if the toolchain that produced the site has moved on a version, the source alone may not rebuild
  • Never testing a restore — corrupt archives, missing subfolders and truncated uploads are all discovered at the worst possible moment
  • Keeping every copy in one place, so a single deleted folder or failed drive ends the whole scheme

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →