Website Backup Strategy: What to Back Up and How Often
Most sites have backups. Fewer have backups that have been restored. The gap between the two is discovered at the worst possible moment, usually alongside the discovery that the backup was missing the database, or the uploads, or the last three weeks.
This guide covers what to back up, how often, where to keep it, and how to verify that a restore actually works.
What a complete backup contains#
A site is not one thing. Missing any of these makes a restore partial, and a partial restore is often worse than none because it looks like it worked.
- Database — content, users, orders, settings. The part that changes constantly.
- Uploaded files — images, documents, anything users or editors added.
- Application code — ideally in version control, which is a form of backup with history.
- Configuration — environment variables, server config, cron jobs, redirect rules.
- Certificates and DNS records — cheap to export, painful to reconstruct under pressure.
- Third-party settings — payment webhook URLs, email configuration, API keys.
Configuration is the part most often missed. A restored database and file set on a server configured differently is not the same site.
How often, and how long to keep#
Frequency follows from one question: how much work can you afford to lose? Retention follows from another: how long before you would notice a problem?
| Site type | Database | Files | Retention |
|---|---|---|---|
| Static brochure site | Weekly | Weekly | 30 days |
| Business site with a blog | Daily | Daily | 30–60 days |
| Busy content site | Daily, or hourly | Daily | 60–90 days |
| Online store | Hourly or continuous | Daily | 90+ days, and keep monthly archives |
| Web application | Continuous with point-in-time recovery | Daily | Per your data policy |
Retention matters because slow-moving problems exist. A corrupted import or a quiet compromise may not be noticed for weeks, by which time a 7-day rotation contains only bad copies.
Where to store them#
The classic rule still holds: three copies, on two kinds of media, with one off-site. Adapted for websites, it means the backup must survive both the server failing and the server being compromised.
- Never store the only copy on the same server as the site.
- Use a different provider for at least one copy, so a provider-level failure does not take both.
- Make at least one copy immutable or write-once, so credentials that run the site cannot delete it.
- Encrypt backups at rest — they contain everything, including personal data.
- Keep a monthly archive outside the rotation for slow-discovery problems.
- Document where they are and how to restore, somewhere that is not only on the site.
Testing: the step that makes it real#
A backup you have never restored is an assumption. Testing takes an hour and converts it into a fact.
- Restore to a separate staging environment, not over the live site.
- Check the database restored completely — count rows in the tables that matter.
- Check uploaded files are present, including recent ones.
- Log in and perform a real task: publish a page, place a test order.
- Time it. "How long would a restore take?" is a question you want answered in advance.
- Write down the procedure so it is not held only by the person who set it up.
- Repeat monthly, and after any change to the hosting setup.
Time the restore. Knowing it takes four hours changes what you promise stakeholders during an outage, and it is the number nobody has when they need it.
Frequently asked questions
Is my host’s backup enough?
It is a good baseline and a poor sole strategy. Host backups typically have short retention, are stored on the same infrastructure, and are lost along with the account if there is a billing dispute or a provider failure. Keep your own copy somewhere else — the cost is small and it is the copy you will need in the scenario where host backups do not help.
How long should I keep backups?
Long enough to cover a slow-discovery problem. Thirty days is a reasonable minimum, ninety is safer for a store, and a monthly archive kept for a year costs almost nothing. Balance that against data protection obligations — backups containing personal data are subject to retention rules too.
Do I need backups if my code is in version control?
Yes. Version control covers code and its history, and it does not contain the database, the uploaded files or the server configuration. Those are where the content and the customer data live, which is the part that cannot be recreated by re-running a deployment.
What is point-in-time recovery?
The ability to restore the database to any moment, rather than to the last scheduled snapshot — achieved by continuously archiving the transaction log. It matters when losing even an hour of orders is unacceptable. For a brochure site it is unnecessary; for a store taking orders through the night it is worth the extra setup.
website backupbackup strategydisaster recoveryrestore websitedatabase backupwebsite recovery
