Knowledge · WordPress Web Design
WordPress Backups + Disaster Recovery: What Actually Works
‘Do you have a backup?’ is the worst conversation to have with a client whose site just went down. By that point, the answer doesn’t matter — either you do or you don’t, and the consequence is locked in. Here’s the backup architecture we use across every Care Plan client, with the tooling and the discipline that makes it work when you need it.
№ 01The three rules of a real backup
Rule 1: Daily, automated. Weekly isn’t enough — that’s 7 days of content / orders / form submissions you might lose. Manual isn’t enough — humans forget. Daily, scheduled, automatic.
Rule 2: Off-site. A backup on the same server as the site isn’t a backup. If the server is compromised, lost, or seized, both go down together. Backups belong on a different provider, ideally a different region.
Rule 3: Tested restores. A backup that has never been restored is a theory. Test the restore process quarterly. Confirm the data comes back clean. Most ‘we had backups’ horror stories are about backups that turned out to be corrupted, incomplete, or missing the database.
Skip any one of the three and the backup is theater.
№ 02The tools we trust
BlogVault ($89/yr): our default for Care Plan clients. Off-site by design (their servers), incremental (only changed files transfer), one-click restore, can clone to staging on their infrastructure. Background backup process is fast and doesn’t affect site performance.
UpdraftPlus Premium ($70/yr): alternative for clients who want backups in their own cloud storage (S3, Google Drive, Dropbox). More setup overhead, more control.
Solid Backups (formerly BackupBuddy, $99/yr): file-based, granular, supports remote storage. Good for self-hosted control freaks.
Duplicator Pro ($69/yr): we use this for one-shot site clones and migrations, not for ongoing backups. Different use case.
Native host backups (Kinsta daily, WP Engine daily): use them as a secondary, not primary. Same-provider backup = same-provider risk.
№ 03The backup architecture per Care Plan
Standard Care Plan: BlogVault daily off-site backups with 90-day retention. Plus the host’s native daily backup (Kinsta, WP Engine) as redundancy. Restore SLA: 4 business hours.
Pro Care Plan: BlogVault daily off-site + 4-hour incrementals for high-change sites. Plus host native. Plus weekly snapshot to a separate cloud account (S3 in a different region). Restore SLA: 1 business hour.
The Pro tier’s 4-hour incremental cadence matters when the site is an active content / commerce operation. A morning’s lost content matters; a day’s lost content is a real problem.
№ 04What actually gets backed up
Real WordPress backups cover four components:
- Database (all the content, settings, user data, options): the most important piece. Without this, the files are useless.
- WordPress core files: re-installable from wordpress.org but quicker to restore from backup.
- Themes and plugins: re-installable from sources but custom themes (yours) must be backed up.
- Uploads directory (
wp-content/uploads): all images, PDFs, media. Often the largest part of the backup.
Incremental backups handle this efficiently — only changed files transfer after the first full backup. A site with 4GB of media might transfer 50MB on a typical day.
№ 05Disaster recovery playbook
When the worst happens (site hacked, database corrupted, host outage, accidentally deleted half the content), here’s the order of operations:
- Don’t panic. Don’t restore on top of the broken site. Restoring on top of a hacked site reinfects the backup.
- Identify the last clean backup. Pre-incident, verified content matches expectation.
- Restore to a staging environment first. Verify the restore is clean and complete before touching production.
- If hack-related: rotate all credentials (WordPress admin, hosting, database, API keys) before bringing the restore live.
- Promote the staging restore to production. DNS or hosting-level swap.
- Monitor for 7 days. Reinfection from incomplete cleanup is common. Watch logs, traffic patterns, any anomalies.
Typical full restore time on a Care Plan: 2-6 hours depending on site size and the nature of the incident.
⚠What to avoid
- Trusting cPanel’s ‘automatic backup’ on shared hosting. They’re weekly at best, same-server, and often not actually complete. Not a backup.
- Storing backups on Google Drive only with no automation. Manual = forgotten. After 60 days, the ‘backups’ are 60 days old.
- Never testing the restore. The first time you discover the database wasn’t included in the backup is during a real incident. Test quarterly.
Related questions
Go deeper
Three Ways to Start · No Sales Pitch
Want this analyzed on your site?
$500 audit. 5-day delivery. Refundable on engagement.