A restore test checks whether your backup contains the files and data needed to recover the site. Use a separate staging environment and verify the restored application.
What to include in a backup
- 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
Backup methods
1. Omega Digital account backups (included)
Check the backup schedule and retention listed for your selected plan. Ask support which restore tools are available for your service, and keep an independent backup copy.
2. WordPress plugin (UpdraftPlus or Jetpack VaultPress)
Backup plugins can export WordPress data to external storage. Review which files they include and exclude.
3. WP-CLI cron (the technical option)
A scheduled script can export the database and archive site files for transfer to off-site storage. Monitor the job and test its backups regularly.
#!/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
Select the required backup date in cPanel → Backups. Download the database and home-directory archives. For UpdraftPlus, download each component: database, plugins, themes, uploads and other files.
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.phpStep 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 || trueStep 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
Every three months, restore a recent backup to staging and run the verification checklist. Record any missing files or failed checks.
Common issues
- No off-server backup. If the server is lost, your only backup is lost with it. At least one layer must live elsewhere.
- Missing database. Include the database to preserve posts, users and site settings.
- Not running search-replace after a URL change. The site half-loads but all links break.
- Cache files. Exclude regenerated cache files to reduce backup size.
- Stale backups. A 14-day-old backup after a ransomware incident may already contain the infection.
Contact support
Email [email protected] with the domain and the backup date you need to restore.