DEV Community

devautomation
devautomation

Posted on

WordPress backups: the strategy that actually protects client sites (most setups fail this test)

Most WordPress backup setups fail when they're needed most.

The plugin is running. The schedule is set. The backup "completed." But when the site breaks, the restore doesn't work -- or the backup was to the same hosting account that just got suspended.

Here's the backup strategy I use for client sites, and the three tests every backup needs to pass.


The three tests every backup must pass

Test 1: Can you restore it?
Most people never test restores. A backup you've never restored is a backup you don't have. Test quarterly minimum -- spin up a staging site, restore the backup, verify the site works.

Test 2: Is it off-server?
Backups on the same hosting account as the site protect against almost nothing. They don't protect against:

  • Hosting account compromise
  • Accidental file deletion that deletes backups too
  • Host-side data loss
  • Account suspension (you lose access to both the site and the backups)

Off-server means: a different cloud storage account (not on the same hosting provider), a different geographic region, ideally controlled by you -- not your hosting company.

Test 3: Is the database included?
Files without database = WordPress installation without any content, users, orders, or settings. Always verify the backup includes the database, not just the wp-content folder.


The backup layers for client sites

A robust backup strategy has three layers:

Layer 1: Daily automated backup (plugin-based)

For most client sites, a good backup plugin configured correctly is sufficient:

  • UpdraftPlus (free) -- backs up to Google Drive, Dropbox, S3, or FTP. Free tier works for most sites.
  • BackWPup (free) -- similar feature set, good S3 support
  • BlogVault (paid, ~$9/month) -- includes incremental backups and one-click restores. Worth it for WooCommerce sites.

What to configure:

Full backup schedule: daily (WooCommerce) or weekly (static sites)
Database only: every 4-6 hours for WooCommerce
Retention: 30 days minimum
Destination: external storage ONLY (not hosting account)
Enter fullscreen mode Exit fullscreen mode

Layer 2: Pre-update snapshot

Before any major update (core version, WooCommerce, theme), take a manual backup first.

Via WP-CLI:

# Database backup
wp --allow-root db export pre_update_$(date +%Y%m%d).sql

# Zip wp-content for file backup
cd /var/www/html/
zip -r wp-content-backup-$(date +%Y%m%d).zip wp-content/
Enter fullscreen mode Exit fullscreen mode

Store somewhere accessible. This takes 2 minutes. A broken update that you can roll back in 5 minutes is a non-event. A broken update you can't roll back is an emergency.

Layer 3: Hosting-level snapshots

Many hosts (Kinsta, WP Engine, SiteGround, Cloudways) offer server-level snapshots that capture the full server state. These are separate from your plugin backups.

Enable them if your host offers them. They're a third layer, not a replacement for plugin backups -- hosting snapshots are in the same account, which means they fail Test 2.


Storage destinations ranked

Best: Amazon S3 (separate AWS account)

  • Unlimited storage, cheap ($0.023/GB/month)
  • IAM user with write-only access for security (compromise of WP server can't delete the backups)
  • Works with UpdraftPlus, BackWPup, most backup plugins

Good: Google Drive or Dropbox (personal account)

  • Easy to set up
  • Storage limits apply (15GB Google Drive free tier)
  • Fine for small sites

Avoid: FTP to same hosting account

  • Fails Test 2 -- same account, same risk
  • Often slower than cloud storage

Avoid: Local server folder

  • Worst option -- same server, fails Test 2, doesn't survive server hardware failure

WooCommerce: higher stakes, different schedule

WooCommerce sites need more frequent database backups because orders come in continuously.

Recommended schedule:

Full backup (files + database): daily, off-peak hours
Database only backup: every 4 hours
Pre-update snapshot: before every WooCommerce update
Retention: 60 days (for order history disputes)
Enter fullscreen mode Exit fullscreen mode

One missed order because of a failed restore is an angry customer and potentially a chargeback. The backup cost is trivial compared to the risk.

Also back up separately:

  • Payment gateway configuration (export settings from WooCommerce -> Settings -> Payments)
  • Shipping zone configuration
  • Tax tables

These aren't in the database and can be a nightmare to reconstruct from memory.


Automating backup verification

Manual backup verification is fine but easy to skip. My automation script runs a basic check after every backup:

# Check if backup completed in last 24 hours (for UpdraftPlus)
LAST_BACKUP=$(wp --allow-root option get updraft_last_backup 2>/dev/null)
YESTERDAY=$(date -d "yesterday" +%s)

if [ -z "$LAST_BACKUP" ] || [ "$LAST_BACKUP" -lt "$YESTERDAY" ]; then
    echo "WARNING: No backup in last 24 hours on $(hostname)"
    # Send alert email
fi
Enter fullscreen mode Exit fullscreen mode

For a hosted setup, BlogVault and ManageWP both send alerts if a backup fails. Worth the price for peace of mind across many client sites.


The backup conversation with clients

Many clients don't know their backup situation. First thing I do on a new client site:

  1. Check if any backup plugin is installed
  2. Check where it's backing up to
  3. Check the last successful backup date
  4. Check the retention period

Most sites I've taken over have backups configured to the same hosting account, running weekly, with 7-day retention. That's three failure points: wrong destination, too infrequent, too short retention.

I update the configuration and document it in my client onboarding notes. When something goes wrong at 11pm on a Friday, I know exactly where the backup is and how to restore it.


The restore procedure (test this NOW)

For UpdraftPlus:

  1. WP Admin -> UpdraftPlus -> Existing Backups
  2. Select backup set
  3. Choose components (database + plugins + themes + uploads)
  4. Click Restore
  5. Confirm

For WP-CLI (database):

wp --allow-root db import backup_file.sql
wp --allow-root cache flush
Enter fullscreen mode Exit fullscreen mode

For WP-CLI (files):

# Restore wp-content from zip
cd /var/www/html/
unzip -o wp-content-backup.zip
Enter fullscreen mode Exit fullscreen mode

Test this on a staging environment so you know the procedure works before you need it under pressure.


The free monthly maintenance checklist includes a backup verification section:

WordPress Monthly Maintenance Checklist -- free download.

The automation bundle includes backup verification scripts that check your last backup date and alert you if backups are failing:
WordPress Agency Automation Bundle


Related articles

All paid tools: devautomation.gumroad.com


What's your backup setup for client sites -- UpdraftPlus, BlogVault, or something else?

Top comments (0)