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

the hosting provider.

• Recommended Destination: Amazon S3 hosted in a dedicated AWS account.
• Cost Efficiency: S3 Standard storage costs approximately $0.023/GB/month, making off-site storage economically viable for any scale.
• Security Implementation: Create an IAM user with a policy that grants PutObject permissions but explicitly denies DeleteObject and GetObject. This ensures that even if the WordPress server is compromised, the attacker cannot delete or exfiltrate the backups.

2. Layered Execution Strategy

Layer 1: Automated Plugin-Based Backups Use a reliable backup plugin to handle the routine scheduling.

• Tools: UpdraftPlus, BackWPup, or BlogVault.
• Configuration:
  • Static Sites: Full backup weekly; retention 30 days.
  • WooCommerce: Full backup daily; database-only backup every 4 hours; retention 60 days.
  • Destination: Enforce external storage only. Disable local retention after upload to save disk space.

Layer 2: Pre-Update Atomic Snapshots Before any core update, plugin update, or theme change, create an immediate, manual snapshot. This allows for instant rollback without waiting for the next scheduled backup cycle.

Implementation Script: The following Bash script automates pre-update snapshots using WP-CLI. It exports the database, archives wp-content, generates checksums for integrity verification, and uploads to a remote destination.

#!/bin/bash
# wp-pre-update-snapshot.sh
# Usage: ./wp-pre-update-snapshot.sh <site_path> <remote_dest>

set -euo pipefail

SITE_PATH="${1:?Error: Site path required}"
REMOTE_DEST="${2:?Error: Remote destination required}"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
BACKUP_DIR="/tmp/wp-snapshot-${TIMESTAMP}"

echo "Starting pre-update snapshot for ${SITE_PATH}..."

# Create temporary directory
mkdir -p "${BACKUP_DIR}"

# Export Database
echo "Exporting database..."
wp --path="${SITE_PATH}" db export "${BACKUP_DIR}/db-${TIMESTAMP}.sql" --quiet

# Archive wp-content
echo "Archiving wp-content..."
tar -czf "${BACKUP_DIR}/wp-content-${TIMESTAMP}.tar.gz" -C "${SITE_PATH}" wp-content

# Generate Checksums
echo "Generating integrity checksums..."
sha256sum "${BACKUP_DIR}"/* > "${BACKUP_DIR}/checksums.sha256"

# Upload to Remote Storage (Example using AWS CLI)
echo "Uploading to ${REMOTE_DEST}..."
aws s3 sync "${BACKUP_DIR}" "${REMOTE_DEST}/${TIMESTAMP}" --profile backup-profile

# Cleanup
rm -rf "${BACKUP_DIR}"

echo "Snapshot complete. Archive ID: ${TIMESTAMP}"

Layer 3: Hosting-Level Snapshots Many managed hosts (Kinsta, WP Engine, Cloudways) provide server-level snapshots. Enable these as a convenience layer. However, treat them as secondary. Since they reside within the hosting provider's infrastructure, they do not satisfy the isolation requirement of Layer 1.

3. WooCommerce Specific Considerations

WooCommerce introduces higher stakes due to continuous transactional data.

• Database Frequency: Configure database-only backups every 4 hours. A missed order due to a failed restore can result in chargebacks and customer loss.
• Configuration Export: Database backups capture orders and products, but payment gateway settings, shipping zones, and tax tables may require separate export for rapid reconstruction.
  • Action: Periodically export WooCommerce settings via WooCommerce > Settings > Export/Import and store these JSON files alongside the backup archive.

4. Automated Verification

Manual verification is prone to human error. Implement an automated check that validates backup freshness.

Verification Logic: A cron job or monitoring service should query the backup plugin's status and alert if the last successful backup exceeds the expected interval.

// wp-cli command to verify backup status
// Usage: wp backup verify --plugin=updraftplus

function verify_backup_freshness($args) {
    $last_backup = get_option('updraft_last_backup');
    if (!$last_backup) {
        WP_CLI::error('No backup record found.');
    }

    $threshold = strtotime('-25 hours');
    if ($last_backup < $threshold) {
        WP_CLI::warning('Backup is stale. Last run: ' . date('Y-m-d H:i:s', $last_backup));
        // Trigger alert mechanism
        wp_mail('admin@example.com', 'Backup Alert', 'Stale backup detected.');
    } else {
        WP_CLI::success('Backup is fresh.');
    }
}

Pitfall Guide

1. The Co-Location Fallacy

   • Mistake: Storing backups on the same hosting account or using the host's S3 bucket.
   • Risk: Hosting suspension, account compromise, or provider outage destroys both site and backup.
   • Fix: Use a separate cloud storage account with independent credentials.

2. Unvalidated Restore Procedures

   • Mistake: Assuming a "Success" message guarantees a restorable archive.
   • Risk: Corrupted archives or missing database tables discovered only during a crisis.
   • Fix: Perform a quarterly restore test on a staging environment. Verify site functionality post-restore.

3. Over-Privileged Storage Access

   • Mistake: Granting backup plugins full read/write/delete access to the storage bucket.
   • Risk: Malware or ransomware on the WordPress server can delete backups.
   • Fix: Implement IAM policies with write-only permissions. Backups should be immutable from the application side.

4. WooCommerce Configuration Drift

   • Mistake: Relying solely on database backups for WooCommerce recovery.
   • Risk: Payment gateway tokens or shipping configurations may be lost or difficult to reconstruct.
   • Fix: Export and store WooCommerce settings files separately. Maintain documentation of gateway credentials.

5. Insufficient Retention Windows

   • Mistake: Defaulting to 7-day retention.
   • Risk: Corruption or data loss may not be detected immediately. Short retention limits recovery options.
   • Fix: Enforce minimum 30-day retention for standard sites and 60 days for WooCommerce to cover dispute windows.

6. Host Snapshot Dependency

   • Mistake: Relying exclusively on hosting provider snapshots.
   • Risk: Snapshots are tied to the hosting account. If the account is lost, snapshots are inaccessible.
   • Fix: Use host snapshots for quick rollbacks, but maintain independent off-site backups for disaster recovery.

7. Ignoring Database Integrity

   • Mistake: Backing up files only or excluding the database.
   • Risk: Restoration results in a blank site with no content, users, or settings.
   • Fix: Always verify that backup configurations include the database. For WooCommerce, prioritize database frequency.

Production Bundle

Action Checklist

• Audit Storage Location: Verify all backups are stored in a separate cloud account, not the hosting provider.
• Implement IAM Restrictions: Create write-only IAM policies for backup storage destinations.
• Configure Retention: Set retention to 30 days minimum; 60 days for WooCommerce.
• Schedule Database Backups: For transactional sites, configure database-only backups every 4 hours.
• Export WooCommerce Settings: Save payment, shipping, and tax configurations to external storage.
• Test Restore Procedure: Perform a full restore on a staging site and verify functionality.
• Enable Verification Alerts: Configure monitoring to alert on backup failures or stale archives.
• Document Recovery Steps: Maintain a runbook for manual restoration via WP-CLI.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Static Marketing Site	Weekly full backup to S3; 30-day retention	Low change frequency; minimal data loss risk.	Low ($0.023/GB)
WooCommerce Store	Daily full + DB every 4h; 60-day retention; IAM write-only	High transaction volume; compliance requirements.	Moderate (Storage + Plugin license)
High-Traffic Blog	Daily backup; Pre-update snapshots; Separate S3 account	Frequent updates; content value.	Low
Agency Client Portfolio	BlogVault or ManageWP for centralized management	Multi-site oversight; automated reporting.	Higher (SaaS subscription)

Configuration Template

IAM Policy for Write-Only S3 Access Apply this policy to the IAM user used by your backup plugin to ensure backups cannot be deleted by the WordPress application.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowWriteOnlyAccess",
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": "arn:aws:s3:::your-backup-bucket-name/*"
        },
        {
            "Sid": "AllowListBucketForVerification",
            "Effect": "Allow",
            "Action": [
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::your-backup-bucket-name",
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        ""
                    ]
                }
            }
        }
    ]
}

Quick Start Guide

1. Create Storage: Set up an S3 bucket in a dedicated AWS account. Note the bucket ARN.
2. Create IAM User: Generate an IAM user and attach the write-only policy template above. Secure the access keys.
3. Install Plugin: Install UpdraftPlus or BackWPup on the WordPress site.
4. Configure Destination: Enter S3 credentials in the plugin settings. Set schedule to daily and retention to 30 days.
5. Validate: Run a manual backup. Verify the file appears in S3. Perform a test restore on a staging environment to confirm integrity.