Backups: what should be backed up, how often, and where
A backup is only worth what it can restore. What to include, how often each part needs it, where copies should live, and the one test that proves it works.
The short answer
A backup is worth exactly what it can restore, which gets found out at the worst moment. Good backups answer four questions in advance: what is included, how often each part is copied, where the copies live, and when it was last proven that a restore works. Anything less is a folder called “backup” and a hope.
What to back up
| What | Why it matters | Where it often is not |
|---|---|---|
| Database and content | The words, products, orders and settings that make the site yours | Provider backups only, retained for days |
| Uploaded files | Images, documents, media that cannot be regenerated | Forgotten because they are not “the database” |
| Form submissions and leads | Business records with legal retention needs | In a form service, never exported |
| Code repository | The site itself, buildable from source | On one developer’s laptop, or one hosting account |
| Configuration and secrets | Environment settings, API keys, integrations | In someone’s head, or in the hosting dashboard only |
| DNS records | The address book for site and email | Never exported; recreated from memory after an incident |
| Credentials to all of the above | Without them the backups are locked | A password manager nobody else can open |
How often
- Database, orders, submissions: daily at least. Hourly for a busy shop. This is where a day’s work lives.
- Uploaded files: daily. They change less, but each one is irreplaceable.
- Code: on every change. A repository does this by nature; make sure the repository itself is mirrored somewhere second.
- DNS and configuration: on every change, plus a monthly export. Small, cheap, and the first thing you need after an account problem.
- Retention: keep several generations. Daily copies for weeks, weekly for months, a monthly for a year, within your data rules. Late-discovered problems need old restore points.
Where
At least two places you control, one of them outside the hosting provider. Provider backups are convenient and share the provider’s failure modes: the account being suspended, the provider having an incident, the retention window passing. Your own copy in a separate storage account, in your company’s name, is the layer that survives all three.
The test that makes it real
Once a quarter, restore a backup to a test location and time it. Not “check that the file exists”: actually bring the site up from the copy, log in, open a recent order or article, confirm the uploads are there. The first time you do this, something is missing. Better to find that on a Tuesday in a test than on a Saturday after an incident.
What this means for you
Ask one question of whoever runs your site: “If everything was gone tomorrow morning, what would you restore, from where, and how long would it take?” A good answer names each item in the table, a location outside the provider, and a recent test. Anything vaguer is the item to fix this month, before it is needed.
Frequently asked questions
Our hosting provider does backups. Is that enough?
It is a good first layer and a poor only layer. Provider backups live inside the provider's account, share its failure modes, are kept for a limited window, and are not yours to take when you leave. Add your own copy, outside the provider, that you can restore without them.
What about a static website, is there anything to back up?
Less, which is one of its advantages. The source lives in a repository, which is versioned and can be cloned; the built site can be regenerated from it. What still needs backing up: the repository itself to a second location, form submissions and any database used by functions, uploaded media, DNS records and configuration.
How long should we keep backups?
Long enough to recover from problems you notice late. A corrupted database or a hacked site is often discovered weeks after it happened, so a single daily backup overwritten each night is useless then. Keep daily copies for a few weeks, weekly for a few months, and a monthly for a year, within what your data rules allow.
Who is responsible for backups?
One named party, in writing, with the schedule, the locations and the restore test in a document you can read. If the honest answer today is 'the hosting company, probably', the answer is nobody.