CloudScale Backup & Restore
| 开发者 | andrewjbaker |
|---|---|
| 更新时间 | 2026年6月2日 22:42 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPL-2.0-or-later |
| 版权网址: | 版权信息 |
详情介绍:
- Full WordPress database: all tables, all data
- Media uploads folder (
/wp-content/uploads/) - Plugins folder (
/wp-content/plugins/) - Themes folder (
/wp-content/themes/)
.zip file with a descriptive filename that reflects exactly what it contains.
Key features
- Run manual backups with one click: choose which components to include each time
- Configurable automatic scheduling: set your interval in days (1, 7, 30, or any number) and the exact hour of day to run
- Configurable retention: keep the last N backups; older ones are deleted automatically after each run
- Full backup history: view all stored backups with filename, type label, size, creation date, and age
- Download any backup directly from the WordPress admin
- Restore the database from any stored backup or by uploading a
.zipor.sqlfile - Safe restore workflow: puts the site into WordPress maintenance mode before restoring and removes it after
- Explicit snapshot warning before any restore operation: requires confirmation before proceeding
- System info panel: shows which backup and restore method will be used on your server, memory limits, and backup storage path
- Backup directory protected from direct web access with
.htaccessdeny-all - All passwords passed to CLI tools via environment variable, not shell arguments
- Reads each table in 500-row chunks via
$wpdb. Never loads the full database into memory. Works on any WordPress host.
- Parses SQL statement by statement with a character-level parser that correctly handles quoted strings, escaped characters, and multi-line
INSERTstatements. Handles files of any size.
backup_full_2026-02-21_03-00-00.zip: all four componentsbackup_db_2026-02-21_14-35-00.zip: database onlybackup_db-media-plugins_2026-02-21_09-10-00.zip: three componentsbackup_plugins-themes_2026-02-21_22-00-00.zip: files only, no database
- Shows the exact backup file name and creation date you are restoring from
- Displays a warning box explaining what will happen step by step
- Requires you to tick a checkbox: "I have taken a server snapshot and understand this will overwrite the live database"
- Only enables the Restore button after that checkbox is ticked
.maintenance file is created so visitors see the standard maintenance page. It is always removed when restore finishes, whether the restore succeeded or failed. The plugin header shows a live badge indicating whether the site is online or in maintenance mode.
Backup zip contents
Each zip includes a backup-meta.json with metadata: plugin version, creation timestamp, WordPress version, site URL, table prefix, and which components were included. This makes it easy to verify a backup without restoring it.
安装:
- Download
cloudscale-backup.zip - In your WordPress admin, go to Plugins > Add New Plugin > Upload Plugin
- Select the zip file and click Install Now
- Click Activate Plugin
- Go to Tools > CloudScale Backup & Restore
- Unzip
cloudscale-backup.zip - Upload the
cloudscale-backupfolder to/wp-content/plugins/ - Activate via Plugins > Installed Plugins
- Go to Tools > CloudScale Backup & Restore
屏幕截图:
常见问题:
Where are backups stored?
In a dedicated cloudscale-backups/ folder inside your WordPress uploads directory. This folder is created automatically on activation and protected with an .htaccess deny-all rule. Download backups using the Download button in the admin panel, which uses a nonce-secured handler.
Will it time out on large sites?
No. The plugin sets set_time_limit(0) and ignore_user_abort(true) for all backup and restore operations. The PHP streaming implementation reads data in small chunks so memory usage stays flat regardless of database size. Check the System Info card for details about your server's configuration.
What PHP version is required?
PHP 8.1 or higher. The plugin uses typed parameters, match expressions, str_contains(), and first-class callable syntax introduced in PHP 8.0/8.1.
Is ZipArchive required?
Yes. The ZipArchive extension is needed to create and read backup zip files. It is bundled with PHP on the vast majority of shared hosting environments. If it is missing, contact your host and ask them to enable the zip PHP extension.
How does the scheduling work?
The plugin registers a custom WordPress cron interval based on the number of days you configure. For reliable scheduling, your server should have a real system cron job pointing at wp-cron.php rather than relying on WordPress's visitor-triggered pseudo-cron. Most managed WordPress hosts configure this automatically. Your server's current time and timezone are shown on the settings page so you can pick the right hour.
Can I restore just the database and keep my current media?
Yes. The restore function extracts database.sql from the backup zip and imports it. Media, plugin, and theme files inside the zip are not automatically restored. You can unzip the backup manually and extract only the folders you need. This prevents accidentally overwriting files you have added since the backup.
Can I restore on a different server or after a domain change?
Yes. The restore imports the SQL as-is. If the database contains hardcoded URLs from the old domain, run a search-replace using WP-CLI after restoring:
wp search-replace 'olddomain.com' 'newdomain.com' --path=/path/to/wordpress
The restore failed. Is the site broken?
The plugin removes maintenance mode even when a restore fails, so your site will be accessible. Check the plugin page to confirm the maintenance badge is gone. Errors are logged to your server's PHP error log. If the database is in a partial state, restore from a server snapshot or use phpMyAdmin or Adminer to assess the database directly.
Can I trigger a backup from WP-CLI or a system cron job?
Yes. Use WP-CLI to trigger a backup from the command line:
wp eval 'csbr_create_backup(true, true, true, true); csbr_enforce_retention();' --path=/path/to/wordpress
Adjust the four boolean arguments ($include_db, $include_media, $include_plugins, $include_themes) as needed.
What is inside the backup zip?
Each zip may contain:
database.sql: complete SQL dump of all WordPress tablesuploads/: full media uploads directory treeplugins/: full plugins directory treethemes/: full themes directory treebackup-meta.json: metadata including plugin version, creation timestamp, WordPress version, site URL, table prefix, and which components were backed up
Can I use this to migrate my site to a new host?
Yes. Run a full backup on the old site, install WordPress on the new host, install and activate this plugin, then use Restore from Upload to import the database. Copy the uploads/, plugins/, and themes/ folders manually from the zip if needed, or use the backup of those folders.
更新日志:
- FIX: Fatal-error-handler drop-in now written via the WordPress Filesystem API instead of raw copy() (resolves Plugin Check PluginDirectoryWrite)
- FIX: Crash Recovery config and notification lock moved from the wp-content root into uploads/cloudscale-backup/ per WordPress.org guidelines; old files removed on upgrade
- FIX: Removed wp_prime_option_caches() (WordPress 6.4+) so the plugin stays compatible with its declared minimum of WordPress 6.0
- CHANGE: Drop-in notifications now use the non-blocking wp_remote_post() HTTP API instead of cURL
- CHANGE: Dev-only crash-test harness and clone module excluded from the release build; removed duplicate Plugin URI header
- FIX: Remove four dead
wp_ajax_csbr_do_sync_job_*handlers that called undefined functioncsbr_do_async_sync(), legacy loopback architecture replaced byregister_shutdown_function()in v3.2.257 - FIX: Automatic Crash Recovery Explain modal and How It Works list now correctly document all notification channels (email, Twilio SMS, ntfy push) instead of only Twilio
- ADD: DocBlocks added to
csbr_set_job(),csbr_get_job(),csbr_delete_job(),csbr_find_rclone(),csbr_find_aws(),csbr_list_tables_in_dump(),csbr_list_backups() - CLEANUP: Remove unused
csbr_verify_nonce()helper (all handlers usecheck_ajax_referer()directly)
- FIX: PCP compliance:
cs_admin_page()now independently checkscurrent_user_can('manage_options') - FIX: PCP compliance:
wp_unslash()added to$_POST['cs_action']and$_POST['schedule_enabled'];phpcs:ignoreannotations added - FIX: PCP compliance:
data-free-bytesattribute annotated withphpcs:ignore EscapeOutput.OutputNotEscaped - FIX:
uninstall.php: Dropbox options now cleaned up on plugin delete - FIX: Dropbox history pane infinite reload loop resolved
- FIX: AMI Save/Create buttons now show feedback message correctly
- UX: Copy buttons on all Explain modal code blocks; Dropbox setup wizard guide; italic placeholders
- Renamed internal constants with CS_BACKUP_ prefix to avoid collisions with other plugins
- Replaced @unlink(), @copy(), @rmdir() with wp_delete_file(), copy(), rmdir() per WordPress coding standards
- NEW: Split backup scheduling into two independent cron events: file backup and AMI snapshot each have their own day picker and time selector
- NEW: Configurable backup filename prefix (default: bkup), set in the Retention card
- NEW: S3 sync auto-retry: on failure a single cron event fires 5 minutes later; UI shows pending state and a manual Retry button
- FIX: Scheduled backup run hour never saved due to missing name attribute on the hour select
- FIX: Full+ backup type badge now renders distinctly from Full (separate CSS rule)
- AMI explain modal updated to document the two-schedule architecture; reboot defaults clarified (off = crash-consistent, no downtime)
- FIX: AMI creation failed with "Character sets beyond ASCII are not supported" due to em dash in description
- AMI description now stripped to printable ASCII only via regex
- AMI name now sanitised to AWS allowed characters (alphanumeric, hyphens, underscores, dots, slashes, parens) and capped at 128 chars
- Replaced sanitize_file_name with stricter AWS specific character filter
- FIX: AMI panel could vanish if IMDS endpoint was unreachable or curl failed during page render
- All IMDS calls now wrapped in try/catch with error suppression so failures cannot break the admin page
- Added curl_init availability check before attempting IMDS calls
- IMDS results cached in WordPress transients (1 hour TTL) to avoid repeated metadata calls on every page load
- AMI panel init block wrapped in top level try/catch, falls back to empty state on any error
- NEW: EC2 AMI Snapshot panel: create full machine images of the hosting instance directly from the plugin
- AMI name uses configurable prefix with automatic yyyyMMdd_HHmm timestamp suffix
- Optional instance reboot for filesystem consistent snapshots
- AMI creation history log with status tracking (last 5 shown, 20 stored)
- Check Status button to poll AMI state from AWS
- Explain modal with IAM policy requirements and restore instructions
- Auto detection of EC2 instance ID and region via IMDS (v1 and v2)
- Save/create/status operations via self contained AJAX handlers
- Initial public release of CloudScale Backup & Restore
- Manual and scheduled backup of database, media uploads, plugins folder, and themes folder
- Configurable schedule interval in days with specific run hour
- Configurable retention with automatic cleanup of oldest backups
- Backup history table with type labels, sizes, dates, and ages
- Download any backup from the admin panel
- Restore from stored backup or uploaded .zip / .sql file
- WordPress maintenance mode enabled during restore and always removed after
- Restore confirmation modal with snapshot warning and checkbox gate
- Smart detection of mysqldump and mysql CLI for native backup and restore
- PHP streamed fallback for environments without CLI tool access
- Backup directory protected with .htaccess deny-all
- System info panel showing detected methods, memory limits, and backup path