CloudPloy

Backups and Disaster Recovery on CloudPloy

CloudPloy runs automated daily backups of your server's databases and application files. If something goes wrong - a bad deployment, an accidental deletion, a corrupted database - you can restore to any recent backup point from the dashboard. This guide covers how backups work, what gets backed up, how to configure retention, and how to perform a recovery.

What Gets Backed Up

CloudPloy backups cover the full application stack on your server:

  • Databases: All MySQL and MariaDB databases on the server, backed up with mysqldump --single-transaction to ensure consistency without locking tables
  • Application files: Your deployed code, configuration files, and any files in the application's working directory
  • User uploads: The WordPress uploads directory, Laravel storage directory, or equivalent for your framework
  • Environment variables: Application environment configuration stored in CloudPloy is included in the server backup
  • Server configuration: Nginx config, PHP configuration, and Supervisor worker definitions

Backups are stored compressed and encrypted on separate infrastructure from your application server.

Backup Schedule and Retention

Automated backups run daily. The retention period depends on your plan - check your account dashboard for your current retention window. Most plans retain daily backups for at least 7 days, allowing point-in-time recovery for the past week.

To view your current backups and retention policy, go to Server in the CloudPloy dashboard, then select Backups. You'll see a list of all available backup points with timestamps.

Manual Backups

You can trigger a backup on demand from the dashboard at any time - for example, before a major deployment or database migration. Manual backups count against your storage quota the same as automated backups.

For applications where you need more control over the backup process, you can run your own backup scripts using cron jobs configured in CloudPloy. Database backups run directly on the server give you more flexibility than the platform's automated backups:

#!/bin/bash
# Custom backup script - add as a cron job in CloudPloy dashboard
BACKUP_DIR="/var/backups/app"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="${DB_DATABASE}"

mkdir -p "$BACKUP_DIR"

# Database backup
mysqldump -u "$DB_USERNAME" -p"$DB_PASSWORD" \
  --single-transaction \
  --routines \
  --triggers \
  "$DB_NAME" | gzip > "$BACKUP_DIR/db_${DATE}.sql.gz"

# Prune backups older than 14 days
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +14 -delete

echo "Backup completed: db_${DATE}.sql.gz"

Run this script on whatever schedule suits your application - hourly for high-write applications, daily for lower-traffic sites.

Offsite Backup with Amazon S3

For additional redundancy, push backups to an S3 bucket in a different AWS region. This protects against scenarios where your server's local backup storage becomes unavailable:

#!/bin/bash
# Upload backup to S3 after creating it
BACKUP_FILE="/var/backups/app/db_${DATE}.sql.gz"

aws s3 cp "$BACKUP_FILE" \
  "s3://${AWS_BACKUP_BUCKET}/db/${DATE}/" \
  --region us-east-1

# Or use the AWS CLI sync command to push all recent backups
aws s3 sync /var/backups/app/ \
  "s3://${AWS_BACKUP_BUCKET}/" \
  --delete

Set AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_BACKUP_BUCKET as environment variables in the CloudPloy dashboard. Use an IAM user with write access to only the backup bucket - not full S3 access.

Restoring from a Backup

To restore from a CloudPloy-managed backup, go to Server > Backups in the dashboard, select the backup point you want to restore from, and click Restore. The restore process:

  1. Stops your application (brief downtime)
  2. Restores database to the selected backup point
  3. Restores application files to the backup state
  4. Restarts your application

Full server restores typically take a few minutes depending on your application size. Database-only restores are faster.

Manual Database Restore

If you have a backup file and need to restore manually (for example, restoring to a staging server from a production backup), use mysql directly:

# Restore a compressed mysqldump backup
gunzip < db_backup.sql.gz | mysql -u "$DB_USERNAME" -p"$DB_PASSWORD" "$DB_NAME"

# Or uncompressed
mysql -u "$DB_USERNAME" -p"$DB_PASSWORD" "$DB_NAME" < db_backup.sql

For large databases, use --max_allowed_packet to increase the packet size limit if the restore fails on large tables:

mysql --max_allowed_packet=256M \
  -u "$DB_USERNAME" \
  -p"$DB_PASSWORD" \
  "$DB_NAME" < db_backup.sql

WordPress-Specific Backup Considerations

WordPress backups need to include both the database and the uploads directory. The database contains all content, settings, and user data. The uploads directory contains all media files that aren't tracked in your Git repository.

Full WordPress Backup Script

#!/bin/bash
# Full WordPress backup including uploads
DATE=$(date +%Y%m%d_%H%M%S)
WP_DIR="/var/www/html"
BACKUP_DIR="/var/backups/wordpress"

mkdir -p "$BACKUP_DIR"

# Database
mysqldump -u "$DB_USERNAME" -p"$DB_PASSWORD" \
  --single-transaction \
  "$DB_NAME" | gzip > "$BACKUP_DIR/db_${DATE}.sql.gz"

# Uploads directory (media files not in Git)
tar -czf "$BACKUP_DIR/uploads_${DATE}.tar.gz" \
  -C "$WP_DIR/wp-content" uploads/

echo "WordPress backup completed: $DATE"

Restoring WordPress

To restore a WordPress site from backup files:

# 1. Restore the database
gunzip < db_backup.sql.gz | mysql -u "$DB_USERNAME" -p"$DB_PASSWORD" "$DB_NAME"

# 2. Restore uploads directory
tar -xzf uploads_backup.tar.gz -C /var/www/html/wp-content/

# 3. Fix file ownership
chown -R www-data:www-data /var/www/html/wp-content/uploads/

# 4. Update WordPress URLs if restoring to a different domain
wp search-replace 'https://old-domain.com' 'https://new-domain.com' \
  --path=/var/www/html \
  --all-tables

Laravel Backup with spatie/laravel-backup

The spatie/laravel-backup package provides a comprehensive backup solution for Laravel applications that integrates with CloudPloy's environment:

composer require spatie/laravel-backup
# config/backup.php key settings
'backup' => [
    'source' => [
        'files' => [
            'include' => [base_path()],
            'exclude' => [
                base_path('vendor'),
                base_path('node_modules'),
                storage_path('app/backups'),
            ],
        ],
        'databases' => ['mysql'],
    ],
    'destination' => [
        'disks' => ['s3'], // Or 'local' for server-only
    ],
]

Schedule the backup command in app/Console/Kernel.php:

protected function schedule(Schedule $schedule): void
{
    $schedule->command('backup:run')->daily()->at('02:00');
    $schedule->command('backup:clean')->daily()->at('01:00');
    $schedule->command('backup:monitor')->daily()->at('03:00');
}

Run the scheduler via a cron job configured in the CloudPloy dashboard:

* * * * * php /var/www/html/artisan schedule:run >> /dev/null 2>&1

Disaster Recovery Planning

Backups are only useful if you can restore from them when you need to. Run a test restoration periodically - at least monthly - to verify your backups are valid and you understand the recovery procedure before you're under pressure.

For critical applications, maintain a staging server that you can promote to production quickly. This means keeping the staging environment current and verifying that your deployment and database migration scripts work correctly on a fresh server. If your production server becomes unrecoverable, you can provision a new CloudPloy server, restore from backup, and update DNS to point to the new server.

Recovery Checklist

  • Provision a new server in CloudPloy dashboard (same region, same size as original)
  • Connect your Git repository and deploy the application
  • Set all environment variables in the dashboard (keep these documented somewhere safe, like a password manager)
  • Restore the database from your most recent backup
  • Restore uploaded files (uploads directory, storage directory)
  • Run any pending database migrations
  • Verify the application is working correctly
  • Update DNS to point to the new server's IP address

The most common gap in disaster recovery plans is missing the environment variables. Keep a copy of all your production environment variables in a secure location (a password manager or secrets vault) - not in your Git repository. When you provision a new server, you'll need these to restore the application to a working state.

Backup Storage and Costs

CloudPloy's automated backups use storage on your server plan. For applications with large media libraries, backup storage can grow significantly. Monitor your backup storage usage in the dashboard and adjust retention policies or use S3 for older backups to manage costs.

Amazon S3 storage costs approximately $0.023 per GB per month in us-east-1. For a 10GB application with 30 days of daily backups, that's around $7/month - a reasonable cost for the insurance value of offsite backups.