WordPress backup and restore: a real recovery plan

Most sites have backups that have never been tested. The first time a site owner restores is after a catastrophe, and they find out the backups were empty, corrupt, or 90 days stale. This article covers a backup strategy you can trust, and the restore procedure you should run in staging at least once per quarter.

What actually needs to be backed up

• · The WordPress database (all tables in the wp_ prefix): contains posts, settings, users
• · The wp-content directory: contains uploads, themes, plugins
• · wp-config.php: contains database credentials and salts
• · .htaccess: contains rewrite rules and redirects
• · Custom directories added outside the defaults

Three approaches, ranked

1. Omega Digital account backups (included)

Every shared and reseller plan includes automated nightly backups retained for 14 days, plus weekly for 4 weeks. Restoration is a one-click cPanel action. This is our recommendation as the primary layer, since backups live off the live server, on separate storage.

2. WordPress plugin (UpdraftPlus or Jetpack VaultPress)

Application-aware backups that write to external storage (S3, Backblaze, Google Drive). Good defense-in-depth layer. The plugin knows how to exclude what doesn't matter (cache files, logs) and package what does.

3. WP-CLI cron (the technical option)

A cron job that runs wp db export and tars wp-content, then uploads to offsite storage. Most control, most maintenance. Only choose this if you're comfortable debugging cron.

#!/bin/bash
# ~/cron/backup.sh — runs nightly via cPanel cron
set -e

SITE=/home/cpuser/public_html
BACKUP_DIR=/home/cpuser/backups
DATE=$(date +%Y%m%d-%H%M%S)
RETAIN_DAYS=14

mkdir -p "$BACKUP_DIR"
cd "$SITE"

# Database
wp db export "$BACKUP_DIR/db-$DATE.sql" --add-drop-table

# Files
tar --exclude='wp-content/cache' \
    --exclude='wp-content/uploads/cache' \
    -czf "$BACKUP_DIR/files-$DATE.tar.gz" \
    wp-config.php .htaccess wp-content/

# Prune old
find "$BACKUP_DIR" -type f -mtime +$RETAIN_DAYS -delete

# Optional: rsync to remote storage
# rsync -az "$BACKUP_DIR/" user@backup-host:/path/

Add as a cron job: cPanel → Cron Jobs → New. Schedule: 0 3 * * * (3am daily). Command: /home/cpuser/cron/backup.sh.

The restore procedure (walk through this in staging)

Step 1: Download the backup

From cPanel → Backups, click the dated backup you want. Download the database .sql.gz and the home-directory tarball. If using UpdraftPlus, grab the five files: db, plugins, themes, uploads, others.

Step 2: Staging environment

Never restore directly over a live site. Create a staging subdomain (staging.yourdomain.com) and restore there first. Verify everything, then swap.

Step 3: Restore files

# SSH in
ssh [email protected]

# Remove broken site (carefully!)
cd public_html
rm -rf wp-content wp-admin wp-includes *.php

# Extract backup
tar -xzf /home/cpuser/backups/files-20260419.tar.gz -C .

# Fix permissions
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

Step 4: Restore database

# Drop existing tables (destructive — make sure you're in staging!)
wp db reset --yes

# Import
wp db import /home/cpuser/backups/db-20260419.sql

# If the site URL has changed (live → staging):
wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com' --dry-run
wp search-replace 'https://yourdomain.com' 'https://staging.yourdomain.com'

# Flush caches
wp cache flush
wp litespeed-purge all 2>/dev/null || true

Step 5: Verify

• · Homepage loads and looks correct
• · Can log into /wp-admin
• · A recent post shows correct content
• · Media library images render
• · Contact forms submit successfully
• · Site loads over HTTPS without mixed-content warnings

Test your backups quarterly

A backup you have not tested is a hope, not a plan. Every three months, restore the most recent backup to staging and run through the verification checklist. Calendar it. This is the single best habit in site operations.

Common gotchas

• · No off-server backup. If the server is lost, your only backup is lost with it. At least one layer must live elsewhere.
• · Forgetting the database. File-only backups restore a dead site: wrong admin password, missing posts.
• · Not running search-replace after a URL change. The site half-loads but all links break.
• · Backing up wp-content/cache. Adds gigabytes of useless files. Always exclude cache paths.
• · Stale backups. A 14-day-old backup after a ransomware incident may already contain the infection.

Still stuck?

Email [email protected]. Restores under time pressure are exactly what we're here for.