Disaster recovery for a small business website: a one-page plan
If the platform or the domain were gone tomorrow, how would the site come back? One page: what is backed up where, who restores it, how fast.
The short answer
Disaster recovery is the answer to one question asked of every piece of your website: if this were gone tomorrow, how would we get it back, from what, and in how long? Ask it of the code, the content, the domain, the hosting platform, the data behind forms and logins, and the accounts and credentials that hold it all together. For a static site in version control, most of the answers are reassuringly short. The domain and the data need more care. Write the answers on one page, decide the two numbers that define the plan, and test it once by restoring to a new account without touching production.
The one-page plan
| Piece | Where the copy is | Who restores | How | Target time |
|---|---|---|---|---|
| Code and templates | Repository in the company account, mirrored to a second location | Partner | Clone, build, deploy to a new platform account | Under an hour |
| Content | In the repository, or exported nightly from the content system to company storage | Partner | Part of the build, or re-import | Under an hour |
| Media | Object storage with versioning, plus a periodic copy elsewhere | Partner | Restore or repoint | An hour |
| Domain and DNS | Registrar account in the company name; DNS records exported monthly | Business owner with partner | Repoint records; if lost, registrar recovery process | Minutes if held; days if lost |
| Data: forms, users, orders | Database backups to a separate location, tested restores | Partner | Restore to a new database, repoint functions | Hours |
| Configuration and secrets | Documented layout; values in the company password manager | Partner | Recreate in the new account | An hour |
| Accounts and access | Company-owned, two admins, password manager | Business owner | Log in; create new accounts if needed | Minutes |
| Monitoring and alerts | Configuration documented | Partner | Recreate | An hour |
The order of restoration
- Secure the domain. Nothing else matters if visitors and email go elsewhere. Confirm access, lock it, prepare to repoint.
- Recreate the platform account in the company’s name if the old one is gone, with two-factor.
- Deploy from the repository with the documented configuration; verify on the preview address.
- Restore data to a new database from the most recent tested backup; repoint the functions.
- Repoint DNS to the new deployment; confirm certificates issue.
- Restore monitoring and alerts, then verify forms, logins and integrations end to end.
- Write down what happened and what the test revealed, and fix the plan.
Testing the plan
Once a year, with the plan in hand, restore the site to a brand new account from the copies alone: repository, content export, media copy, database backup, documented configuration. Do not touch production. Time it against the target. Every question that arises is a gap in the plan, found at a cost of an afternoon rather than during an outage. On a well-built static site the test usually succeeds in under two hours and reveals one or two documentation gaps, which is exactly what it is for.
What this means for you
Disaster recovery for a small business website is one page and one yearly test. List each piece, where its copy is, who restores it and how fast. Decide how much loss and how much downtime are acceptable. Make sure every account in the plan is one your company can reach today. Then restore to a new account once, from the copies alone, and fix what the test finds. Nothing else about the plan matters if that test has never been run.
Frequently asked questions
Is disaster recovery different from backups?
Backups are copies. Recovery is the tested ability to turn copies into a working site within an agreed time. Businesses with backups and no recovery plan discover during the incident that the backup is incomplete, the domain is not theirs, nobody has the platform login or the restore takes three days. The plan closes those gaps in advance.
What counts as a disaster for a small website?
The platform account deleted or suspended, the domain lost or hijacked, the repository gone, a compromise that requires starting clean, a provider closing, or the one person with all the access unavailable. Each is rare; together they are not, and the same one-page plan covers them.
How long should recovery take?
Decide it from the business: how many hours of the site being down starts costing real money. For a small business site a target of a few hours is realistic on a modern stack and a day is acceptable. For a shop in peak season it is shorter. Write the number down and test against it.