Automated Backups and Disaster Recovery

Data loss is the kind of disaster that happens exactly once before it changes how you run infrastructure forever. A single ransomware infection, an accidental DROP TABLE, or a failed WordPress plugin update that corrupts the database - any of these can take hours or days to recover from without proper backups, or minutes with them.

CloudPloy's backup system is designed around one principle: you should be able to recover from any failure in under 15 minutes. This guide covers how to configure automated backups, set retention policies, connect external storage, verify backup integrity, and execute a full site restore when you need it.

How CloudPloy Backups Work

CloudPloy takes two types of backups that together provide complete coverage of your application:

1. Application File Backups

A compressed archive of your application's file system - including your WordPress installation, themes, plugins, and wp-content/uploads directory. These are stored as .tar.gz archives and support incremental snapshots after the first full backup to minimize storage usage.

2. Database Backups

A complete MySQL dump of your application's database, exported using mysqldump with --single-transaction to ensure consistency without locking tables. For large databases (>1GB), CloudPloy uses Percona XtraBackup for hot physical backups that are faster and impose zero read/write performance penalty.

Backup Storage Locations

Local backups: Stored on the same server in a dedicated backup partition - fast to restore from, but lost if the server fails catastrophically
Remote backups: Transferred to an external provider (S3, DigitalOcean Spaces, Backblaze B2, or your own SFTP) - protected against server failure
Cross-region replication: For enterprise plans, backups are replicated to a second geographic region automatically

Best practice: use both local and at least one remote backup destination. Local backups provide fast recovery; remote backups provide disaster protection.

Configuring Automated Backups

Step 1: Open Backup Settings

Log into the CloudPloy dashboard
Select your server from the server list
Click on your application (WordPress site, Laravel app, etc.)
Go to Backups in the left navigation

Step 2: Configure Backup Schedule

CloudPloy supports cron-style scheduling. Common configurations:

Daily at 2 AM: 0 2 * * * - good for most blogs and small sites
Every 6 hours: 0 */6 * * * - recommended for active WooCommerce stores
Every hour: 0 * * * * - for high-traffic sites or sites with frequent content updates
Weekly on Sunday: 0 3 * * 0 - for low-traffic informational sites

Schedule backups during your lowest-traffic period. The database export and file archive operations add momentary I/O load - this is negligible on modern SSDs but scheduling off-peak is good practice.

Step 3: Set Retention Policy

Retention policies control how many backup copies to keep before older ones are automatically deleted. Consider these tradeoffs:

7 daily backups: minimum for most sites - covers common "I accidentally deleted something yesterday" scenarios
30 daily backups: covers month-end scenarios and slow-developing data corruption issues
90 days + 12 monthly: enterprise standard - enables compliance with many audit requirements

Storage cost is the main constraint. A 5GB WordPress site produces roughly 3-4GB compressed backups. At 30 daily backups, that is ~100GB of storage - budget accordingly when choosing a retention period.

Step 4: Configure Remote Storage (Recommended)

Connect at least one remote backup destination to protect against server failure. Go to Server Settings > Backup Providers to add a provider:

Amazon S3

# Required IAM policy for the backup IAM user
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-backup-bucket",
        "arn:aws:s3:::your-backup-bucket/*"
      ]
    }
  ]
}

Create a dedicated S3 bucket with versioning disabled (CloudPloy handles versioning via retention) and server-side encryption enabled (AES-256).

Backblaze B2 (Most Cost-Effective)

Backblaze B2 costs $6/TB/month vs S3's ~$23/TB/month, making it the most economical option for large backup storage. Create an Application Key with read/write access to your backup bucket, then enter the Key ID and Application Key in CloudPloy.

DigitalOcean Spaces

If your server is on DigitalOcean, Spaces is co-located in the same datacenter which reduces transfer latency and egress costs. Create a Space, generate API keys under API > Spaces Access Keys, and configure the endpoint to match your region (e.g., nyc3.digitaloceanspaces.com).

Custom SFTP

For self-hosted NAS devices or custom backup servers, CloudPloy supports SFTP with public key authentication. Generate an SSH key pair, add the public key to your SFTP server's authorized_keys, and provide the private key to CloudPloy.

Step 5: Enable Encryption

For backups containing sensitive user data (WooCommerce customer records, user PII), enable AES-256 encryption before transfer. CloudPloy encrypts backups at rest using a key you control. Store your encryption key somewhere safe - CloudPloy cannot recover encrypted backups without it.

On-Demand Manual Backups

Always take a manual backup before making significant changes: major plugin updates, WordPress core upgrades, theme changes, database migrations, or server configuration changes.

From the Backups panel, click Create Backup Now. You can also trigger backups via WP-CLI or the CloudPloy API:

# Create backup via WP-CLI (if WP-CLI plugin installed)
wp cloudploy backup create --type=full --note="before-wp-6.5-upgrade"

# Via CloudPloy API
curl -X POST https://api.cloudploy.com/v1/applications/{app_id}/backups \
  -H "Authorization: Bearer {your_api_token}" \
  -H "Content-Type: application/json" \
  -d '{"type": "full", "note": "pre-upgrade manual backup"}'

Restoring from Backup

Recovery time depends on backup size and whether you restore files, database, or both. A typical 5GB WordPress site restores in 4-8 minutes.

Full Restore (Files + Database)

Go to your application's Backups panel
Find the backup to restore from - use the timestamp and note to identify the correct one
Click Restore
Choose restore scope: Full Restore (files + database), Files Only, or Database Only
Confirm the restore - the current site will be overwritten
CloudPloy places the site in maintenance mode during restore to prevent data conflicts
Restoration runs in the background; you will receive a notification when complete

Database-Only Restore

For cases where only the database was corrupted (e.g., failed migration, accidental data deletion), use a database-only restore to avoid re-uploading all files:

# Via WP-CLI - restore specific backup to a new database for review first
mysqldump backup_20260328_020000.sql.gz | gunzip | mysql -u dbuser -p dbname

# Then verify the data looks correct before replacing production
mysql -u dbuser -p production_db < backup_20260328_020000.sql

# Flush object cache after database restore
wp cache flush
wp rewrite flush

Partial File Restore

If you only need to recover specific files (e.g., accidentally deleted images in wp-content/uploads), download the backup archive and extract only the files you need:

# Extract just the uploads directory from a backup archive
tar -xzf backup-20260328-020000.tar.gz --strip-components=1 \
  var/www/yoursite/wp-content/uploads/2026/

# Or extract a specific file
tar -xzf backup-20260328-020000.tar.gz \
  var/www/yoursite/wp-content/uploads/2026/03/logo.png

Restoring to a Different Server (Disaster Recovery)

If your primary server is completely unavailable, restore to a new server:

Provision a new CloudPloy server (same or larger specs)
Create a new WordPress application on the new server
Go to Backups > Import Backup
Provide your external storage credentials - CloudPloy will list available backups
Select the most recent backup and run the restore
Update DNS to point your domain to the new server IP
Re-issue SSL certificate (triggered automatically when DNS propagates)

With remote backups pre-configured, this entire process typically takes 15-30 minutes.

Verifying Backup Integrity

A backup you have never tested is a backup you cannot trust. CloudPloy offers automated backup verification, but you should also run manual restore tests periodically.

Automated Verification

Enable Backup Verification in your backup settings. After each backup completes, CloudPloy automatically:

Checks the archive is not corrupted using checksum validation
Attempts to extract and verify key files (wp-config.php, wp-content/ structure)
Tests the database dump by importing it to a temporary database and checking row counts match
Sends a report with verification status to your notification email

Manual Restore Test

Run a full restore test on a staging environment at least once per quarter:

Create a staging application on CloudPloy
Restore your latest production backup to staging
Verify the site loads correctly, database queries work, and key functionality (forms, WooCommerce checkout, user login) is functional
Record the restore time - this is your actual RTO (Recovery Time Objective) for planning purposes

Backup Monitoring and Alerts

Configure alerts so you know immediately when a backup fails instead of discovering the problem during a recovery attempt.

Go to Server Settings > Notifications to configure:

Backup success notifications: optional, useful initially to confirm the schedule is working
Backup failure alerts: always enable - sent immediately when a scheduled backup fails
Storage space warnings: alerts when backup storage exceeds 80% of allocated space
Verification failure alerts: triggered when automated verification detects a corrupt backup

Notifications can be sent via email, Slack webhook, or PagerDuty integration.

WordPress-Specific Backup Considerations

What to Include in WordPress Backups

wp-content/uploads: user-uploaded media - often the largest and most valuable directory
wp-content/themes: custom themes and child themes
wp-content/plugins: can be re-downloaded from wordpress.org but custom/purchased plugins need backup
wp-config.php: contains database credentials and security keys
The MySQL database: all posts, pages, settings, user accounts, WooCommerce orders

WordPress core files (the wp-admin/ and wp-includes/ directories) do not need to be backed up - they can be re-downloaded from wordpress.org. Excluding them reduces backup size significantly.

WooCommerce Order Data

WooCommerce stores order data in the MySQL database. For stores with HPOS (High-Performance Order Storage) enabled, orders are stored in dedicated tables (wc_orders, wc_order_items) rather than the legacy wp_posts table. Both table sets are captured in CloudPloy's database backup.

For active stores, consider increasing backup frequency to every 1-2 hours to minimize order data loss window (RPO). At 100 orders/day, a 6-hour RPO window could mean losing 25+ orders.

Multisite Networks

WordPress Multisite stores all sites in the same database. A single database backup captures all subsites. However, the file system has per-site upload directories (wp-content/uploads/sites/) which grow proportionally with the number of sites. Plan storage accordingly.

Backup Cost Optimization

Backup storage costs can grow quickly without management. These strategies keep costs under control:

Exclude WordPress core: do not back up wp-admin/ and wp-includes/ - saves 50-60MB per backup and those files are always re-downloadable
Compress uploads with lossy image optimization before backup: ShortPixel or Imagify can reduce uploads directory size by 40-70% before it goes into backup archives
Use tiered storage: keep 7 days of daily backups in standard storage, move older backups to cold storage (S3 Glacier, Backblaze B2) at ~20% of standard storage cost
Incremental file backups: after the initial full backup, daily increments only capture changed files - a 10GB site with 100MB of daily changes produces 100MB increments, not 10GB

Disaster Recovery Runbook

Document your recovery procedure before you need it. A runbook makes the difference between a 15-minute recovery and a 4-hour one when you are stressed at 2 AM.

Recovery Decision Tree

Site down, server accessible: Check application logs, attempt rollback to last stable backup (database only if files are intact)
Database corrupted: Database-only restore from the most recent verified backup; confirm with wp db check after restore
Files corrupted/deleted: Files-only restore; verify wp-config.php permissions (440) and directory permissions (755) after restore
Server inaccessible (hardware failure, datacenter issue): Provision new server, import from remote backup, update DNS
Account compromise: Provision new server, restore from backup predating the compromise, rotate all credentials (database passwords, API keys, WordPress admin passwords) before going live

Post-Restore Checklist

# Run these checks after every restore
wp core verify-checksums          # Verify WordPress core files are intact
wp plugin verify-checksums --all  # Check plugin file integrity
wp db check                       # Check database table integrity
wp cache flush                    # Clear all caches
wp cron event run --due-now       # Run any missed scheduled tasks

# Verify the site loads
curl -I https://yoursite.com      # Should return HTTP 200
curl -I https://yoursite.com/wp-login.php  # Should return 200, not redirect loop

Data Protection Results

Organizations using CloudPloy's backup solution report:

99.999% Data Durability: Enterprise-grade reliability with redundant storage and integrity verification
Under 15-minute RTO: Average recovery time from backup selection to working site
Zero unrecoverable data loss incidents: Across 50,000+ recovery events on the platform
60% lower backup storage costs: vs. managed backup services that charge per-GB premiums