A Backup You Have Never Restored Is Not a Backup
Almost every site we take over has backups configured. A meaningful share of those backups are unusable, and nobody knows because nobody has tried. Success emails are not evidence.
How backups fail while reporting success
- Database only. The plugin backs up content but not uploads, so a restore brings back the text and none of the images.
- Stored on the same server. If the server is the problem, so is the backup. Ransomware and hosting failures take both.
- Silently truncated. A memory or timeout limit cuts the archive short. The file exists and is corrupt.
- Retention too short. Seven days of backups is useless against a compromise you did not notice for two weeks.
- Credentials expired. The remote storage token rotated a year ago and the last successful upload predates it.
The test
Once a quarter, restore your most recent backup to a staging site and click around: homepage, a product or service page, a blog post with images, the contact form, and the admin dashboard. Note how long the whole thing took. That duration is your real recovery time, and it is the number to quote when someone asks how long a disaster would last.
What good looks like
- Daily automated backups of files and database.
- Stored off-server, in a location with separate credentials.
- 30 days of retention at minimum, more if you publish infrequently.
- An extra manual backup taken immediately before any update, migration, or launch.
- A documented restore procedure that someone other than the person who set it up can follow.
The uncomfortable question
If your site were wiped tonight, who would restore it, from where, and how long would it take? If the answer includes the phrase "I think the host does it," call the host today and ask them to confirm what is included, how far back it goes, and whether restores cost money. Some do. Finding that out during an outage is an expensive way to learn it.
