Running & Maintaining a Site

Disaster Recovery

Definition

Disaster recovery is what happens after prevention has failed. It covers the total losses rather than the small ones: a host that shuts down, an account closed without warning, a domain that lapses, a folder deleted by someone with the right credentials and the wrong intention. Two numbers describe any plan. The recovery time objective is how long the site may stay down, and the recovery point objective is how much recent work you accept losing — if backups run weekly, your recovery point is up to seven days of edits. A plan is only real when it names the copy you restore from, the place you restore it to, and the person who holds the login for both. For a static site the good news is that the whole thing is files, so recovery is an upload rather than a rebuild.

Why It Matters

Without a plan the recovery starts with an hour of searching for credentials, which is an hour of downtime paid at the worst moment. Put numbers on it: if a site collects ten enquiries a day and your objective is four hours, you have decided to lose fewer than two. That is a business decision, and writing it down turns a panic into a checklist. A plan also exposes the dependencies nobody thinks about — the registrar login held by a contractor who left, the DNS account tied to a personal email, the build that only works on one laptop.

How It Works

Start by listing what must come back: the files, the domain, the DNS records, the certificate and any analytics you would miss. Store a current website backup somewhere separate from the live host, and store the access details for the registrar and DNS separately again, because losing one account should not lock you out of the other. Write the restore as numbered steps — upload the ZIP to a second host, point the A record or CNAME record at it, wait out the TTL, confirm HTTPS, check the three most important pages. Keep the DNS TTL low enough that a switch takes minutes rather than a day, and know in advance which alternate host you would use. Then rehearse it once, on a spare subdomain, before you need it.

Real-World Example

A charity runs its annual report at trust-report.99helpers.site on a custom domain. The plan is one page long: the ZIP lives in the treasurer's cloud storage, the registrar login is in a shared password vault with two people holding access, and the DNS TTL sits at 300 seconds. When a mis-typed bulk operation empties the account one Tuesday, the treasurer uploads last Friday's ZIP to a fresh 99helpers site, repoints the CNAME, and the report is back on its own domain in under twenty minutes. The only loss is two small copy edits made the day before.

Common Mistakes

  • Having backups but no written restore steps — the files are fine and the four hours go to remembering how the domain was wired up
  • Keeping the recovery documentation on the site that is down, or in a document only one person can open
  • Leaving the DNS TTL at 86400 seconds, which means a switch to a standby host can take a full day to reach everyone
  • Never rehearsing, so the first restore attempt is also the first time anyone discovers the backup is missing a folder

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 →