Backups and Disaster Recovery
Every website eventually faces a bad day: a botched update, a hacked account, a deleted database, a failed drive, or a hosting outage. Backups are what turn that bad day into an inconvenience instead of a catastrophe. They are the last line of defense, and treating them as non-negotiable is one of the clearest marks of a professionally run site.
Backup types
Backups generally take one of three forms, often used in combination:
- Full backup — a complete copy of the site’s files and database. Simplest to restore from, but the largest and slowest to create.
- Incremental backup — captures only what changed since the last backup of any kind. Fast and storage-efficient, but a restore must replay a chain of increments.
- Differential backup — captures everything changed since the last full backup. A middle ground: larger than incremental, but simpler to restore.
A common pattern is a periodic full backup supplemented by frequent incrementals between them.
Frequency
How often to back up should follow how often the site changes. A busy store taking orders may need hourly or continuous backups, while a static brochure site might do fine with weekly ones. Two concepts frame the decision:
- Recovery Point Objective (RPO) — how much data you can afford to lose, measured in time. An hourly backup means losing at most an hour of changes.
- Recovery Time Objective (RTO) — how quickly the site must be back online after an incident.
Set backup frequency so that the RPO is tolerable for the business, not just convenient for the server.
Offsite and independent storage
A backup stored only on the same server as the live site is barely a backup at all — if that server is compromised, corrupted, or destroyed, the backup goes with it. Reliable practice keeps copies offsite, in a separate system and ideally a different geographic location, so a single failure cannot take out both the site and its safety net. A widely cited guideline is to keep multiple copies across more than one medium or location, with at least one copy held offsite.
Retention matters too: keeping a rolling window of past backups means a problem that goes unnoticed for days can still be rolled back to a clean point.
Test the restore
The single most overlooked discipline is restore testing. A backup that has never been restored is an assumption, not a safeguard — silent corruption, missing databases, or incomplete file sets are routinely discovered only when someone tries to recover in a real emergency. Periodically restoring a backup to a staging environment and confirming the site actually works is what turns a backup into genuine protection.
Disaster recovery basics
Disaster recovery is the plan around the backups. At minimum it means:
- Documented steps for restoring the site, so recovery does not depend on one person’s memory under pressure.
- Independent recovery paths — backups reachable even if the primary hosting account is locked or lost.
- Clear ownership of who acts when something breaks, and how.
Good backups combined with a rehearsed recovery plan mean that hacks, failed updates, human error, and hardware failure become recoverable events rather than existential ones.
For the environments used to test restores, see Staging Environments; for the security failures backups guard against, see SSL and Website Security; and for the risks around moving a site, see Website Migrations.
