Three out of four sites we audit don't have a working backup. They think they do — there's a plugin installed, an old export file in cPanel, "the host backs us up." When the disaster hits, none of it works. This guide is what we deploy on every site we manage. It's costless, automated, off-site, tested, and recoverable in under 20 minutes.
The complete backup system
1. Why "my host backs me up" isn't enough
Three things go wrong with host-side backups consistently:
- They live on the same server. If the server dies, both site and backups die. We've seen this twice in 2025 alone — host hardware failure, all backups gone with the customer's data.
- They're rarely tested. Host backups are full server snapshots that may or may not restore cleanly. You only find out when you need them.
- They're slow to restore. Most host backups require opening a ticket, waiting hours, and getting the host's support team to do the restore. Meanwhile your site is down.
Treat host backups as a nice-to-have. Your real backup system needs to be independent.
2. The 3-2-1 rule
The industry standard for safe backup, originally from enterprise IT, applies perfectly to WordPress:
- 3 total copies of your data
- 2 different storage media (e.g., cloud + external drive)
- 1 off-site copy (cloud counts)
In practice for WordPress
(1) Live site on the host. (2) Automated backup plugin pushes daily backup to Google Drive or Dropbox. (3) Monthly full backup downloaded to your local machine or a separate cloud bucket. Three copies, two media types, two locations.
3. Tools we use
Free options
- UpdraftPlus (free version). Reliable, automated, can push to Google Drive, Dropbox, Amazon S3, OneDrive. Restore is one-click. We use this on small sites and starter projects.
- Duplicator (free). Better for migrations than scheduled backups. Free version requires manual triggering — fine for monthly archive snapshots.
- WP-CLI + cron + S3 (free if self-managed). For developers comfortable with command-line, scripted backups via WP-CLI cost only your S3 storage. Ultimate control. Painful for non-technical owners.
Paid options (worth the money)
- BlogVault — $89/yr per site. Daily incremental backups, off-site by default, one-click restore, staging environments included. Our default for client sites where downtime cost is real.
- UpdraftPlus Premium — $70+/yr. Adds incremental backups, multisite support, multiple destinations, encrypted backups.
- ManageWP / WP Umbrella — agency tools. Centralised dashboard for managing 50+ client sites with bundled backups. Pricing scales by site count.
4. Backup schedule by site type
- Brochure / lead-gen site (rarely changes): Weekly full backup. Daily database backup if you collect form submissions. Retain 4 weeks.
- Blog with regular publishing: Daily database backup. Weekly full backup. Retain 8 weeks.
- WooCommerce / membership site: Hourly database backup, daily full backup, retain 30 days. Order data is irreplaceable; spend the money on real-time backup if revenue justifies it.
- News / high-publishing site: Real-time database replication if possible. Daily full file backup. Retain 30 days.
5. Off-site storage: where backups go
Your backup destination matters as much as the backup itself. The right destinations:
- Google Drive (15 GB free, $2/mo for 100 GB). Easiest for non-technical clients. Familiar interface. Reliable.
- Dropbox. Same use case as Google Drive. 2 GB free, $12/mo for 2 TB.
- Amazon S3. The gold standard for off-site backup. Pay only for what you store (typically a few cents per month for a small site). Requires technical setup.
- Backblaze B2. S3-compatible, even cheaper. $0.005/GB/mo. Great for archive backups.
- Off-site disk (your local computer). One additional copy for true 3-2-1 compliance. Download a full backup once a month, store on a labelled external drive.
Don't backup to the same host
cPanel's "Generate Backup" or "JetBackup" stores backups on the same server as your site. If the server dies, both die together. They're useful as a fast first-line restore but they are not your real backup. Always have a copy somewhere outside your hosting account.
6. How to test a backup is actually working
An untested backup is theatre. Once a quarter, run the actual restore process on a staging environment:
- Spin up a staging site. Most hosts (SiteGround, Kinsta, WP Engine) offer one-click staging. Otherwise, create a clean WordPress install on a subdomain.
- Restore your latest backup to staging. Use the same plugin restore process you'd use in a real disaster.
- Verify everything works. Login, frontend pages, forms, payment processing (in test mode), media library. Anything broken means your backup is not actually a working backup.
- Document the restore time. If your restore takes 4 hours, that's your minimum recovery time. Plan accordingly.
7. Disaster recovery: restoring under pressure
When the disaster hits — site hacked, host down, accidental deletion — panic is the enemy. Have a runbook. The one we use:
- Stop and breathe. Most "disasters" are recoverable. Don't make hasty changes that destroy further data.
- Diagnose the source. Is the host down (check status page)? Is the site hacked (look at file modifications, suspicious cron tasks)? Is it a plugin conflict (check what was updated last)?
- If hacked: change all passwords first. WordPress admin, FTP, database, hosting account. Then restore.
- Restore from a known-clean backup. Pick the most recent backup before the issue started. Don't restore the latest if the latest is also infected.
- Verify the restore. Login, browse, check Search Console for security warnings, scan with Wordfence.
- Patch the cause. Update WordPress core, themes, plugins. Remove the vulnerable plugin if known. Apply hardening.
- Communicate. If the site was down for hours, post a brief notice. If user data was potentially exposed, notify users per GDPR / your jurisdiction's law.
8. Common mistakes that cost sites
- Storing backups in the same hosting account. Already covered. Off-site or it doesn't count.
- No retention policy. Some bugs are silent for weeks before discovery. If you only keep 7 days of backups and the bug started 14 days ago, you're stuck.
- Backups too large to download. If your backup is 12 GB, restoring it over a slow connection takes hours. Compress aggressively, exclude cache directories, exclude unused media.
- Untested restores. The single biggest failure mode. Test once a quarter minimum.
- Encrypted backups with no decryption key stored safely. If you encrypt backups (smart) but lose the key, the backup is dead. Store the key in a password manager separate from the backup.
- Database backup only, no files. The database has your content but the wp-content folder has all your themes, plugins, uploads. You need both.
Quick implementation (30 minutes)
Install UpdraftPlus → connect to Google Drive → schedule daily database + weekly file backup → retain 8 copies → run a test backup now → confirm files appear in Drive → schedule a quarterly restore test on staging. Done. Most sites we audit don't have this. You now do.
Frequently asked questions
How often should I back up my WordPress site?
Database: as often as the data changes meaningfully — daily for blogs, hourly for ecommerce. Files: weekly is fine for most sites since themes and plugins change less often. WooCommerce stores need real-time or near-real-time database replication because losing 24 hours of orders is catastrophic.
Are free backup plugins reliable enough?
UpdraftPlus free is reliable for most small-to-medium sites. The paid version adds incremental backups (faster, smaller) and useful agency features. Avoid abandoned or low-update plugins — your backup is only as reliable as the last release. Stick with plugins that ship updates monthly.
Should I encrypt my backups?
Yes if they contain customer data, payment information, or anything regulated. Most premium backup plugins offer encryption with a passphrase. Store the passphrase in a password manager (1Password, Bitwarden) — separate from the backup itself. Encrypting protects against the destination being compromised; storing the key alongside the backup defeats the purpose.
How long should I keep backups?
For active sites: 30 days minimum, 60–90 days ideal. Hidden bugs (database corruption, malware infections, gradual data loss) often aren't discovered for weeks. Keeping a longer chain of backups means you can find a clean version. Storage is cheap; data loss is expensive.
What if my host says "we have backups, you don't need any"?
Trust nothing without testing. Ask the host: how do I restore from your backup? How long does it take? Where are the backups stored? If the answer involves "open a ticket and wait" or "stored on the same server," supplement with your own backup system. Host backups are first-line; your independent backup is the safety net.
Can I just download a copy via FTP and that's enough?
A one-time FTP download is better than nothing but it's not a backup system. It's a single point in time. Real backups are scheduled, automated, retained, off-site, and tested. Manual FTP downloads also miss the database — which is where your content actually lives.