Backups That Actually Restore: A Checklist for Small Websites
By ABD Web Tools Editorial · 2026-03-04 · 7 min read
Almost every site owner has backups of some kind. Far fewer have ever restored one. The gap between those two states is where data loss actually happens: the archive existed, but it was incomplete, corrupted, encrypted with a lost key or stored in the account that was compromised.
What a complete backup includes
A site is more than its database. Missing any of these turns a restore into a reconstruction project.
- The database, dumped consistently rather than copied from disk while running.
- User-uploaded files, which are usually the only irreplaceable part.
- Application code, if it is not fully reproducible from version control.
- Configuration and environment values, stored separately and encrypted.
- DNS records and certificate configuration, exported as text.
A retention schedule you can maintain
Daily backups kept for a fortnight, weekly kept for a quarter, monthly kept for a year. This shape covers both the mistake you notice within hours and the corruption you notice in month three, without unbounded storage growth.
Keep at least one copy in a different provider and a different account from production. A backup that lives inside the system it protects is not an offsite copy.
Advertisement
The rehearsal nobody schedules
Once a quarter, restore the most recent backup into a scratch environment and actually use the result: log in, load a page that reads uploaded files, run a report. Write down how long it took. That number is your real recovery time, and it is usually several times longer than people assume.
The rehearsal is also where you discover the missing environment variable, the file permissions that were never captured, or the database extension that has to be installed first.
Protecting the backups themselves
Encrypt archives at rest and store the key somewhere other than the backup destination. Use credentials that can write new files but not delete or overwrite existing ones, so an attacker who reaches production cannot destroy history. Enable versioning or an immutability window on the storage bucket where available.
Monitoring for silent failure
Backup jobs fail quietly. Alert on the absence of a successful run rather than on errors, and check the size of each archive against the previous one — a backup that suddenly shrinks by ninety per cent has been failing partway through for some time.
Frequently asked questions
Is my host's backup enough?
It is a good first layer, but it lives in the same account as your site. Keep an independent copy elsewhere so a billing dispute or account compromise cannot take both.
How often should I back up?
Ask how much work you are willing to redo. If the answer is one day, back up daily; if it is one hour, you need more frequent snapshots or continuous replication.
Do I need backups if I use version control?
Version control covers code. It does not cover the database, uploaded files or configuration, which is where the irreplaceable data lives.
How long should a restore take?
Whatever your rehearsal measured. Publish that figure internally so expectations during an incident match reality.
Advertisement
