A WordPress deployment pipeline automates the entire process—code changes flow from development through testing to production automatically, with safety checks, automated testing, rollback capability, and zero downtime. Deploy confidently dozens of times per day.

In this guide, you’ll build a complete WordPress deployment pipeline using WP-CLI and Bash, from basic scripts to production-ready systems used by professional WordPress development teams.

Why Build a Deployment Pipeline?

Manual WordPress deployments don’t scale and introduce human error at every step.

Problems with Manual Deployment

Error-prone: Manual file transfers and database updates cause mistakes.

Downtime: Sites go offline during deployments affecting users and revenue.

No testing: Changes deploy directly to production without validation.

Slow: Manual deployments take 30-60 minutes of focused work.

No rollback: Fixing failed deployments requires manual restoration from backups.

Deployment Pipeline Benefits

Automated: One command deploys entire release from development to production.

Zero downtime: Users never see maintenance pages or errors.

Tested: Automated tests catch issues before they reach production.

Fast: Complete deployments in under 5 minutes instead of hours.

Reversible: Instant rollback to previous version if issues occur.

According to DevOps Research, teams with deployment pipelines deploy 200x more frequently with 24x faster recovery times.

Deployment Pipeline Components

Understand the stages of a WordPress deployment pipeline.

Basic Pipeline Stages

1. Development  → Code changes made locally
2. Testing      → Automated tests verify changes
3. Staging      → Deploy to staging environment
4. Validation   → Manual/automated verification
5. Production   → Deploy to live site
6. Monitoring   → Track deployment health

Essential Pipeline Elements

Version Control: Git tracks all changes and enables rollback.

Database Migrations: Automated schema and data updates.

Asset Building: Compile CSS, minify JavaScript, optimize images.

Environment Config: Different settings for dev/staging/production.

Health Checks: Verify deployment succeeded before completing.

Rollback Strategy: Quick recovery from failed deployments.

Learn about continuous deployment principles.

Basic Deployment Script

Start with a simple automated deployment workflow.

Manual Deployment Process

#!/bin/bash
# deploy-wordpress.sh - Basic deployment script

set -euo pipefail

REPO_URL="git@github.com:yourcompany/wordpress-site.git"
DEPLOY_PATH="/var/www/production"
BRANCH="main"

cd "$DEPLOY_PATH"

echo "Starting deployment..."

# Pull latest code
git fetch origin
git reset --hard "origin/$BRANCH"

# Install/update dependencies
composer install --no-dev --optimize-autoloader

# Run database migrations
wp db migrate

# Clear caches
wp cache flush
wp rewrite flush

# Build assets (if needed)
npm run build

echo "✓ Deployment complete"

Deployment with Backup

#!/bin/bash
# deploy-with-backup.sh

set -euo pipefail

DEPLOY_PATH="/var/www/production"
BACKUP_DIR="/backups/deployments"
DATE=$(date +%Y%m%d_%H%M%S)

cd "$DEPLOY_PATH"

# Create pre-deployment backup
echo "Creating backup..."
mkdir -p "$BACKUP_DIR"

wp db export "$BACKUP_DIR/db-$DATE.sql.gz"
git rev-parse HEAD > "$BACKUP_DIR/git-commit-$DATE.txt"

# Deploy
echo "Deploying..."
git pull origin main

composer install --no-dev

# Database updates
wp db migrate || {
    echo "Migration failed, rolling back..."
    wp db import "$BACKUP_DIR/db-$DATE.sql.gz"
    git reset --hard $(cat "$BACKUP_DIR/git-commit-$DATE.txt")
    exit 1
}

# Clear caches
wp cache flush

echo "✓ Deployment complete"
echo "Backup: $BACKUP_DIR/db-$DATE.sql.gz"

Staging to Production Pipeline

Deploy changes from staging environment to production safely.

Complete Staging Deploy

#!/bin/bash
# deploy-staging-to-production.sh

set -euo pipefail

STAGING_PATH="/var/www/staging"
PROD_PATH="/var/www/production"
BACKUP_DIR="/backups/production"
DATE=$(date +%Y%m%d_%H%M%S)

echo "=== Staging to Production Deployment ==="

# Step 1: Backup production
echo "Step 1/6: Backing up production..."
cd "$PROD_PATH"

wp db export "$BACKUP_DIR/db-$DATE.sql.gz"
tar -czf "$BACKUP_DIR/files-$DATE.tar.gz" \
    wp-content/plugins \
    wp-content/themes \
    wp-content/uploads

echo "✓ Backup complete"

# Step 2: Get staging code version
echo "Step 2/6: Getting staging version..."
cd "$STAGING_PATH"
STAGING_COMMIT=$(git rev-parse HEAD)
echo "Staging commit: $STAGING_COMMIT"

# Step 3: Deploy code to production
echo "Step 3/6: Deploying code..."
cd "$PROD_PATH"

# Enable maintenance mode
wp maintenance-mode activate

git fetch origin
git reset --hard "$STAGING_COMMIT"

# Step 4: Install dependencies
echo "Step 4/6: Installing dependencies..."
composer install --no-dev --no-interaction

# Build assets
npm run build

# Step 5: Run database migrations
echo "Step 5/6: Running database migrations..."
if ! wp db migrate; then
    echo "✗ Migration failed, rolling back..."
    wp db import "$BACKUP_DIR/db-$DATE.sql.gz"
    wp maintenance-mode deactivate
    exit 1
fi

# Step 6: Final checks and cleanup
echo "Step 6/6: Final checks..."

# Verify WordPress works
if ! wp core is-installed; then
    echo "✗ WordPress check failed, rolling back..."
    wp db import "$BACKUP_DIR/db-$DATE.sql.gz"
    wp maintenance-mode deactivate
    exit 1
fi

# Clear caches
wp cache flush
wp rewrite flush

# Disable maintenance mode
wp maintenance-mode deactivate

echo "=== Deployment Complete ==="
echo "Deployed commit: $STAGING_COMMIT"
echo "Backup: $BACKUP_DIR/db-$DATE.sql.gz"

Automated Validation

#!/bin/bash
# validate-deployment.sh

SITE_URL="$1"

echo "Validating deployment..."

# Test homepage
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL")
if [ "$HTTP_CODE" != "200" ]; then
    echo "✗ Homepage failed: HTTP $HTTP_CODE"
    exit 1
fi
echo "✓ Homepage accessible"

# Test admin
ADMIN_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL/wp-admin/")
if [ "$ADMIN_CODE" != "200" ] && [ "$ADMIN_CODE" != "302" ]; then
    echo "✗ Admin failed: HTTP $ADMIN_CODE"
    exit 1
fi
echo "✓ Admin accessible"

# Test critical pages
for PAGE in "/about" "/contact" "/shop"; do
    CODE=$(curl -s -o /dev/null -w "%{http_code}" "$SITE_URL$PAGE")
    if [ "$CODE" = "200" ]; then
        echo "✓ $PAGE accessible"
    else
        echo "⚠ $PAGE returned HTTP $CODE"
    fi
done

echo "✓ Validation complete"

Zero-Downtime Deployment

Deploy without taking the site offline.

Symlink Strategy

#!/bin/bash
# zero-downtime-deploy.sh

set -euo pipefail

DEPLOY_BASE="/var/www/releases"
CURRENT_LINK="/var/www/current"
SHARED_DIR="/var/www/shared"
RELEASE_ID=$(date +%Y%m%d_%H%M%S)
RELEASE_PATH="$DEPLOY_BASE/$RELEASE_ID"

echo "=== Zero-Downtime Deployment ==="
echo "Release ID: $RELEASE_ID"

# Create new release directory
mkdir -p "$RELEASE_PATH"
cd "$RELEASE_PATH"

# Clone code
git clone --depth 1 git@github.com:yourcompany/site.git .

# Link shared directories
ln -s "$SHARED_DIR/wp-content/uploads" wp-content/uploads
ln -s "$SHARED_DIR/wp-config.php" wp-config.php

# Install dependencies
composer install --no-dev

# Build assets
npm run build

# Database migrations (on shared database)
cd "$SHARED_DIR"
wp db migrate --path="$RELEASE_PATH"

# Atomic switch to new release
ln -sfn "$RELEASE_PATH" "$CURRENT_LINK"

# Webserver points to /var/www/current

# Cleanup old releases (keep last 5)
cd "$DEPLOY_BASE"
ls -t | tail -n +6 | xargs rm -rf

echo "✓ Deployment complete"
echo "Current release: $RELEASE_ID"

Blue-Green Deployment

#!/bin/bash
# blue-green-deploy.sh

BLUE_PATH="/var/www/blue"
GREEN_PATH="/var/www/green"
CURRENT_LINK="/var/www/current"

# Determine inactive environment
if [ "$(readlink $CURRENT_LINK)" = "$BLUE_PATH" ]; then
    INACTIVE="$GREEN_PATH"
    INACTIVE_NAME="green"
else
    INACTIVE="$BLUE_PATH"
    INACTIVE_NAME="blue"
fi

echo "Deploying to inactive environment: $INACTIVE_NAME"

cd "$INACTIVE"

# Deploy to inactive
git pull origin main
composer install --no-dev
npm run build

# Test inactive environment
if curl -f "http://localhost:8080" > /dev/null 2>&1; then
    echo "✓ Inactive environment healthy"
else
    echo "✗ Inactive environment failed health check"
    exit 1
fi

# Switch traffic to new version
ln -sfn "$INACTIVE" "$CURRENT_LINK"

# Reload webserver
systemctl reload nginx

echo "✓ Switched to $INACTIVE_NAME environment"

Learn about zero-downtime deployment strategies.

Database Migration Handling

Safely manage database schema changes during deployments.

Migration System

#!/bin/bash
# db-migrate.sh - Run database migrations

MIGRATIONS_DIR="/var/www/db/migrations"
APPLIED_FILE="/var/www/db/applied-migrations.txt"

touch "$APPLIED_FILE"

echo "Running database migrations..."

for MIGRATION in $(ls "$MIGRATIONS_DIR"/*.sql | sort); do
    MIGRATION_NAME=$(basename "$MIGRATION")

    # Check if already applied
    if grep -q "$MIGRATION_NAME" "$APPLIED_FILE"; then
        echo "⊘ Skipping: $MIGRATION_NAME (already applied)"
        continue
    fi

    echo "Applying: $MIGRATION_NAME"

    # Run migration
    if wp db query < "$MIGRATION"; then
        echo "$MIGRATION_NAME" >> "$APPLIED_FILE"
        echo "✓ Applied: $MIGRATION_NAME"
    else
        echo "✗ Failed: $MIGRATION_NAME"
        exit 1
    fi
done

echo "✓ All migrations applied"

Reversible Migrations

# Migration file structure
# migrations/001-add-custom-table.sql (up)
# migrations/001-add-custom-table-rollback.sql (down)

#!/bin/bash
# rollback-migration.sh

MIGRATION_ID="$1"
MIGRATIONS_DIR="/var/www/db/migrations"

ROLLBACK_FILE="$MIGRATIONS_DIR/${MIGRATION_ID}-rollback.sql"

if [ ! -f "$ROLLBACK_FILE" ]; then
    echo "✗ Rollback file not found: $ROLLBACK_FILE"
    exit 1
fi

echo "Rolling back migration: $MIGRATION_ID"
wp db query < "$ROLLBACK_FILE"

echo "✓ Rollback complete"

Deployment Notifications

Alert teams about deployment status.

Slack Notifications

#!/bin/bash
# notify-deployment.sh

SLACK_WEBHOOK="https://hooks.slack.com/services/YOUR/WEBHOOK/URL"
STATUS="$1"  # success or failure
COMMIT="$2"
DEPLOYER="$3"

if [ "$STATUS" = "success" ]; then
    COLOR="good"
    MESSAGE="Deployment successful"
else
    COLOR="danger"
    MESSAGE="Deployment failed"
fi

curl -X POST "$SLACK_WEBHOOK" \
    -H 'Content-Type: application/json' \
    -d "{
        \"attachments\": [{
            \"color\": \"$COLOR\",
            \"title\": \"$MESSAGE\",
            \"fields\": [
                {\"title\": \"Environment\", \"value\": \"Production\", \"short\": true},
                {\"title\": \"Commit\", \"value\": \"$COMMIT\", \"short\": true},
                {\"title\": \"Deployed by\", \"value\": \"$DEPLOYER\", \"short\": true}
            ]
        }]
    }"

Email Notifications

#!/bin/bash
# email-deployment-report.sh

EMAIL="team@example.com"
STATUS="$1"
DETAILS="$2"

SUBJECT="WordPress Deployment $STATUS"

cat <<EOF | mail -s "$SUBJECT" "$EMAIL"
WordPress Deployment Report
===========================

Status: $STATUS
Time: $(date)
Server: $(hostname)
Deployed by: $(whoami)

Details:
$DETAILS

Automated deployment system
EOF

Complete Production Pipeline

Integrate all components into a complete system.

Master Deployment Script

#!/bin/bash
# deploy.sh - Complete deployment pipeline

set -euo pipefail

ENVIRONMENT="${1:-staging}"
LOG_FILE="/var/log/deployments/deploy-$(date +%Y%m%d-%H%M%S).log"

mkdir -p "$(dirname $LOG_FILE)"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $@" | tee -a "$LOG_FILE"
}

notify() {
    ./notify-deployment.sh "$1" "$2" "$(whoami)"
}

log "=== Deployment Started ==="
log "Environment: $ENVIRONMENT"

# Pre-deployment checks
log "Running pre-deployment checks..."
./pre-deploy-check.sh "$ENVIRONMENT" || {
    log "✗ Pre-deployment checks failed"
    notify "failure" "Pre-deployment checks failed"
    exit 1
}

# Backup
log "Creating backup..."
./backup.sh "$ENVIRONMENT"

# Deploy code
log "Deploying code..."
./deploy-code.sh "$ENVIRONMENT" || {
    log "✗ Code deployment failed"
    ./rollback.sh "$ENVIRONMENT"
    notify "failure" "Code deployment failed"
    exit 1
}

# Database migrations
log "Running database migrations..."
./db-migrate.sh || {
    log "✗ Database migration failed"
    ./rollback.sh "$ENVIRONMENT"
    notify "failure" "Database migration failed"
    exit 1
}

# Post-deployment validation
log "Validating deployment..."
./validate-deployment.sh "$ENVIRONMENT" || {
    log "✗ Validation failed"
    ./rollback.sh "$ENVIRONMENT"
    notify "failure" "Deployment validation failed"
    exit 1
}

# Success
log "=== Deployment Complete ==="
notify "success" "Deployment to $ENVIRONMENT successful"

echo "✓ Deployment successful"
echo "Log: $LOG_FILE"

Next Steps

You now have a complete WordPress deployment pipeline built with WP-CLI and Bash.

Recommended Learning Path

Week 1: Basic automation

• Create simple deploy scripts
• Add backup mechanisms
• Implement rollback procedures

Week 2: Testing integration

• Add validation checks
• Create health checks
• Automate testing

Week 3: Zero-downtime

• Implement symlink strategy
• Set up blue-green deployment
• Test switching mechanisms

Week 4: Production hardening

• Add monitoring
• Implement notifications
• Document procedures

Advanced Topics

1. Container Deployments – Docker-based pipelines
2. GitOps Workflows – Git-driven deployments
3. Multi-Region Deployment – Global site deployment

Get More Resources

Download deployment scripts including:

• Complete pipeline system
• Testing frameworks
• Rollback automation

Join our email course for:

• Weekly WP-CLI tutorials
• DevOps best practices
• Deployment strategies

Conclusion

A WordPress deployment pipeline transforms risky manual deployments into reliable, automated workflows that enable rapid, confident releases to production.

What we covered:

✅ Deployment pipeline components and stages
✅ Basic deployment automation with backups
✅ Staging to production workflows
✅ Zero-downtime deployment strategies
✅ Database migration handling
✅ Complete production pipeline integration

Master these techniques, and you’ll deploy WordPress changes confidently dozens of times per day with zero downtime and instant rollback capability.

Ready for more? Learn continuous integration or infrastructure as code.

Questions about WordPress deployment pipelines? Drop a comment below!

Found this helpful? Share with other WordPress DevOps teams.

The post Build a WordPress Deployment Pipeline with WP-CLI and Bash appeared first on WP-CLI Mastery.

WP-CLI lets you update all plugins and themes across unlimited WordPress sites from your terminal—in minutes instead of hours. Add safety checks, automatic backups, and rollback capabilities, and you have enterprise-grade update automation.

In this guide, you’ll learn professional techniques for bulk updating WordPress installations safely, including pre-update backups, staged rollouts, and automated testing used by WordPress agencies managing hundreds of sites.

Why Bulk Update with WP-CLI?

WordPress updates are critical for security, but manual updates don’t scale.

Problems with Manual Updates

Time-consuming: Updating 50 sites manually takes 5-8 hours of repetitive clicking.

Security delays: Critical security patches sit uninstalled for days or weeks.

Inconsistent: Some sites get updated, others forgotten, creating security gaps.

No rollback: If an update breaks a site, you’re manually restoring backups.

Update fatigue: Developers avoid updates because the process is painful.

WP-CLI Bulk Update Advantages

Fast: Update 100 sites in under 30 minutes with automation scripts.

Consistent: Same update process across all sites prevents human error.

Safe: Automated backups before every update enable instant rollback.

Scheduled: Cron automation handles updates during maintenance windows.

Testable: Stage updates on test sites before production rollout.

According to WordPress security research, 60% of hacked WordPress sites were compromised due to outdated plugins. Efficient update workflows prevent breaches.

Single Site Update Operations

Master updating individual WordPress installations first.

Update All Plugins

# Update all plugins
wp plugin update --all

# Preview updates without installing
wp plugin update --all --dry-run

# Update excluding specific plugins
wp plugin update --all --exclude=woocommerce,elementor

# Update specific plugins only
wp plugin update wordfence yoast-seo contact-form-7

Update All Themes

# Update all themes
wp theme update --all

# Update specific theme
wp theme update astra

# Dry run to preview
wp theme update --all --dry-run

Update WordPress Core

# Update to latest version
wp core update

# Update to specific version
wp core update --version=6.4.2

# Update minor versions only (security updates)
wp core update --minor

Pro Tip: Always run --dry-run first to preview what will be updated before making changes.

Learn more in the official WP-CLI plugin update documentation.

Safe Update Workflow with Backups

Never update without backups and rollback capability.

Complete Backup Before Updates

#!/bin/bash
# safe-update.sh - Update with automatic backup

SITE_PATH="/var/www/html"
BACKUP_DIR="/backups"
DATE=$(date +%Y%m%d_%H%M%S)

cd "$SITE_PATH"

echo "Creating pre-update backup..."

# Backup database
wp db export "$BACKUP_DIR/db-before-update-$DATE.sql.gz"

# Backup files (plugins, themes, uploads)
tar -czf "$BACKUP_DIR/files-before-update-$DATE.tar.gz" \
    wp-content/plugins \
    wp-content/themes \
    wp-content/uploads

echo "✓ Backup complete"

# Update plugins
echo "Updating plugins..."
wp plugin update --all

# Update themes
echo "Updating themes..."
wp theme update --all

# Verify WordPress still works
if wp core is-installed; then
    echo "✓ Updates successful, WordPress functional"
else
    echo "✗ WordPress check failed, restoring backup..."
    wp db import "$BACKUP_DIR/db-before-update-$DATE.sql.gz"
    exit 1
fi

Rollback Failed Updates

#!/bin/bash
# rollback-update.sh - Restore last backup

BACKUP_DIR="/backups"

# Find most recent backup
LATEST_DB=$(ls -t "$BACKUP_DIR"/db-before-update-*.sql.gz | head -1)
LATEST_FILES=$(ls -t "$BACKUP_DIR"/files-before-update-*.tar.gz | head -1)

if [ -z "$LATEST_DB" ]; then
    echo "No backup found!"
    exit 1
fi

echo "Rolling back to backup: $LATEST_DB"

# Restore database
wp db import "$LATEST_DB"

# Restore files
tar -xzf "$LATEST_FILES" -C /var/www/html/

echo "✓ Rollback complete"

Bulk Update Across Multiple Sites

Update plugins and themes across all WordPress installations you manage.

Update Multiple Sites Script

#!/bin/bash
# bulk-update-sites.sh - Update all managed sites

SITES=(
    "/var/www/site1"
    "/var/www/site2"
    "/var/www/site3"
    "/var/www/client-site"
)

BACKUP_DIR="/backups"
LOG_FILE="/var/log/wp-bulk-updates.log"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $@" | tee -a "$LOG_FILE"
}

log "=== Bulk WordPress Update Started ==="

for SITE in "${SITES[@]}"; do
    SITE_NAME=$(basename "$SITE")
    log "Processing: $SITE_NAME"

    cd "$SITE" || { log "ERROR: Cannot access $SITE"; continue; }

    # Check WordPress is installed
    if ! wp core is-installed 2>/dev/null; then
        log "WARNING: WordPress not found in $SITE, skipping"
        continue
    fi

    # Backup database
    BACKUP_FILE="$BACKUP_DIR/${SITE_NAME}-$(date +%Y%m%d).sql.gz"
    if wp db export "$BACKUP_FILE"; then
        log "✓ Backed up: $SITE_NAME"
    else
        log "✗ Backup failed for $SITE_NAME, skipping updates"
        continue
    fi

    # Update plugins
    log "Updating plugins for $SITE_NAME..."
    if wp plugin update --all --quiet; then
        log "✓ Plugins updated: $SITE_NAME"
    else
        log "✗ Plugin update failed: $SITE_NAME"
    fi

    # Update themes
    log "Updating themes for $SITE_NAME..."
    if wp theme update --all --quiet; then
        log "✓ Themes updated: $SITE_NAME"
    else
        log "✗ Theme update failed: $SITE_NAME"
    fi

    log "---"
done

log "=== Bulk Update Complete ==="

Use Case: Agencies managing dozens of client sites can update all installations in one maintenance window.

Update with Email Notifications

#!/bin/bash
# bulk-update-notify.sh - Updates with email reporting

ADMIN_EMAIL="admin@example.com"
REPORT="/tmp/update-report-$$.txt"

{
    echo "WordPress Bulk Update Report"
    echo "Generated: $(date)"
    echo "================================"
    echo ""

    # Update logic here (from previous script)
    # ...

} > "$REPORT"

# Email report
mail -s "WordPress Bulk Update Report" "$ADMIN_EMAIL" < "$REPORT"

rm "$REPORT"

Selective and Staged Update Strategies

Control exactly what gets updated and when.

Update Specific Plugins Only

#!/bin/bash
# update-security-plugins.sh - Update security plugins only

SECURITY_PLUGINS=(
    "wordfence"
    "sucuri-scanner"
    "ithemes-security"
    "all-in-one-wp-security-and-firewall"
)

for PLUGIN in "${SECURITY_PLUGINS[@]}"; do
    echo "Updating security plugin: $PLUGIN"
    wp plugin update "$PLUGIN" 2>/dev/null
done

echo "✓ Security plugins updated"

Staged Rollout Strategy

#!/bin/bash
# staged-update.sh - Update test sites first, then production

TEST_SITES=("/var/www/test1" "/var/www/staging")
PROD_SITES=("/var/www/prod1" "/var/www/prod2")

echo "Stage 1: Updating test sites..."
for SITE in "${TEST_SITES[@]}"; do
    cd "$SITE"
    wp plugin update --all
    wp theme update --all
done

echo "Test sites updated. Monitor for 24 hours before production."
read -p "Proceed with production updates? (y/n) " -n 1 -r
echo

if [[ ! $REPLY =~ ^[Yy]$ ]]; then
    echo "Production updates cancelled"
    exit 0
fi

echo "Stage 2: Updating production sites..."
for SITE in "${PROD_SITES[@]}"; do
    cd "$SITE"
    # Backup first
    wp db export "/backups/$(basename $SITE)-prod-$(date +%Y%m%d).sql.gz"
    wp plugin update --all
    wp theme update --all
done

echo "✓ Staged rollout complete"

Learn about WordPress staging environments best practices.

Exclude Problematic Plugins

#!/bin/bash
# update-exclude-known-issues.sh

# Plugins known to have issues in latest version
EXCLUDE_PLUGINS=(
    "broken-plugin"
    "problematic-theme-plugin"
)

# Build exclude parameter
EXCLUDE_PARAM=""
for PLUGIN in "${EXCLUDE_PLUGINS[@]}"; do
    EXCLUDE_PARAM="${EXCLUDE_PARAM}${PLUGIN},"
done

# Remove trailing comma
EXCLUDE_PARAM=${EXCLUDE_PARAM%,}

# Update all except excluded
wp plugin update --all --exclude="$EXCLUDE_PARAM"

echo "Updated all plugins except: $EXCLUDE_PARAM"

Automated Update Scheduling

Schedule bulk updates to run automatically during maintenance windows.

Weekly Automated Updates

#!/bin/bash
# weekly-auto-update.sh - Run via cron

LOG_FILE="/var/log/auto-updates.log"
BACKUP_DIR="/backups/auto"
SITES_DIR="/var/www"

log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $@" | tee -a "$LOG_FILE"
}

log "=== Automated Weekly Update Started ==="

# Find all WordPress installations
find "$SITES_DIR" -maxdepth 2 -name "wp-config.php" | while read WP_CONFIG; do
    SITE_PATH=$(dirname "$WP_CONFIG")
    SITE_NAME=$(basename "$SITE_PATH")

    cd "$SITE_PATH"
    log "Updating: $SITE_NAME"

    # Backup
    mkdir -p "$BACKUP_DIR"
    wp db export "$BACKUP_DIR/$SITE_NAME-$(date +%Y%m%d).sql.gz" --quiet

    # Update
    wp plugin update --all --quiet
    wp theme update --all --quiet
    wp core update --minor --quiet

    log "✓ Updated: $SITE_NAME"
done

# Cleanup old backups (keep 30 days)
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +30 -delete

log "=== Automated Update Complete ==="

Schedule with cron:

# Run every Sunday at 2 AM
0 2 * * 0 /usr/local/bin/weekly-auto-update.sh

Update Monitoring and Alerts

#!/bin/bash
# monitor-updates.sh - Check for available updates

SITES=("/var/www/site1" "/var/www/site2")
ALERT_EMAIL="admin@example.com"
UPDATES_FOUND=0

REPORT="/tmp/update-status-$$.txt"

{
    echo "WordPress Update Status Report"
    echo "Generated: $(date)"
    echo "=============================="
    echo ""

    for SITE in "${SITES[@]}"; do
        SITE_NAME=$(basename "$SITE")
        cd "$SITE"

        PLUGIN_UPDATES=$(wp plugin list --update=available --format=count 2>/dev/null)
        THEME_UPDATES=$(wp theme list --update=available --format=count 2>/dev/null)

        if [ "$PLUGIN_UPDATES" -gt 0 ] || [ "$THEME_UPDATES" -gt 0 ]; then
            echo "Site: $SITE_NAME"
            echo "  Plugins needing update: $PLUGIN_UPDATES"
            echo "  Themes needing update: $THEME_UPDATES"
            echo ""
            UPDATES_FOUND=$((UPDATES_FOUND + 1))
        fi
    done

    if [ "$UPDATES_FOUND" -eq 0 ]; then
        echo "All sites are up to date!"
    fi

} > "$REPORT"

# Send email if updates available
if [ "$UPDATES_FOUND" -gt 0 ]; then
    mail -s "WordPress Updates Available ($UPDATES_FOUND sites)" "$ALERT_EMAIL" < "$REPORT"
fi

rm "$REPORT"

Testing and Verification

Verify updates didn’t break functionality.

Post-Update Health Check

#!/bin/bash
# verify-updates.sh - Check sites after updates

SITES=("/var/www/site1" "/var/www/site2")

for SITE in "${SITES[@]}"; do
    SITE_NAME=$(basename "$SITE")
    cd "$SITE"

    echo "Checking: $SITE_NAME"

    # Check WordPress is functional
    if ! wp core is-installed 2>/dev/null; then
        echo "✗ WordPress check failed: $SITE_NAME"
        continue
    fi

    # Check database connection
    if ! wp db check 2>/dev/null; then
        echo "✗ Database check failed: $SITE_NAME"
        continue
    fi

    # Check site responds
    SITE_URL=$(wp option get siteurl 2>/dev/null)
    if curl -f -s "$SITE_URL" > /dev/null; then
        echo "✓ $SITE_NAME is healthy"
    else
        echo "✗ $SITE_NAME not responding"
    fi
done

Automated Testing Script

#!/bin/bash
# test-after-update.sh

# Critical pages to test
TEST_URLS=(
    "/"
    "/shop"
    "/checkout"
    "/my-account"
)

SITE_URL=$(wp option get siteurl)

echo "Testing critical pages..."

for PATH in "${TEST_URLS[@]}"; do
    URL="${SITE_URL}${PATH}"

    HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" "$URL")

    if [ "$HTTP_CODE" -eq 200 ]; then
        echo "✓ $PATH - OK (200)"
    else
        echo "✗ $PATH - FAILED ($HTTP_CODE)"
    fi
done

Next Steps

You now have professional bulk update capabilities for WordPress sites at scale.

Recommended Learning Path

Week 1: Single site updates

• Practice safe update workflows
• Implement backup strategies
• Test rollback procedures

Week 2: Multi-site automation

• Build bulk update scripts
• Add safety checks
• Implement logging

Week 3: Staged rollouts

• Create test/production workflows
• Set up monitoring
• Automate notifications

Week 4: Full automation

• Schedule automated updates
• Build health check systems
• Document recovery procedures

Advanced Topics

1. Zero-Downtime Updates – Update without taking sites offline
2. Update Testing Automation – Automated functional testing
3. Large-Scale WordPress Management – Managing 500+ sites

Get More Resources

Download update automation scripts including:

• Complete bulk update system
• Rollback automation
• Health check templates

Join our email course for:

• Weekly WP-CLI tutorials
• WordPress automation strategies
• Enterprise management techniques

Conclusion

Bulk updating WordPress sites with WP-CLI transforms a time-consuming, risky process into a fast, safe, automated workflow that scales to any number of installations.

What we covered:

✅ Single site update operations with safety checks ✅ Automated backup and rollback strategies ✅ Bulk update scripts for multiple sites ✅ Selective and staged update approaches ✅ Automated scheduling and monitoring ✅ Post-update testing and verification

Master these techniques, and you’ll manage WordPress updates across unlimited sites efficiently while maintaining security and minimizing downtime.

Ready for more? Learn WordPress deployment automation or continuous integration for WordPress.

Questions about bulk WordPress updates with WP-CLI? Drop a comment below!

Found this helpful? Share with other WordPress developers and agencies.

The post Bulk Update WordPress Plugins and Themes Across Multiple Sites with WP-CLI appeared first on WP-CLI Mastery.

Understanding Cron and WP-CLI Integration

Cron is a time-based job scheduler in Unix-like operating systems that executes commands at specified intervals. When paired with WP-CLI, cron enables you to automate virtually any WordPress operation, from database optimization to content publishing.

The combination offers powerful capabilities: scheduled backups during off-peak hours, automatic plugin updates with rollback protection, regular security scans, database cleanup operations, and automated content workflows. This automation frees developers to focus on building features rather than routine maintenance.

Crontab Syntax Essentials

Understanding cron syntax is fundamental to creating effective scheduled tasks. A cron expression consists of five time fields followed by the command to execute:

* * * * * command-to-execute
│ │ │ │ │
│ │ │ │ └─── Day of week (0-7, where 0 and 7 are Sunday)
│ │ │ └───── Month (1-12)
│ │ └─────── Day of month (1-31)
│ └───────── Hour (0-23)
└─────────── Minute (0-59)

Common patterns include:

• 0 2 * * * – Daily at 2:00 AM
• */15 * * * * – Every 15 minutes
• 0 0 * * 0 – Weekly on Sunday at midnight
• 0 3 1 * * – Monthly on the 1st at 3:00 AM
• 0 */6 * * * – Every 6 hours

Special strings provide shortcuts: @reboot (on system startup), @daily (once per day), @hourly (once per hour), @weekly (once per week), and @monthly (once per month).

Setting Up Your First WP-CLI Cron Job

Begin by accessing your crontab editor with crontab -e. For a simple daily backup task:

# Daily WordPress database backup at 2 AM
0 2 * * * /usr/local/bin/wp --path=/var/www/html db export /backups/db-$(date +\%Y\%m\%d).sql --allow-root

Critical considerations when writing cron jobs: always use absolute paths for commands and files, set the correct user permissions, escape special characters (like % with backslash), and specify the WordPress path with the --path flag.

If WP-CLI runs as root, include the --allow-root flag. However, running as the web server user (like www-data) is generally safer:

# Run as www-data user
0 2 * * * sudo -u www-data /usr/local/bin/wp --path=/var/www/html db export /backups/db-$(date +\%Y\%m\%d).sql

Creating a Maintenance Script

Rather than cramming complex logic into crontab, create dedicated scripts that cron executes. This approach improves maintainability, enables version control, and facilitates testing.

#!/bin/bash
# /opt/scripts/wp-maintenance.sh
# WordPress daily maintenance automation

set -euo pipefail

WP_PATH="/var/www/html"
BACKUP_DIR="/backups/wordpress"
LOG_FILE="/var/log/wp-maintenance.log"
DATE=$(date +%Y%m%d-%H%M%S)

# Logging function
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a "$LOG_FILE"
}

log "Starting WordPress maintenance"

# Create backup directory if it doesn't exist
mkdir -p "$BACKUP_DIR"

# Database backup
log "Creating database backup"
wp --path="$WP_PATH" db export "$BACKUP_DIR/database-$DATE.sql" || {
    log "ERROR: Database backup failed"
    exit 1
}

# Optimize database
log "Optimizing database"
wp --path="$WP_PATH" db optimize

# Clean up old backups (keep last 7 days)
log "Cleaning old backups"
find "$BACKUP_DIR" -name "database-*.sql" -mtime +7 -delete

# Update plugins (excluding specific ones)
log "Updating plugins"
wp --path="$WP_PATH" plugin update --all --exclude=woocommerce,elementor

# Clear transients
log "Clearing expired transients"
wp --path="$WP_PATH" transient delete --expired

# Generate thumbnail for recent uploads
log "Regenerating recent thumbnails"
wp --path="$WP_PATH" media regenerate --yes --only-missing

# Clear object cache if available
if wp --path="$WP_PATH" cache flush &>/dev/null; then
    log "Cache flushed successfully"
fi

log "Maintenance completed successfully"

Make the script executable and add to crontab:

chmod +x /opt/scripts/wp-maintenance.sh

# In crontab
0 3 * * * /opt/scripts/wp-maintenance.sh

Advanced Scheduling Strategies

Complex WordPress operations often require conditional logic, environment-specific configurations, and coordination between multiple tasks.

#!/bin/bash
# Advanced scheduling with environment detection

WP_PATH="/var/www/html"

# Detect environment
ENVIRONMENT=$(wp --path="$WP_PATH" config get WP_ENVIRONMENT_TYPE)

case $ENVIRONMENT in
    production)
        # Conservative updates in production
        wp --path="$WP_PATH" plugin update --minor
        wp --path="$WP_PATH" core update --minor
        ;;
    staging)
        # More aggressive updates in staging
        wp --path="$WP_PATH" plugin update --all
        wp --path="$WP_PATH" core update
        wp --path="$WP_PATH" theme update --all
        ;;
    development)
        # Full updates including development versions
        wp --path="$WP_PATH" plugin update --all
        wp --path="$WP_PATH" core update --version=nightly
        ;;
esac

For coordinated tasks across multiple sites:

#!/bin/bash
# Multi-site update coordination

SITES=(
    "/var/www/site1"
    "/var/www/site2"
    "/var/www/site3"
)

for site in "${SITES[@]}"; do
    echo "Processing: $site"

    # Check if site is healthy before updating
    if wp --path="$site" core is-installed; then
        wp --path="$site" core update --minor
        wp --path="$site" plugin update --all --exclude=custom-plugin

        # Verify site is still functional
        if ! wp --path="$site" core verify-checksums; then
            echo "WARNING: Checksum verification failed for $site"
            # Send alert notification
        fi
    else
        echo "ERROR: WordPress not properly installed at $site"
    fi
done

Error Handling and Notifications

Production cron jobs require robust error handling and notification systems to alert administrators when problems occur.

#!/bin/bash
# wp-backup-with-notifications.sh

set -euo pipefail

ADMIN_EMAIL="admin@example.com"
WP_PATH="/var/www/html"
BACKUP_DIR="/backups"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)

send_alert() {
    local subject="$1"
    local message="$2"
    echo "$message" | mail -s "$subject" "$ADMIN_EMAIL"
}

# Trap errors
trap 'send_alert "WordPress Backup Failed" "Backup script failed at line $LINENO"' ERR

# Check disk space
AVAILABLE_SPACE=$(df "$BACKUP_DIR" | tail -1 | awk '{print $4}')
if [ "$AVAILABLE_SPACE" -lt 1048576 ]; then  # Less than 1GB
    send_alert "Low Disk Space Warning" "Available space: ${AVAILABLE_SPACE}KB"
    exit 1
fi

# Perform backup
wp --path="$WP_PATH" db export "$BACKUP_DIR/db-$TIMESTAMP.sql"

# Backup files
tar -czf "$BACKUP_DIR/files-$TIMESTAMP.tar.gz" -C "$WP_PATH" wp-content/uploads

# Verify backup integrity
if [ -f "$BACKUP_DIR/db-$TIMESTAMP.sql" ] && [ -f "$BACKUP_DIR/files-$TIMESTAMP.tar.gz" ]; then
    BACKUP_SIZE=$(du -sh "$BACKUP_DIR" | cut -f1)
    send_alert "Backup Completed Successfully" "Backup size: $BACKUP_SIZE"
else
    send_alert "Backup Verification Failed" "One or more backup files are missing"
    exit 1
fi

Logging and Monitoring

Comprehensive logging helps troubleshoot issues and track automation performance over time.

#!/bin/bash
# Enhanced logging example

LOG_DIR="/var/log/wp-automation"
mkdir -p "$LOG_DIR"

# Create dated log file
LOG_FILE="$LOG_DIR/maintenance-$(date +%Y%m%d).log"

# Logging function with levels
log() {
    local level=$1
    shift
    local message="$@"
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [$level] $message" >> "$LOG_FILE"
}

# Execute WP-CLI command with logging
wp_execute() {
    local cmd="$@"
    log "INFO" "Executing: wp $cmd"

    if output=$(wp $cmd 2>&1); then
        log "SUCCESS" "Command completed: $output"
        return 0
    else
        log "ERROR" "Command failed: $output"
        return 1
    fi
}

# Usage
wp_execute --path=/var/www/html plugin list --status=active
wp_execute --path=/var/www/html core update --minor

Monitor log files with automated analysis:

# Cron job to analyze logs and send daily summary
0 8 * * * /opt/scripts/analyze-logs.sh

# analyze-logs.sh
#!/bin/bash
LOG_DIR="/var/log/wp-automation"
YESTERDAY=$(date -d "yesterday" +%Y%m%d)
LOG_FILE="$LOG_DIR/maintenance-$YESTERDAY.log"

if [ -f "$LOG_FILE" ]; then
    ERRORS=$(grep -c "\[ERROR\]" "$LOG_FILE" || true)
    SUCCESSES=$(grep -c "\[SUCCESS\]" "$LOG_FILE" || true)

    mail -s "WP Automation Summary $YESTERDAY" admin@example.com <<EOF
Daily WordPress Automation Summary

Successful operations: $SUCCESSES
Failed operations: $ERRORS

Recent errors:
$(grep "\[ERROR\]" "$LOG_FILE" | tail -5)
EOF
fi

Security Considerations

Secure your cron jobs by limiting file permissions, using dedicated service accounts, and protecting sensitive information.

# Create dedicated user for WordPress automation
sudo useradd -r -s /bin/bash wpautomation

# Set appropriate permissions
chmod 700 /opt/scripts/wp-maintenance.sh
chown wpautomation:wpautomation /opt/scripts/wp-maintenance.sh

# Store credentials securely
cat > /home/wpautomation/.wp-cli-credentials << EOF
SMTP_PASSWORD=secure_password
API_KEY=secret_key
EOF

chmod 600 /home/wpautomation/.wp-cli-credentials
chown wpautomation:wpautomation /home/wpautomation/.wp-cli-credentials

# Crontab for wpautomation user
sudo -u wpautomation crontab -e

Testing Cron Jobs

Before deploying to production, test your cron jobs thoroughly:

# Run manually to verify behavior
/opt/scripts/wp-maintenance.sh

# Test with verbose WP-CLI output
wp --path=/var/www/html plugin update --all --dry-run --debug

# Verify cron syntax
# Install cron expression parser
npm install -g cron-validate

# Check if your cron expression is valid
echo "0 3 * * *" | cron-validate

Use temporary increased frequency for testing:

# Test frequency (every 5 minutes)
*/5 * * * * /opt/scripts/test-automation.sh

# Production frequency (daily at 3 AM)
# 0 3 * * * /opt/scripts/wp-maintenance.sh

Best Practices Summary

Always redirect output appropriately – either to log files or use >/dev/null 2>&1 to suppress. Include timeout mechanisms for long-running operations to prevent hanging processes. Implement file locking to prevent concurrent execution when scripts shouldn’t overlap.

Use environment variables for configuration rather than hardcoding values. Document each cron job with comments explaining its purpose and frequency. Regularly review and audit scheduled tasks to remove obsolete jobs.

Consider using cron management tools like whenever (Ruby) or cronitor for monitoring. Set up health checks to verify cron jobs are executing as expected.

Related Links

• WP-CLI Commands Reference
• Crontab Guru – Cron Schedule Expression Editor
• Linux Cron Tutorial
• WordPress Maintenance Best Practices
• Automated WordPress Deployment Guide

The post How to Schedule WP-CLI Tasks with Cron: Complete Automation Guide appeared first on WP-CLI Mastery.

Manual backups are tedious, error-prone, and easy to forget. The solution? Automated backups using WP-CLI and Bash that run like clockwork—whether you’re awake or asleep.

In this comprehensive guide, you’ll learn how to build a production-ready WordPress backup automation system from scratch. By the end, you’ll have a script that automatically backs up your database, files, compresses everything, manages retention policies, and even notifies you of success or failure.

Why Automate WordPress Backups?

The Cost of No Backups

Real scenario: A client’s WordPress site gets hacked at 3 AM. The attacker deletes the database and replaces files with malware. Without automated backups, you’re looking at:

• Hours of downtime (lost revenue)
• Lost content (months of blog posts, products, customer data)
• Damaged reputation (customers lose trust)
• Potential data breach liability

With automated backups, you restore from last night’s backup and are back online in 15 minutes.

Manual Backups Don’t Scale

The manual backup problem:

• Requires you to remember (you won’t always)
• Takes 10-15 minutes per site
• Easy to make mistakes (wrong directory, incomplete backup)
• Doesn’t work at 3 AM when you’re sleeping

Automated backups solve this:

• Run on schedule without human intervention
• Always complete (or notify you of failures)
• Work 24/7/365
• Scale to hundreds of sites with the same script

Statistics That Matter

According to CodeinWP’s WordPress statistics:

• 30% of websites have no backup at all
• 60% of small businesses never recover from data loss
• The average cost of downtime is $5,600 per minute for e-commerce sites

Can you afford NOT to automate backups?

What to Backup in WordPress

A complete WordPress backup includes two critical components:

1. Database (MySQL/MariaDB)

The database contains:

• All posts, pages, and custom post types
• Comments and user data
• Site settings and options
• Plugin and theme configurations
• Widgets and menus

Size: Usually 5-50 MB for small sites, up to 500 MB+ for large sites

Backup frequency: Daily minimum, hourly for high-traffic sites

2. File System

Essential files include:

• wp-content/uploads/ – All media files (images, videos, PDFs)
• wp-content/themes/ – Custom themes
• wp-content/plugins/ – Installed plugins
• wp-config.php – Database configuration (contains credentials)
• .htaccess – Server configuration

Size: Can range from 100 MB to 50+ GB depending on media library

Backup frequency: Daily for active sites, weekly for static sites

What You Can Skip

To save space and time, you can exclude:

• wp-content/cache/ – Temporary cache files
• wp-content/backups/ – Avoid backing up backups
• wp-core files – Can be re-downloaded from WordPress.org

For very large media libraries (10+ GB), consider backing up uploads separately to cloud storage.

Prerequisites

Before building the automation script, ensure you have:

Required Software

1. WP-CLI installed – Installation guide
2. Bash shell – Standard on Linux/Unix/macOS
3. SSH access to your server
4. Basic Bash knowledge – Bash functions guide

Server Requirements

• Disk space: At least 2x your WordPress installation size for backups
• Write permissions: Access to create backup directories
• WP-CLI access: Ability to run wp commands
• Cron access: For scheduling (optional but recommended)

Test Your Setup

Verify WP-CLI works:

cd /var/www/html
wp core version

If this returns your WordPress version, you’re ready to proceed.

Building the Backup Script Step-by-Step

Let’s build the backup script incrementally, starting simple and adding features.

Step 1: Basic Structure

Create a new file:

nano ~/wp-backup.sh

Add the basic structure:

#!/bin/bash
#
# WordPress Backup Automation Script
# Backs up database and files for a WordPress installation
#

set -euo pipefail  # Exit on error, undefined vars, pipe failures

# Configuration
WP_PATH="/var/www/html"
BACKUP_DIR="/var/backups/wordpress"
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")

echo "Starting WordPress backup..."
echo "Timestamp: ${TIMESTAMP}"

# Script logic will go here

echo "Backup completed!"

Make it executable:

chmod +x ~/wp-backup.sh

What this does:

• set -euo pipefail ensures the script exits on errors
• Variables store paths and timestamp
• Basic output shows script is running

Database Backup with WP-CLI

Export Database to SQL File

Add database backup function:

backup_database() {
    local wp_path=$1
    local backup_dir=$2
    local timestamp=$3

    local db_file="${backup_dir}/database_${timestamp}.sql"

    echo "Backing up database..."

    if wp db export "$db_file" --path="$wp_path" --quiet; then
        echo "✓ Database exported: ${db_file}"
        echo "$db_file"
        return 0
    else
        echo "✗ Database export failed" >&2
        return 1
    fi
}

How this works:

• wp db export dumps the entire database to a .sql file
• --quiet suppresses verbose output
• Returns the filename on success, empty on failure

Add Compression

Compress the SQL file to save space:

backup_database() {
    local wp_path=$1
    local backup_dir=$2
    local timestamp=$3

    local db_file="${backup_dir}/database_${timestamp}.sql"

    echo "Backing up database..."

    if wp db export "$db_file" --path="$wp_path" --quiet; then
        echo "✓ Database exported: ${db_file}"

        # Compress with gzip
        gzip "$db_file"
        echo "✓ Database compressed: ${db_file}.gz"

        echo "${db_file}.gz"
        return 0
    else
        echo "✗ Database export failed" >&2
        return 1
    fi
}

Compression benefits:

• Typical compression ratio: 10:1 (50 MB → 5 MB)
• Saves disk space and transfer bandwidth
• Standard format compatible with all restore tools

Database Backup Best Practices

Security considerations:

• SQL files contain database credentials in plain text
• Ensure backup directory has restricted permissions (700)
• Never store backups in web-accessible directories

# Secure backup directory
mkdir -p "$BACKUP_DIR"
chmod 700 "$BACKUP_DIR"

Performance tips:

• Large databases (500+ MB) can take 1-5 minutes to export
• Run backups during low-traffic periods (2-4 AM)
• Consider incremental backups for massive databases

File System Backup

Backup WordPress Files with tar

Add file backup function:

backup_files() {
    local wp_path=$1
    local backup_dir=$2
    local timestamp=$3

    local files_archive="${backup_dir}/files_${timestamp}.tar.gz"

    echo "Backing up files..."

    # Exclude cache and temporary files
    local exclude_opts="--exclude=wp-content/cache --exclude=wp-content/backup*"

    if tar -czf "$files_archive" \
        $exclude_opts \
        -C "$(dirname $wp_path)" \
        "$(basename $wp_path)" 2>/dev/null; then

        echo "✓ Files archived: ${files_archive}"
        echo "$files_archive"
        return 0
    else
        echo "✗ File backup failed" >&2
        return 1
    fi
}

What this does:

• tar -czf creates a compressed archive
• -C changes directory before archiving
• --exclude skips cache and backup directories
• Output is redirected to suppress tar warnings

Conditional Uploads Backup

For sites with large media libraries, make uploads optional:

backup_files() {
    local wp_path=$1
    local backup_dir=$2
    local timestamp=$3
    local include_uploads=${4:-true}  # Default to true

    local files_archive="${backup_dir}/files_${timestamp}.tar.gz"

    echo "Backing up files..."

    # Build exclude options
    local exclude_opts="--exclude=wp-content/cache --exclude=wp-content/backup*"

    if [ "$include_uploads" = "false" ]; then
        echo "  (Excluding uploads directory)"
        exclude_opts="${exclude_opts} --exclude=wp-content/uploads"
    fi

    if tar -czf "$files_archive" \
        $exclude_opts \
        -C "$(dirname $wp_path)" \
        "$(basename $wp_path)" 2>/dev/null; then

        echo "✓ Files archived: ${files_archive}"
        echo "$files_archive"
        return 0
    else
        echo "✗ File backup failed" >&2
        return 1
    fi
}

# Usage
backup_files /var/www/html /backups $TIMESTAMP false  # Skip uploads

When to exclude uploads:

• Media library > 10 GB
• Uploads stored on CDN or cloud storage
• Backup uploads separately to S3/Backblaze

Compression and Storage Optimization

Compression Comparison

Recommendation: Use gzip for daily backups (best speed/size balance)

Combined Archive

Create a single archive containing both database and files:

create_combined_backup() {
    local db_backup=$1
    local files_backup=$2
    local backup_dir=$3
    local timestamp=$4

    local combined="${backup_dir}/wordpress_backup_${timestamp}.tar.gz"
    local temp_dir=$(mktemp -d)

    # Copy both backups to temp directory
    cp "$db_backup" "$files_backup" "$temp_dir/"

    # Create combined archive
    tar -czf "$combined" -C "$temp_dir" .

    # Clean up
    rm -rf "$temp_dir"
    rm -f "$db_backup" "$files_backup"

    echo "✓ Combined backup created: ${combined}"
    echo "$combined"
}

Benefits:

• Single file to manage
• Easier to transfer and restore
• Atomic backup (all or nothing)

Retention Policies

Automatic Cleanup of Old Backups

Prevent backups from filling your disk:

cleanup_old_backups() {
    local backup_dir=$1
    local retention_days=${2:-7}  # Default 7 days

    echo "Cleaning up backups older than ${retention_days} days..."

    local deleted=$(find "$backup_dir" \
        -name "wordpress_backup_*.tar.gz" \
        -type f \
        -mtime +${retention_days} \
        -delete -print | wc -l)

    if [ "$deleted" -gt 0 ]; then
        echo "✓ Deleted ${deleted} old backup(s)"
    else
        echo "  No old backups to clean up"
    fi
}

# Usage
cleanup_old_backups /var/backups/wordpress 7  # Keep 7 days

Retention Strategy Recommendations

Daily backups:

• Keep: Last 7 days
• Disk usage: ~7x backup size

Weekly backups:

• Keep: Last 4 weeks (28 days)
• Disk usage: ~4x backup size

Monthly backups:

• Keep: Last 12 months (365 days)
• Disk usage: ~12x backup size

3-2-1 Rule:

• 3 copies of data (original + 2 backups)
• 2 different storage types (local + cloud)
• 1 copy off-site

Email Notifications

Send Email on Success/Failure

send_notification() {
    local subject=$1
    local message=$2
    local email="${NOTIFICATION_EMAIL:-}"

    if [ -z "$email" ]; then
        return 0  # No email configured
    fi

    if command -v mail &> /dev/null; then
        echo -e "$message" | mail -s "$subject" "$email"
        echo "✓ Email sent to ${email}"
    else
        echo "⚠ mail command not found (install mailutils)"
    fi
}

# Usage on success
send_notification \
    "WordPress Backup SUCCESS" \
    "Backup completed successfully\nFile: ${backup_file}\nSize: ${size}"

# Usage on failure
send_notification \
    "WordPress Backup FAILED" \
    "Backup failed during database export\nCheck logs for details"

Install Mail Utilities

# Ubuntu/Debian
sudo apt-get install mailutils

# CentOS/RHEL
sudo yum install mailx

Configure email in script:

# At top of script
NOTIFICATION_EMAIL="admin@yourdomain.com"

Scheduling with Cron

Add to Crontab

Schedule daily backups at 2 AM:

# Edit crontab
crontab -e

# Add this line
0 2 * * * /home/username/wp-backup.sh >> /var/log/wp-backup.log 2>&1

Cron schedule breakdown:

• 0 – Minute (0)
• 2 – Hour (2 AM)
• * – Day of month (every day)
• * – Month (every month)
• * – Day of week (every day)

Common Cron Schedules

# Every 6 hours
0 */6 * * * /home/username/wp-backup.sh

# Daily at 3:30 AM
30 3 * * * /home/username/wp-backup.sh

# Weekly on Sundays at 2 AM
0 2 * * 0 /home/username/wp-backup.sh

# Twice daily (6 AM and 6 PM)
0 6,18 * * * /home/username/wp-backup.sh

Use crontab.guru to generate cron schedules visually.

Verify Cron is Running

# List your cron jobs
crontab -l

# Check cron logs (Ubuntu/Debian)
grep CRON /var/log/syslog

# Check your backup logs
tail -f /var/log/wp-backup.log

Testing Your Backups

Critical truth: A backup you haven’t tested is worthless.

Test Restore Procedure

1. Extract backup:

cd /var/backups/wordpress
tar -xzf wordpress_backup_20250220_020000.tar.gz

2. Restore database:

gunzip database_20250220_020000.sql.gz
wp db import database_20250220_020000.sql --path=/var/www/html

3. Restore files:

tar -xzf files_20250220_020000.tar.gz -C /var/www/

4. Verify site: Visit your site and check that content is intact.

Test on Staging Environment

Best practice: Never test restores on production.

Create a staging environment:

# Copy WordPress to staging
cp -r /var/www/html /var/www/staging

# Update wp-config.php with staging database
wp config set DB_NAME staging_db --path=/var/www/staging

# Test restore there
wp db import backup.sql --path=/var/www/staging

Backup Verification Script

verify_backup() {
    local backup_file=$1

    echo "Verifying backup integrity..."

    # Check file exists
    if [ ! -f "$backup_file" ]; then
        echo "✗ Backup file not found"
        return 1
    fi

    # Check file size (should be > 1KB)
    local size=$(stat -f%z "$backup_file" 2>/dev/null || stat -c%s "$backup_file")
    if [ "$size" -lt 1024 ]; then
        echo "✗ Backup file suspiciously small (${size} bytes)"
        return 1
    fi

    # Test tar integrity
    if tar -tzf "$backup_file" &>/dev/null; then
        echo "✓ Backup archive is valid"
        return 0
    else
        echo "✗ Backup archive is corrupted"
        return 1
    fi
}

Off-Site Backup Storage

Local backups protect against accidental deletion. Off-site backups protect against server failure, fires, and catastrophic events.

Option 1: AWS S3

# Install AWS CLI
sudo apt-get install awscli

# Configure credentials
aws configure

# Sync backups to S3
aws s3 sync /var/backups/wordpress/ s3://your-bucket/wordpress-backups/

Add to backup script:

# After backup completes
echo "Syncing to AWS S3..."
if aws s3 cp "$backup_file" s3://your-bucket/backups/; then
    echo "✓ Uploaded to S3"
else
    echo "✗ S3 upload failed" >&2
fi

S3 pricing: ~$0.023/GB/month (very affordable)

Option 2: Rsync to Remote Server

# Sync to remote server via SSH
rsync -avz /var/backups/wordpress/ \
    user@backup-server.com:/backups/wordpress/

Add to backup script:

# After backup completes
echo "Syncing to remote server..."
if rsync -avz "$backup_file" user@backup-server.com:/backups/; then
    echo "✓ Synced to remote server"
else
    echo "✗ Remote sync failed" >&2
fi

Option 3: Backblaze B2 (Budget-Friendly)

Backblaze B2 costs 1/4 of S3 ($0.005/GB/month):

# Install B2 CLI
pip install b2

# Configure
b2 authorize-account <key_id> <app_key>

# Upload
b2 upload-file <bucket_name> "$backup_file" backups/$(basename $backup_file)

Learn more: Backblaze B2 Documentation

Complete Production Script

Here’s the full production-ready script with all features:

#!/bin/bash
#
# WordPress Backup Automation Script
# Complete production-ready version
#

set -euo pipefail

#############################################
# CONFIGURATION
#############################################

WP_PATH="/var/www/html"
BACKUP_DIR="/var/backups/wordpress"
RETENTION_DAYS=7
NOTIFICATION_EMAIL="admin@yourdomain.com"
INCLUDE_UPLOADS=true

#############################################
# COLORS
#############################################

RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m'

#############################################
# FUNCTIONS
#############################################

log_info() {
    echo -e "${GREEN}[INFO]${NC} $*"
}

log_error() {
    echo -e "${RED}[ERROR]${NC} $*" >&2
}

backup_database() {
    local wp_path=$1
    local backup_dir=$2
    local timestamp=$3
    local db_file="${backup_dir}/database_${timestamp}.sql"

    log_info "Backing up database..."

    if wp db export "$db_file" --path="$wp_path" --quiet; then
        gzip "$db_file"
        log_info "Database backed up: ${db_file}.gz"
        echo "${db_file}.gz"
        return 0
    else
        log_error "Database backup failed"
        return 1
    fi
}

backup_files() {
    local wp_path=$1
    local backup_dir=$2
    local timestamp=$3
    local files_archive="${backup_dir}/files_${timestamp}.tar.gz"
    local exclude_opts="--exclude=wp-content/cache --exclude=wp-content/backup*"

    if [ "$INCLUDE_UPLOADS" = "false" ]; then
        exclude_opts="${exclude_opts} --exclude=wp-content/uploads"
    fi

    log_info "Backing up files..."

    if tar -czf "$files_archive" $exclude_opts \
        -C "$(dirname $wp_path)" "$(basename $wp_path)" 2>/dev/null; then
        log_info "Files backed up: ${files_archive}"
        echo "$files_archive"
        return 0
    else
        log_error "File backup failed"
        return 1
    fi
}

create_combined_backup() {
    local db_backup=$1
    local files_backup=$2
    local backup_dir=$3
    local timestamp=$4
    local combined="${backup_dir}/wordpress_backup_${timestamp}.tar.gz"
    local temp_dir=$(mktemp -d)

    cp "$db_backup" "$files_backup" "$temp_dir/"
    tar -czf "$combined" -C "$temp_dir" .
    rm -rf "$temp_dir" "$db_backup" "$files_backup"

    log_info "Combined backup: ${combined}"
    echo "$combined"
}

cleanup_old_backups() {
    local backup_dir=$1
    local retention_days=$2

    log_info "Cleaning up backups older than ${retention_days} days..."

    find "$backup_dir" -name "wordpress_backup_*.tar.gz" \
        -type f -mtime +${retention_days} -delete
}

send_notification() {
    local subject=$1
    local message=$2

    if [ -n "$NOTIFICATION_EMAIL" ] && command -v mail &> /dev/null; then
        echo -e "$message" | mail -s "$subject" "$NOTIFICATION_EMAIL"
    fi
}

#############################################
# MAIN
#############################################

TIMESTAMP=$(date +"%Y%m%d_%H%M%S")

log_info "========================================="
log_info "WordPress Backup Started"
log_info "========================================="
log_info "Path: ${WP_PATH}"
log_info "Timestamp: ${TIMESTAMP}"

mkdir -p "$BACKUP_DIR"

# Backup database
if ! db_backup=$(backup_database "$WP_PATH" "$BACKUP_DIR" "$TIMESTAMP"); then
    send_notification "Backup FAILED" "Database backup failed"
    exit 1
fi

# Backup files
if ! files_backup=$(backup_files "$WP_PATH" "$BACKUP_DIR" "$TIMESTAMP"); then
    send_notification "Backup FAILED" "File backup failed"
    exit 1
fi

# Create combined backup
final_backup=$(create_combined_backup "$db_backup" "$files_backup" "$BACKUP_DIR" "$TIMESTAMP")

# Cleanup old backups
cleanup_old_backups "$BACKUP_DIR" "$RETENTION_DAYS"

# Get backup size
backup_size=$(du -h "$final_backup" | cut -f1)

log_info "========================================="
log_info "Backup Completed Successfully!"
log_info "File: ${final_backup}"
log_info "Size: ${backup_size}"
log_info "========================================="

send_notification "Backup SUCCESS" "Backup: ${final_backup}\nSize: ${backup_size}"

exit 0

Download this script: 👉 Get the production-ready backup script free

Troubleshooting

Issue 1: “wp: command not found”

Problem: WP-CLI is not in the cron user’s PATH.

Solution: Use full path in cron:

# Instead of:
0 2 * * * ~/wp-backup.sh

# Use:
0 2 * * * /usr/local/bin/wp-backup.sh

Or add PATH to crontab:

PATH=/usr/local/bin:/usr/bin:/bin
0 2 * * * ~/wp-backup.sh

Issue 2: Permission Denied

Problem: Backup script can’t write to backup directory.

Solution:

# Create directory with proper permissions
sudo mkdir -p /var/backups/wordpress
sudo chown $USER:$USER /var/backups/wordpress
chmod 700 /var/backups/wordpress

Issue 3: Disk Space Full

Problem: Backups fill up the disk.

Solution: Reduce retention or exclude uploads:

# Check disk usage
df -h

# Reduce retention to 3 days
RETENTION_DAYS=3

# Or exclude uploads
INCLUDE_UPLOADS=false

Issue 4: Backup Taking Too Long

Problem: Large sites take 30+ minutes to backup.

Solution:

1. Exclude uploads (back up separately)
2. Run during off-peak hours
3. Use incremental backups for files
4. Consider database replication for very large databases

Issue 5: Cron Job Not Running

Problem: Script works manually but not via cron.

Solution: Check cron logs and add logging:

# Add to crontab
0 2 * * * /home/user/wp-backup.sh >> /var/log/wp-backup.log 2>&1

# Check logs
tail -f /var/log/wp-backup.log

# Verify cron service is running
sudo systemctl status cron

Next Steps

Congratulations! You now have a production-ready WordPress backup automation system.

Enhance Your Backup System

1. Schedule WP-CLI Tasks with Cron – Advanced scheduling techniques
2. WordPress Multisite Network Management – Back up entire networks
3. WordPress CI/CD Pipeline with GitHub Actions – Integrate backups into deployment

Related Guides

• Bash Functions for WordPress – Make your scripts more maintainable
• Error Handling in Bash Scripts – Handle failures gracefully
• Install WP-CLI – Get WP-CLI set up properly

Master WordPress Automation

Want to build advanced automation systems like:

• Automated blog publishing with AI and APIs
• Complete WordPress deployment pipelines
• Multi-site management at scale

Join the WPCLI Mastery waitlist and get:

• This complete backup script (production-ready)
• Advanced backup strategies (incremental, differential)
• Off-site storage integration templates
• Early bird pricing ($99 vs $199)

Conclusion

Automated WordPress backups are non-negotiable for any production site. With WP-CLI and Bash, you can build a bulletproof backup system in less than an hour that runs flawlessly for years.

Key takeaways:

• Automate backups to eliminate human error
• Backup both database and files
• Compress backups to save space
• Implement retention policies to manage disk usage
• Test restores regularly (untested backups are useless)
• Store backups off-site for disaster recovery
• Monitor with email notifications

The script you built today can protect hundreds of WordPress sites. Set it up once, and sleep better knowing your data is safe.

Ready to implement? Download the complete production script and get it running today.

Questions about WordPress backup automation? Drop a comment below!

Found this helpful? Share it with other WordPress developers who need automated backups.

Next: Learn how to deploy WordPress environments automatically using similar automation techniques.

The post Automate WordPress Backups with WP-CLI and Bash (Step-by-Step) appeared first on WP-CLI Mastery.