CloudScale Backup & Restore

Yes. Full restore, selective table restore, single post restore, cloud restore, staging clones and automated standby restore are all in the free plugin. Only Managed Cloud storage is paid; your own cloud accounts cost nothing extra.

Any of the destinations under Where Backups Go, several at once. Each has its own card on the Cloud Backups tab with Test Connection and Diagnose buttons. Step-by-step setup for every provider, including where to create the bucket and key and which region and endpoint to enter: https://help.cloudscale.consulting/plugin-help/backup-restore/s3/ (Amazon S3 and S3-compatible), https://help.cloudscale.consulting/plugin-help/backup-restore/sftp/ and https://help.cloudscale.consulting/plugin-help/backup-restore/webdav/.

Yes. The database is dumped in 500-row pages, so memory stays flat whatever its size. Backups and restores run without PHP’s time limit, large uploads are sent in retried chunks, and an S3 or Managed Cloud download that stops part way resumes. A backup killed mid-run is picked up and finished or restarted. The System Info panel shows your server’s limits and the methods in use.

Not if you set Backup Limits on the Local Backups tab; both are off by default. A maximum CPU temperature pauses compression until the processor is 5°C cooler, up to 5 minutes at a time and 30 minutes per backup, so a host that never cools still gets its backup. This needs PHP 8.0 or newer and a host that exposes its temperature, and the card says when yours does not. A maximum share of your stated upload speed spaces out uploads to S3, Managed Cloud, Google Drive, Dropbox and OneDrive. It limits the average, not the peak, and does not cover SFTP, FTP or WebDAV.

On your server in wp-content/uploads/cloudscale-backup-<random>/ . The random part makes the folder name unguessable, and it carries deny rules for Apache, nginx and IIS plus an index.php and 0700 permissions. Download any backup from the admin with the Download button. Copies go to every cloud destination you enable.

In one of ten Amazon S3 regions. Automatic picks the region nearest your site by measuring it; you can also choose one, for example to keep data in Europe. Changing region sends new backups there; backups in the old region expire within 90 days.

No. A compromised site can remove a backup from the list, but storage keeps the deleted copy for 30 days and neither your site nor the CloudScale broker can erase it. Contact support to recover it. After those 30 days it is permanently deleted, so a backup that reaches the 90-day limit is erased by day 120.

Yes. In the Restore window choose Full restore (files, then database), Specific tables only (just the tables you tick) or Single post or page . Upload a .sql file to restore a database only. On the command line, wp csbr restore takes --db-only , --files-only and --components=<list> .

Yes. Install WordPress and this plugin on the new host, then restore the backup from an upload or straight from your cloud storage. Files and database are both restored. If the domain changed, run wp search-replace 'old.example' 'new.example' --all-tables afterwards. To copy a site onto the same server under a new URL, use Clone Targets, which rewrites URLs for you.

Choose the days of the week and the time of day; cloud copies run a set delay after the local backup. For reliable timing, point a real system cron job at wp-cron.php instead of relying on visitor traffic. Your server’s time and timezone are shown next to the schedule.

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. On the Automated Restore tab connect the cloud storage the live site backs up to, choose the site to copy from, and switch on the schedule. The checklist shows anything still missing. A hot standby also needs something outside WordPress to move your DNS; the plugin’s GitHub repository has a Cloudflare script for that.

Create an empty directory the web server can write to, with a wp-config.php naming an empty database (or one your database user can create). Take a backup that includes WordPress core files. On the Clone Targets tab add the directory, its URL and that wp-config.php , press Verify, then Clone Now. Everything in the target is replaced and every URL is rewritten. The wp-config.php must hold literal database values, and cloning needs the PHP mysqli extension. A clone is a complete copy, including mail settings and scheduled tasks, so block outgoing email on it before you browse it. Hook csbr_clone_post_restore to run your own steps afterwards.

Maintenance mode is removed even when a restore fails, including on a PHP fatal or out-of-memory error, and you are alerted with the reason. The restore result lists anything that could not be written. There is no automatic rollback of a partly restored database, so take a server snapshot first (the Restore window asks you to confirm you have) and restore again or from that snapshot.

Yes. wp csbr restore <file> restores a local backup, wp csbr cloud-pull --newest downloads the newest S3 backup, wp csbr sync-from-cloud pulls and restores in one step, and wp csbr auto-restore runs a standby’s configured restore. Run wp help csbr for every option.

No. A restore would overwrite every site in the network, while each site’s own administrator holds the permission its screens check. On a multisite network the plugin shows a notice and does nothing else.

PHP 8.1 or newer and the PHP zip extension, which nearly every host includes. AES-256 encryption needs a zip extension built with encryption support; the plugin tells you if yours is not.

The parts you chose: database.sql , the uploads, plugins, themes and other folders, plus backup-meta.json , which records the plugin and WordPress versions, site URL, table prefix and components, so you can check a backup without restoring it.

Two, both under the MIT licence and used only for SFTP: phpseclib 3.0.57 (https://phpseclib.com) and paragonie/constant_time_encoding 3.1.3 (https://github.com/paragonie/constant_time_encoding). They are renamed under the CSBR_Vendor namespace so they cannot clash with another plugin’s copy. Licence texts are in vendor/ .

No. The plugin’s header links to its help pages there. It is an ordinary link the administrator may choose to open; the plugin itself never requests that host and sends it no data.

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. Uninstalling removes them, except where noted:

• 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. Kept on uninstall so a reinstall or a manual restore can still use your backups; delete the folder yourself if you no longer want them. The token is kept in wp-content/csbr-state/dir-token (with the same deny rules), which also stays so a reinstall finds the folder.
• wp-content/csbr-state/ – the plugin’s hardened state directory: the automatic restore schedule, the backup run lock and the crash-recovery configuration. Removed on uninstall, apart from dir-token and its deny rules (above).
• wp-content/csbr-failover-mode.json , csbr-site-id.json and csbr-restore-ledger.json – small markers for the standby, failover and restore features, kept outside the database because a restore replaces the database. Removed on uninstall.
• wp-content/csbr-site-role.json and wp-content/cloudscale-alert-env-label.json – the site’s role (primary or standby) and its alert label. Kept on uninstall , because the other CloudScale plugins read them too; delete them by hand if no CloudScale plugin remains.
• wp-content/maintenance.php and wp-content/csbr-restore-progress.json – the visitor page and progress file shown while a restore runs, removed when it ends. Uninstall removes maintenance.php only if it is this plugin’s copy.
• 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 beg