CloudScale Backup & Restore

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.

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.

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.

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.

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.

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.

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

Install WordPress and this plugin on the second server, then open the Standby & DR tab there (never on the live site). Choose a hot standby or a refreshed copy, label its alerts, type MAKE THIS A COPY and press Apply. Then on the Automated Restore tab connect the cloud storage the live site backs up to, choose the folder or site to copy from, and switch on the schedule. The checklist on the Standby & DR tab shows anything still missing. A hot standby also needs something outside WordPress to move your DNS and to tell the standby when it is serving; the help site and the plugin's GitHub repository describe a Cloudflare script that does the DNS half.

Create the target first: an empty directory the web server can write to, containing a wp-config.php that names an empty database (or one your database user can create). Take a backup that includes WordPress core files. Then open the Clone Targets tab, add a target with that directory, the URL it will be served from and the path to that wp-config.php, press Verify, and press Clone Now. The target's files and database are replaced by the backup and every URL is rewritten. The plugin refuses if the target is this site's own directory or database, or a directory that contains this site. Point your web server or hosting panel at the new directory to view it. The wp-config.php must contain literal database values: one that reads them from environment variables cannot be used, and the plugin says so. Cloning needs the PHP mysqli extension, and the database user named in that wp-config.php must be able to create the database, or the database must already exist. Clone Now names the directory and database it will overwrite and asks first, because everything in the target is replaced and that cannot be undone. You can also refresh a target automatically after each scheduled backup, on the days you choose, and hook the csbr_clone_post_restore PHP action to run your own steps afterwards: the clone itself runs no shell scripts. A clone is a complete copy, including your mail settings and scheduled tasks, and nothing in it blocks outgoing email, so block email on it before you browse it.

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.

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.

Each zip may contain:

• database.sql: complete SQL dump of all WordPress tables
• uploads/: full media uploads directory tree
• plugins/: full plugins directory tree
• themes/: full themes directory tree
• backup-meta.json: metadata including plugin version, creation timestamp, WordPress version, site URL, table prefix, and which components were backed up

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.

The Automatic Crash Recovery feature writes a single file outside the plugin folder when it is enabled: wp-content/fatal-error-handler.php. This is a WordPress-recognised drop-in file (documented in the WordPress Developer Handbook under get_dropins()). WordPress core checks for this file on every request; if present, it replaces the default fatal-error screen with a custom handler. The plugin uses this mechanism to show a branded recovery page to visitors while a crash is being fixed, instead of a blank white screen. The file is written using the WordPress Filesystem API (WP_Filesystem). It is only written when the feature is enabled, only overwritten if it was written by this plugin (identified by an internal marker), and is deleted when the feature is disabled or the plugin is uninstalled. No personal data is stored in this file. The plugin also writes the following, all of which are removed on uninstall:

• wp-content/uploads/cloudscale-backup-<random>/ - the backup archives themselves, plus an .htaccess, a web.config and an index.php that block public access to them. The directory name carries a per-site random token because a fixed, guessable name meant sequentially-named archives could be downloaded by anyone who guessed a filename.
• wp-content/csbr-secrets.php - cloud storage credentials, the licence key and the backup encryption password, held outside the database so they are not carried inside the database dumps this plugin creates. It begins with a PHP exit guard so it cannot be read over HTTP, is written 0600, and is excluded from every backup. A lock file and a short-lived temporary file sit alongside it during a write.
• wp-content/cloudscale-backup-par.json - the Automatic Crash Recovery state file, recording which plugins are being monitored.
• wp-content/csbr-state/csbr-auto-restore.json - on a standby site only, the automatic restore schedule and the source it pulls from. The directory carries the same deny-all rules as the backup directory, so the file is not readable over HTTP. Installs upgrading from an earlier version have their existing wp-content/csbr-auto-restore.json moved here automatically.
• <WordPress root>/.maintenance - WordPress's own maintenance-mode file, written only while a restore is running and removed when it finishes or fails. This is the mechanism WordPress itself uses during core updates.
• A temporary staging directory under the system temp path while a backup is built or a restore is unpacked, deleted when the operation ends.
• wp-content/csbr-state/plugin-auto-recovery/ - Automatic Crash Recovery only: a copy of a plugin taken just before WordPress updates it, so a bad update can be rolled back. It is removed when the monitoring window closes and otherwise after 72 hours, and on uninstall. It sits outside the uploads folder because it holds PHP, and it carries deny rules.
• Clone Targets only, and only after an administrator adds a target and presses Clone Now or enables its schedule: a complete WordPress install (core, plugins, themes, uploads and the wp-config.php the administrator named) is written into the directory the administrator chose for that target, which is normally outside wp-content, and the tables in that target's own database are dropped and recreated. It never writes to this site's own directory, and no script is generated or run. The target list is stored in the csbr_clone_targets option.