A Backup Routine You Will Actually Test
Almost every site has backups. Far fewer have backups anyone has restored. The gap between those two is where data loss actually happens, and the fix is a drill rather than better software.
The short version
- A backup on the same server as the site is not a backup.
- Keep at least one copy offline and off-provider.
- Retention matters as much as frequency, because compromises are found late.
- Restore one to staging every quarter, on purpose.
What to back up
- Database. Every post, setting, user and order. Changes constantly.
- wp-content/uploads. Your media. Large, and rarely changes once uploaded.
- Themes and plugins. Reinstallable from source, except your custom theme.
- wp-config.php and server config. Small, critical, easily forgotten.
Core files do not need backing up. You can download a clean copy in seconds, and backing them up adds weight that makes restores slower.
Frequency by site type
| Site | Database | Files |
|---|---|---|
| Low-traffic blog | Daily | Weekly |
| Active publication | Daily | Daily |
| E-commerce | Hourly or continuous | Daily |
| Membership site | Hourly | Daily |
| Static brochure site | Weekly | Weekly |
The storage rule
Three copies, two different media or providers, one off-site. For a small site that is simpler than it sounds: the host’s automatic backup, a plugin or service pushing to separate cloud storage, and a monthly copy you download and keep.
Watch out
Host backups alone are a single point of failure. If the hosting account is suspended, compromised or billed incorrectly, you can lose access to both the site and its backups at the same moment.
Retention, which matters more than people think
Seven days of backups sounds reasonable until you discover a compromise that happened three weeks ago. By then every retained backup contains the backdoor.
- Daily backups kept for 30 days.
- Weekly backups kept for 3 months.
- Monthly backups kept for a year.
- A manual copy before any major change, kept until you are confident.
The quarterly drill
1. Pick a backup at random
Not the newest. You are testing the process, not the most convenient case.
2. Restore it to staging
Full restore: database and files.
3. Log in and click around
Home, a post, an archive, the admin. Does it work, and is the data current to the backup date?
4. Time it
How long did it take from decision to working site? That number is your real recovery time.
5. Write down what went wrong
Something always does — a missing credential, a plugin that needs reactivating. Fix it now, not during an incident.
What people get wrong
- Backing up to the same server, which fails exactly when you need it.
- Backing up the database but not uploads, then restoring a site with no images.
- Retention too short to cover a compromise discovered late.
- Never testing, and discovering during an incident that the archives are corrupt.
Common questions
Which backup plugin should I use?
Almost any established one works. What matters is where it stores copies, how long it keeps them, and whether you have restored one.
Is the host’s backup enough?
As one of the three copies, yes. As the only copy, no.
How long should a restore take?
For a small site, under thirty minutes. If you do not know your number, you have not tested.
Sumit
Writes everything on TechMozz.