Title: CloudScale Backup & Restore Author: andrewjbaker Published: 31 Mei 2026 Last modified: 14 Oktober 2026 --- Cari plugin ![](https://ps.w.org/cloudscale-backup-restore/assets/icon-256x256.png?rev=3555613) # CloudScale Backup & Restore Oleh [andrewjbaker](https://profiles.wordpress.org/andrewjbaker/) [Unduh](https://downloads.wordpress.org/plugin/cloudscale-backup-restore.3.2.846.zip) * [Detail](https://id.wordpress.org/plugins/cloudscale-backup-restore/#description) * [Ulasan](https://id.wordpress.org/plugins/cloudscale-backup-restore/#reviews) * [Instalasi](https://id.wordpress.org/plugins/cloudscale-backup-restore/#installation) * [Pengembangan](https://id.wordpress.org/plugins/cloudscale-backup-restore/#developers) [Bantuan](https://wordpress.org/support/plugin/cloudscale-backup-restore/) ## Deskripsi **Most backup plugins fail exactly when you need them most: on your biggest site.** Free tiers commonly cap imports around 500MB, time out on large sites, or allow only one cloud destination. **CloudScale Backup & Restore has no site-size limit, no destination limit, and no plan wall.** It reads your database in 500-row chunks and never loads the whole thing into memory, so a 50MB site and a 50GB site back up the same way, without hitting your host’s memory limit or execution timeout. It backs up to five destinations at once, for free: Amazon S3, Google Drive, Dropbox, Microsoft OneDrive, and CloudScale’s own Managed Cloud Backup. #### Any Size, No Limits * Streams the database in 500-row chunks via `$wpdb`; never loads the full database into memory, regardless of size * Restore uses a character-level SQL parser that correctly handles quoted strings, escaped characters and multi-line `INSERT` statements, on files of any size * System Info panel shows exactly which backup and restore method, and memory limits, your server is using #### Back Up to Five Destinations at Once * Amazon S3, Google Drive, Dropbox and Microsoft OneDrive, using your own accounts, free, with no destination limit * CloudScale Managed Cloud Backup: $5/month for 750GB of off-site storage on Amazon S3 Glacier Instant Retrieval, no separate cloud account needed, stored in the nearest of ten regions, or one you choose * Configurable retention: keep the last N backups on every destination, deleted automatically after each run. Managed copies expire after 90 days; your own cloud follows your own lifecycle rules * Every destination you enable receives every backup automatically #### What It Backs Up Choose any combination, packaged into one `.zip` with a descriptive filename (for example `backup_db-media-plugins_2026-02-21_09-10-00.zip`) that reflects exactly what it contains: * Full WordPress database: all tables, all data * Media uploads folder (`/wp-content/uploads/`) * Plugins folder (`/wp-content/plugins/`) * Themes folder (`/wp-content/themes/`) * Optional Site Root Extras: root-level files like `php.ini`, `robots.txt`, favicon,`. well-known/`, and search-engine verification files * Optional Server Config Snapshot: read-only reference copies of your nginx/Apache config, PHP runtime settings and MySQL variables * Post-restore environment comparison flags PHP version, missing extensions, lower memory/upload limits, or MySQL version differences between the backup’s original server and the one you restored onto * Every zip includes `backup-meta.json` describing what it holds, so you can check a backup without restoring it **Automatic backups are off by default.** Run your first backup manually to confirm everything works on your server, then configure a schedule if you need one. #### Restore Safely Clicking Restore DB opens a confirmation showing the backup’s name and date and what will happen, and the Restore button stays disabled until you tick that you have taken a server snapshot. During restore visitors see a maintenance page, removed when the restore finishes, whether it succeeded or failed. #### Disaster Recovery * Standby & DR tab: one screen to turn a second install into either a hot standby( takes over if the live site dies) or a refreshed copy (for testing, never serves the public). One typed confirmation sets the site role, failover mode, the alert label and disarms the live site’s scheduled jobs on the copy, then a six-step checklist shows what is done and what is left * Automated Restore: a standby refreshes itself from the primary’s newest cloud backup on a schedule. It lists your cloud storage (S3, Google Drive, Dropbox, OneDrive or CloudScale Managed), copies the backup straight to the server without passing through your computer, restores it, and reports the recovery time and a file-by-file reconciliation afterwards * Staleness limit: a run refuses a backup older than the limit you set (36 hours by default) and raises an alert, after waiting up to three hours for a late one * Armed is not serving: failover mode marks a standby as armed to take over, so it never creates, schedules or allows a backup of its own, and says so on every admin screen. Whether it is actually carrying traffic is a separate host-level signal written by whatever moves your DNS; while it says serving, the refresh is suspended so nothing visitors wrote is overwritten * Cloudflare failover script: `tools/cloudflare-failover.sh` in the plugin’s GitHub repository (not in this zip) repoints one DNS record at the standby after three failed probes of the primary, and back after ten clean ones * EC2 AMI Snapshots: create a full machine image of your AWS-hosted server directly from the plugin, with optional reboot for filesystem consistency, plus AMI history and status polling #### Clone to a Staging Site Restore any backup into a **separate WordPress install on the same server**, with its own directory and database, instead of over the live site. * Clone Targets tab: give a target a directory, its URL and its `wp-config.php`, then press Clone Now. URLs are rewritten everywhere, including serialized data and JSON * Refuses this site’s own database or directory before touching anything * Optional schedule after each backup. Runs no shell scripts; hook the `csbr_clone_post_restore` action instead * The dump is streamed, so large sites clone inside PHP’s default memory limit #### Security * Backup directory uses a randomised, non-guessable name, not a fixed predictable path * Protection covers Apache (both `.htaccess` syntaxes), nginx, IIS (`web.config`), and a silent `index.php`, plus `0700` permissions, not just an `.htaccess` that nginx and IIS ignore * A daily self-check fetches its own backup URL to confirm the directory genuinely isn’t publicly readable, and warns you with the exact server rule to add if it is * All passwords passed to CLI tools via environment variable, not shell arguments #### Developer & Automation * Trigger a backup from WP-CLI or a system cron job * Scheduling by day of the week and hour * Full backup history with size, date and age; download any backup from the admin * One-click migration: restore the database from any stored backup or by uploading a `.zip` or `.sql` file, on the same host or a new one ### External services This plugin optionally connects to third-party services when those features are configured by the site administrator. No data is sent to any external service unless the administrator has explicitly enabled the relevant integration. #### Telegram Bot API (optional notifications) **Service:** Telegram Messenger, https://telegram.org/ When a Telegram bot token and chat ID are entered, the plugin sends backup, restore, rollback and error alerts to that chat. A message holds the site name, event status and, for errors, the PHP error, file and line. No visitor data, post content or backup data is sent. API endpoint contacted: the sendMessage method on api.telegram.org, addressed with the administrator’s own bot token. Terms of Service: https://telegram.org/tos Privacy Policy: https://telegram.org/privacy Telegram Bot API documentation: https://core. telegram.org/bots/api #### Amazon S3 (optional cloud backup) **Service:** Amazon Web Services, https://aws.amazon.com/ When S3 settings are configured, the plugin uploads backup zips to the administrator’s own S3 bucket via the S3 REST API. Only the backup zip is sent. The credentials are stored on the site and sent only to the AWS S3 endpoint. API endpoint contacted: the Amazon S3 host for the bucket’s own AWS region, for example s3.eu-west-1.amazonaws.com. Terms of Service: https://aws.amazon.com/service-terms/ Privacy Policy: https:// aws.amazon.com/privacy/ #### Google Drive (optional cloud backup) **Service:** Google, https://workspace.google.com/products/drive/ When Google Drive settings are configured, the plugin transfers backup zip files to the administrator’s own Google Drive account using the Google Drive v3 REST API and OAuth 2.0. No data is sent unless the administrator has completed the OAuth authorisation flow (entered a Client ID and Client Secret from Google Cloud Console and clicked “Connect to Google Drive”). Only the backup zip file is uploaded. OAuth tokens (access token and refresh token) are stored in the WordPress options table. API endpoints contacted: www.googleapis.com (Drive v3) and oauth2.googleapis.com (OAuth 2.0 tokens). Terms of Service: https://policies.google.com/terms Privacy Policy: https://policies.google. com/privacy #### Dropbox (optional cloud backup) **Service:** Dropbox, https://www.dropbox.com/ When Dropbox settings are configured, the plugin transfers backup zip files to the administrator’s own Dropbox account using the Dropbox v2 REST API and OAuth 2.0. No data is sent unless the administrator has completed the OAuth authorisation flow (entered an App Key and App Secret from the Dropbox App Console and clicked “Connect to Dropbox”). Only the backup zip file is uploaded. OAuth tokens are stored in the WordPress options table. API endpoints contacted: api.dropboxapi.com and content.dropboxapi.com (Dropbox v2 REST API). Terms of Service: https://www.dropbox.com/terms Privacy Policy: https://www.dropbox. com/privacy #### Microsoft OneDrive (optional cloud backup) **Service:** Microsoft, https://learn.microsoft.com/en-us/onedrive/ When OneDrive settings are configured, the plugin transfers backup zip files to the administrator’s own Microsoft OneDrive account using the Microsoft Graph REST API and OAuth 2.0. No data is sent unless the administrator has completed the OAuth authorisation flow( entered an Azure App Client ID and Client Secret and clicked “Connect to OneDrive”). Only the backup zip file is uploaded. OAuth tokens are stored in the WordPress options table. API endpoint contacted: https://graph.microsoft.com/ and https://login.microsoftonline. com/ Terms of Service: https://www.microsoft.com/en-us/servicesagreement/ Privacy Policy: https://www.microsoft.com/en-us/privacy/privacystatement #### CloudScale Managed Cloud Backup (optional, paid service) **Service:** CloudScale Consulting, https://cloudscale.consulting/ When subscribed, the plugin asks the CloudScale broker for a short-lived, prefix-scoped Amazon S3 token, then uploads backup zips straight to CloudScale’s S3 storage; backup bytes never pass through the broker. It times ten HEAD requests per storage region and sends the averages, to pick the nearest region. Nothing is sent until a licence key is entered. Storage is encrypted at rest. For extra security, Encrypt backups adds AES-256 encryption with the site owner’s own password before upload. Leave us a message sends the typed email and message, hostname and licence key on Send. Clicking the PayPal button sends the product name, hostname and the optional email typed above it to /checkout-start, so a failed checkout can be followed up. API endpoints contacted (broker): https://api.cloudscale.consulting/backup/token, https:// api.cloudscale.consulting/backup/list, https://api.cloudscale.consulting/status, https://api.cloudscale.consulting/checkout, https://api.cloudscale.consulting/checkout- start, https://api.cloudscale.consulting/recover, https://api.cloudscale.consulting/ recover/verify, https://api.cloudscale.consulting/refund-request and https://api. cloudscale.consulting/contact. Storage and timing requests go to CloudScale’s Amazon S3 storage in its ten regions: af-south-1, eu-west-1, us-east-1, ap-southeast-2, ap-southeast-1, ap-south-1, sa-east-1, us-west-2, eu-central-1 and ap-northeast- 1. Terms of Service: https://cloudscale.consulting/terms/ Privacy Policy: https:// cloudscale.consulting/privacy/ #### PayPal (optional, payment for Managed Cloud Backup) **Service:** PayPal, https://www.paypal.com/us/home Subscription payments for the optional CloudScale Managed Cloud Backup service are processed by PayPal on its own hosted checkout; card details never reach this plugin or the site. When the administrator starts a subscription, the subscriber’s email and the order amount( $5.00 USD) are sent from the WordPress server to the PayPal REST API (api-m.paypal. com) to create a checkout session. Nothing is sent unless the administrator chooses to subscribe. API endpoint contacted: api-m.paypal.com (live) or api-m.sandbox.paypal. com (sandbox testing), the PayPal REST API: https://developer.paypal.com/api/rest Browser-loaded script: PayPal’s JavaScript SDK from www.paypal.com/sdk/js, loaded into the plugin’s admin screen only after an administrator opens the subscription checkout. PayPal requires the SDK be served from its own origin so a compromised build can be revoked, so it cannot be bundled with the plugin. Terms of Service: https://www.paypal.com/us/legalhub/paypal/useragreement-full Privacy Policy: https:// www.paypal.com/us/legalhub/paypal/privacy-full #### AWS EC2 / AMI snapshots (optional, AMI snapshot feature only) **Service:** Amazon Web Services, https://aws.amazon.com/ When the AMI snapshot feature is used, the plugin reads instance metadata (instance ID and region) from the local EC2 Instance Metadata Service at the link-local address 169.254.169.254. This address is only reachable from within an EC2 instance and no data leaves the server at this step. AMI creation, status poll, deregister, and snapshot delete requests are then issued directly to the AWS EC2 REST API (no external tools required). The same AWS credentials (access key ID and secret key) used for S3 are used; if none are configured the plugin attempts to use the EC2 instance role via IMDS. API endpoint contacted: the Amazon EC2 host for the instance’s own AWS region, for example ec2.eu-west-1.amazonaws.com. Terms of Service: https://aws.amazon.com/service-terms/ Privacy Policy: https://aws.amazon.com/privacy/ #### Automatic Crash Recovery: health check probe (optional) When Automatic Crash Recovery is enabled, the plugin periodically sends an HTTP request to the administrator-configured health check URL to verify the site is responding. The URL defaults to the site’s own home URL. No personal data is transmitted. The request is a plain GET with no authentication payload. The same probe is made when the administrator clicks “Test Health Check” in the plugin settings. If a system- cron watchdog script is installed on the server, that script also probes this URL independently via curl. The health check URL is set by the administrator and is never shared with any third party. No Terms of Service or Privacy Policy apply ( the request goes to a URL you own). #### Gmail SMTP port check (only when sending a test email) **Service:** Google, https://workspace.google.com/gmail/ When the administrator clicks Send Test in the Notifications card, the plugin opens a TCP connection to smtp.gmail.com on ports 587, 465 and 25 and closes it at once, to tell whether this server can reach an outside mail server at all. No email, login or data of any kind is sent; only the connection is attempted. Nothing happens until the button is clicked. Terms of Service: https://policies.google.com/terms Privacy Policy: https://policies. google.com/privacy #### Help documentation link The plugin’s header links to its help pages on help.cloudscale.consulting. It is an ordinary link the administrator may choose to open; the plugin itself never requests that host and sends it no data. ### Privacy Policy CloudScale Backup & Restore does not collect, transmit, or store any personal data. All backups are stored locally in the `cloudscale-backups/` folder inside your WordPress uploads directory. No telemetry or analytics are sent by this plugin. Optional cloud backup features (S3, Google Drive, Dropbox, OneDrive, AMI snapshots, CloudScale Managed) transmit data only when explicitly configured by the site administrator. CloudScale Managed backups are encrypted at rest; Encrypt backups adds the site owner’s own password. See the External services section above. ## Tangkapan Layar [⌊Schedule and settings panel showing configurable backup interval in days, run- at hour, retention count, folder sizes, and system information including detected backup and restore methods.⌉⌊Schedule and settings panel showing configurable backup interval in days, run-at hour, retention count, folder sizes, and system information including detected backup and restore methods.⌉[ Schedule and settings panel showing configurable backup interval in days, run-at hour, retention count, folder sizes, and system information including detected backup and restore methods. [⌊Manual backup panel with individual component checkboxes and live progress bar, plus the full backup history table showing stored backups with type badges, age, and Download / Restore DB / Delete actions.⌉⌊Manual backup panel with individual component checkboxes and live progress bar, plus the full backup history table showing stored backups with type badges, age, and Download / Restore DB / Delete actions .⌉[ Manual backup panel with individual component checkboxes and live progress bar, plus the full backup history table showing stored backups with type badges, age, and Download / Restore DB / Delete actions. ## Instalasi **Option 1: WordPress admin (recommended)** 1. Download `cloudscale-backup.zip` 2. In your WordPress admin, go to **Plugins > Add New Plugin > Upload Plugin** 3. Select the zip file and click **Install Now** 4. Click **Activate Plugin** 5. Go to **Tools > CloudScale Backup & Restore** **Option 2: Manual via FTP/SFTP** 1. Unzip `cloudscale-backup.zip` 2. Upload the `cloudscale-backup` folder to `/wp-content/plugins/` 3. Activate via **Plugins > Installed Plugins** 4. Go to **Tools > CloudScale Backup & Restore** ## Tanya Jawab ### 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 ``` ### How do I set up a standby or disaster-recovery copy of my site? 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. ### How do I clone my site to a staging copy on the same server? 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 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 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 ### 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. ### What files does the plugin write outside its own folder? 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-/` – 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. * `/.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. No personal data is stored in any of these files beyond what the site itself already holds. ## Ulasan Belum ada ulasan untuk plugin ini. ## Kontributor & Pengembang “CloudScale Backup & Restore” adalah perangkat lunak open source. Berikut ini mereka yang sudah berkontribusi pada plugin ini. Kontributor * [ andrewjbaker ](https://profiles.wordpress.org/andrewjbaker/) [Terjemahkan “CloudScale Backup & Restore” dalam bahasa Anda.](https://translate.wordpress.org/projects/wp-plugins/cloudscale-backup-restore) ### Tertarik mengembangkan? [Lihat kode](https://plugins.trac.wordpress.org/browser/cloudscale-backup-restore/), periksa [repositori SVN ](https://plugins.svn.wordpress.org/cloudscale-backup-restore/), atau mendaftar ke [log pengembangan](https://plugins.trac.wordpress.org/log/cloudscale-backup-restore/) melalui [RSS](https://plugins.trac.wordpress.org/log/cloudscale-backup-restore/?limit=100&mode=stop_on_copy&format=rss). ## Log Perubahan #### 3.2.846 * IMPROVED: The Managed card reads “Use a password for extra security” with a Set a password button, or confirms backups are encrypted with your password. * FIX: Saving the backup encryption password checks the request’s nonce itself, not only in its callers. #### 3.2.845 * IMPROVED: CloudScale Managed storage adds Oregon (US West), Frankfurt and Tokyo, ten regions in all. N. Virginia now reads as US East. #### 3.2.844 * NEW: The Managed card suggests a backup password for extra security. Setting or changing the encryption password now asks for it twice and a confirmation that a copy is kept. * FIX: A restore of an encrypted backup without the matching password stops before changing anything. * FIX: A database-only backup can be restored again; it was refused for having no files. #### 3.2.843 * FIX: Uploading a large backup to S3 or CloudScale Managed no longer grows the PHP process by the size of the backup. A 3 GB backup could be stopped by the server’s memory limit partway through its cloud uploads. * FIX: The Automatic Restore card no longer logs “Undefined variable $show_hour” and now pre-fills the suggested restore time. #### 3.2.842 * FIX: A standby restoring its primary’s Managed backups reads the region the primary backs up to, not its own region choice or nearest region. #### 3.2.841 * IMPROVED: WordPress.org review pass: output escaped where it is printed, every request value sanitised where it is read, admin scripts attached to the plugin’s script handle, and the External services section completed. Notification emails now show the site name in the header. * FIX: A restore request with an empty file name is refused instead of resolving to the backup folder. #### 3.2.840 * NEW: Choose the CloudScale Managed backup region on the Cloud Backups tab: Automatic( nearest this site) or any of seven regions. Changing region sends new backups there; backups in the old region stop showing and expire there within 90 days, and switching back shows them. * IMPROVED: CloudScale Managed storage adds Singapore, Mumbai and São Paulo, so the regions are US, South America, Europe, Africa, India, Asia and Australia. #### 3.2.838 * IMPROVED: CloudScale Managed storage adds a bucket in Sydney (ap-southeast-2), so the nearest region is now one of US, Europe, Africa or Australia. * IMPROVED: Backup alerts say where a Managed backup is stored, for example “CloudScale Managed: OK, stored in Africa (Cape Town)”. The Managed card and the Explain panel show the region too, instead of saying all storage is in the EU. #### 3.2.836 * IMPROVED: CloudScale Managed storage now has a bucket in Cape Town (af-south- 1) and N. Virginia (us-east-1) as well as Ireland (eu-west-1). On its first managed backup a site times ten requests to each region, and the account is kept in the nearest one from then on. A site in South Africa uploads to Cape Town instead of Ireland, roughly fifteen times faster per connection. #### 3.2.835 * IMPROVED: Large backups now upload to S3 and CloudScale Managed up to four parts at a time instead of one, when the server has the memory for it. Uploads to a distant region were limited by the round trip, not the connection: one 3.2 GB backup took 51 minutes to reach Managed storage. A part that fails in a batch is sent again on its own with the usual retries. #### 3.2.833 * FIXED: A site restored from a backup taken by 3.2.832 could start a full backup of itself a few minutes after the restore. The backup’s own “in progress” record travels inside its database, and the restored site took it for a backup of its own that had died. A run record is now used only by the site that wrote it, and never on a standby. * FIXED: A standby no longer runs a scheduled backup even when one is handed to it. * FIXED: Backup folders left behind by older versions of the plugin are no longer included in the uploads part of a backup. One site’s backup grew from 3 GB to 8 GB because of two old archives in such a folder. #### 3.2.832 * FIXED: A scheduled backup that is killed part-way through its cloud upload (PHP restarted by a deploy or an update, a server reboot, an out-of-memory kill) is now noticed within five minutes and picked up again by itself. The archive is uploaded to the destinations that do not have it yet, and you are told both that it was interrupted and how it ended. Before, the run simply vanished: no alert, no retry, and no new backup in the cloud until the next night. * FIXED: The scheduled backup is now watched for the whole run, uploads included. A PHP error during the upload used to send nothing, because the safety net was switched off once the archive had been written. * FIXED: The cloud catch-up pass no longer stands down for six hours after a backup that died, and it now covers CloudScale Managed and OneDrive as well as S3, Google Drive and Dropbox. * FIXED: A scheduled backup killed while still building its archive is started again, once. * IMPROVED: A second scheduled backup cannot start while the previous one is still uploading. #### 3.2.830 * FIXED: A large backup is no longer lost to one slow part of an Amazon S3 or CloudScale Managed upload. When S3 answers a part with a temporary error (a request timeout, or a 500, 502, 503 or 504), that part alone is now sent again, up to five times with waits of 2, 8, 30 and 60 seconds, instead of the whole upload failing. Before, a single timed-out part on a slow connection discarded a multi-gigabyte upload. * IMPROVED: The time allowed to send one part of a large S3 upload now follows the size of the part (up to 800 seconds for a full 50 MB part, 300 before), so an upload that is slow but still moving is allowed to finish. #### 3.2.819 * CHANGED: The Restore button in the backup list now shows a box with an up arrow instead of a plain circular arrow, which read as “undo” or “refresh” rather than“ restore from a backup”. * IMPROVED: When you choose your own site in “Bring a backup onto this server”, the list now says these are this site’s own backups and that restoring one replaces everything on this site with it. Copying it onto the server is still allowed, as it is how you recover a rebuilt server. #### 3.2.818 * FIXED: A site can no longer be set up to restore itself from its own backups. Automatic restore replaces the whole site with the newest backup of another site, so pointed at its own backups it would undo everything written since the last one, every night. The source list now shows this site greyed out and unselectable, the save refuses it, and a schedule that already has it will not run. A standby copying its primary is unaffected. #### 3.2.817 * FIXED: A restore now clears the site’s persistent object cache (Redis or Memcached). Before, the database was replaced but the cache kept serving the old settings, so a restored site could go on showing its previous theme, plugin list or site settings until the cache was cleared by hand, while the restore reported success. The cache is cleared as soon as the database has been restored, and also after an import that stops part-way. #### 3.2.816 * FIXED: A restore no longer strands your backups in a folder the plugin has stopped looking in. The backup folder’s name carries a private token that was kept only in the database, so restoring a database that lacked it (a standby copying a primary, or a database taken from another site) made the plugin invent a new folder and leave the old one behind, unused, with the backups inside. The token is now also kept in a protected file outside the uploads folder, and the folder name stays the same after a restore. Sites that already have a folder keep it. #### 3.2.815 * FIXED: Automatic Crash Recovery now takes its rollback copy when several plugins are updated at once. Before, it only did so for a single update, so “Update all” in the dashboard and `wp plugin update --all` left every plugin in the batch without a copy to roll back to, and the log said “No pre-update backup found”. Both now get a copy and the same post-update monitoring as a single update. #### 3.2.814 * FIXED: Buying a one-off boost through PayPal could leave the order unpaid. The return link handed to PayPal had its parameters joined with `&` instead of`&`, so when PayPal sent the buyer back the plugin could not find the order and quietly did nothing. The link is now built correctly and a return with a missing or expired security token is logged, with “Recover licence” as the way out. #### 3.2.813 * FIXED: Automatic Crash Recovery no longer keeps copies of a plugin’s PHP files inside the uploads folder. Before each plugin update it copies the plugin so it can roll the update back, and those copies sat under uploads, where a security scanner reads any PHP as a possible compromise. Cyber DevTools’ file-integrity check reported 50 executable files on a standby after WordPress auto-updated one plugin. The copies now live under `wp-content/csbr-state/`, outside uploads, with deny rules. Rolling back works exactly as before, and copies taken by earlier versions are still used and are cleared by the same 72-hour sweep. #### 3.2.812 * ADDED: Clone to a staging site. Restore any backup into a separate WordPress install on the same server, with its own directory and database and every URL rewritten, instead of over the live site. Set up targets on the new Clone Targets tab, run one with Clone Now (which names what it will overwrite and asks first) or refresh it after each scheduled backup on the days you pick. * ADDED: The clone refuses to run against this site’s own database or directory, or a directory that contains this site, and checks a target’s wp-config.php is writable before it deletes anything. * ADDED: `csbr_clone_post_restore` PHP action for steps to run after a clone. The clone runs no shell scripts. #### 3.2.809 * FIXED: A restore now replaces files the web server cannot open for writing, such as files owned by another user after an SFTP upload, a control-panel edit or a host-side deploy. Those files were reported as “could not be written” and the stale copy was left in place, so the restore was partial while looking complete apart from a warning. The new file is written beside the old one and swapped in atomically, so a failure part way leaves the old file, never a gap. A file whose directory is not writable is still reported. * FIXED: The restore warning that lists files which could not be written printed“ Array; Array; Array” instead of naming them. It now names the component, the reason and an example path, as the WP-CLI output already did. #### 3.2.806 * FIXED: Backups failed in their first second on sites where the database is dumped by PHP, with “count(): Argument #1 must be of type Countable|array, null given”. A variable was released two lines before it was counted. Introduced in 3.2.799. If you installed 3.2.799 to 3.2.805, check that your scheduled backups have been running. * CHANGED: The Last recovery panel leaves out a phase that took no time, such as the copy from cloud storage when the backup was already on the server. #### 3.2.805 * CHANGED: On the Recover a site tab, the “Cannot log in to wp-admin at all?” card has moved to the bottom, after the restore steps it used to interrupt. When Automatic Crash Recovery is already on it is now a single line saying so, and the full card appears only when it is off. #### 3.2.804 * ADDED: A “Last recovery” panel on the Recover a site tab. It shows how long the last restore really took, split into the copy from cloud storage, files, database and checking, how big it was, and how old the backup was when it was restored. * ADDED: Reconciliation. When a restore finishes, every file in the backup is looked up on disk and any that are missing or the wrong size are counted and named. The panel also checks, live, for anything left lying around: a maintenance file, a restore frozen part way, a half-copied backup, or an operation that never reported its ending. * ADDED: The restore-succeeded alert now carries the recovery time, sizes and the reconciliation result. * FIXED: A restore that died without cleaning up left the maintenance file on disk for ever. It is now cleared on the next admin page load, recorded as a failed restore, and alerted once. #### 3.2.803 * FIXED: A restore could die on any large file. Each file in the backup was read into memory whole, so a single 121 MB file under a 128 MB PHP memory limit killed the restore on its fourteenth file. Files are now streamed to disk, and a 48 MB file restores in 2 MB of memory. * FIXED: When a restore, backup, cloud copy or cloud sync hit a fatal error in the background, nothing was reported at all: no alert, no failed job, and maintenance mode left on. The safety net for this could never run because of where the work was started from. It runs now. * FIXED: A restore that was refused because another was already running could start anyway. * FIXED: The automatic restore status stopped checking the first time the server lost the job, and told you to reload. It now keeps following through maintenance mode and the database being replaced, and says so plainly if the restore stalls. * IMPROVED: Restoring files now reports progress as it goes, instead of sitting at 0% until every file is written. #### 3.2.802 * CHANGED: “Run the automatic restore now” asks for its confirmation in the plugin’s own dialog instead of a browser prompt, with the word to type shown in bold and an Explain button. * ADDED: A progress bar under the automatic restore status while a manual run is copying and restoring. #### 3.2.801 * FIXED: “Run the automatic restore now” never restored anything. It recorded its own job as running, then saw that record, decided a restore was already in progress and skipped itself within a couple of seconds. * FIXED: The result of a manual automatic-restore run was wiped by a page reload 2.5 seconds later, so a run that refused looked like a button that did nothing. Failures now stay on screen, in a visible status box, and a skipped run is no longer shown with a tick. * CHANGED: “Run the automatic restore now” asks you to type confirm before it starts, instead of REPLACE THIS SITE. #### 3.2.800 * FIXED: An “Automatic Restore” box appeared at the bottom of every tab on sites with Google Drive, Dropbox or OneDrive backup history. Three unclosed attributes on the Manual Restore tab let its contents spill out of the tab. * CHANGED: “Run the automatic restore now” has moved next to Save schedule and Check the source now on the Recover a site tab, beside the settings it runs. It still asks you to type REPLACE THIS SITE first. The separate box on Manual Restore is gone. #### 3.2.799 * SECURITY: Your Google Drive, Dropbox and OneDrive credentials were stored in the database, which meant every backup contained them. A site restored from one of your backups came up able to read and delete the backups in your cloud account. They are now stored outside the database and moved across automatically when you update. * SECURITY: The file holding your cloud credentials, licence key and backup encryption password could briefly be downloaded from your site while it was being written. It is now protected for its whole life, and any leftovers from an interrupted write are cleaned up. * SECURITY: The health-check address in Automatic Crash Recovery was not escaped when written into the monitoring script that runs as root, so anyone who could reach the settings page could run commands on the server. * SECURITY: The Dashboard widget and its script loaded for every logged-in user, including subscribers, exposing backup counts, disk space and cloud sync status. Both are now administrator-only. * SECURITY: Cloning to another site could drop every table in THIS site’s database if the clone target still pointed at this installation’s wp-config.php. * FIXED: Encrypted backups were always reported as corrupt. The verifier was not given the encryption password, so it could not read inside the archive and marked good backups as failed. * FIXED: Dropbox retention never deleted anything unless you had clicked Refresh on the Dropbox card at least once, so old Dropbox backups built up without limit. * FIXED: A backup taken while the site was busy could silently miss rows, because the database was read in pages with no guaranteed order. * FIXED: Restores started from WP-CLI, from a standby’s automatic restore, or from the clone tool let visitors back onto the site after ten minutes, part-way through the restore. * FIXED: A scheduled backup could start during a restore and store a copy of a half-restored database. * FIXED: Downloading a large backup from Google Drive, Dropbox, OneDrive or S3 could time out. Only the local download streamed properly; the other four now do too. * FIXED: A standby site with incorrect cloud credentials slowed every page on the front end. * FIXED: A standby reported backups as arriving late when they had arrived in good time. * FIXED: Restoring a database dump created by mysqldump or phpMyAdmin merged into your existing database instead of replacing it, while reporting success. Comment lines in those dumps were being read as part of the statement below them, so the instruction to replace each table was skipped and its rows were added to the old table. Backups made by this plugin were never affected. Dumps from other tools now restore correctly. * FIXED: A restore that the database rejected is now reported as a failure. Rejected statements were counted and logged, but the restore still recorded itself as successful, sent a success notification and took the site out of maintenance mode. It now stops and tells you the database needs restoring again from a known- good backup. * FIXED: Cloning to another site could drop every table in THIS site’s database if the clone target still pointed at this installation’s wp-config.php. The clone now checks the target database as well as the target directory, and refuses unless you have explicitly allowed it. #### 3.2.787 * ADDED: A standby site now remembers when the last 14 backups actually arrived in your cloud storage, and suggests a restore time that sits clear of all of them. It also warns when backups have started arriving after the time you chose, which otherwise only shows up as a refused restore the next morning. The suggestion is never applied on its own. * FIXED: When the plugin could not read your account, it said “this account holds no backups yet” instead of saying what went wrong. An error and an empty account are now told apart, and failures name the reason. #### 3.2.784 * FIXED: The activity log could hide recent entries, so a backup that had just succeeded looked like it had never run. Entries were stored under one name and looked for under another, and the periodic tidy-up that made them visible ran on a one-in-ten chance. The log now shows everything that has been written, immediately, and Clear now really clears. * FIXED: Scheduled jobs other than the main backup could fail without telling anyone. A PHP fatal cannot be caught by ordinary error handling, so the nightly cloud upload, the exposure probe and the AMI checks could simply stop, leaving nothing in the log and no alert. All scheduled jobs now report failures the same way the backup does. * FIXED: After a backup, the “last backup” time, the in-progress marker and the failure flag could disagree with each other. They are now all set in one place, and the time comes from the backup file itself. #### 3.2.782 * FIXED: The “Copy Last Backup to Cloud” button appeared five times, once per cloud provider, with the same wording each time. Each one now names its destination, so you can tell which cloud you are about to upload to without scrolling back to the card heading. #### 3.2.781 * FIXED: Scheduled backups could fail with “Call to undefined function wp_tempnam()” while manual backups from the admin screen kept working. The function lives in a WordPress admin file that scheduled jobs never load, so the nightly backup died and the one you clicked yourself did not. Every use now loads that file first. * FIXED: A site marked as a refreshed copy no longer sends any email. A copy has the original site’s users and orders, so a password reset or an order confirmation would otherwise go to a real customer from a test machine. Sites marked as a hot standby still send, because they are meant to take over. Blocked messages are logged so you can see what was stopped. * FIXED: The flag that tells a standby whether it is currently serving live traffic is now ignored when it is out of date, rather than believed indefinitely. #### 3.2.779 * ADDED: A “Standby & DR” tab. Setting up a second site needed four settings in three different places and nothing said what they were for. This asks one question instead: is this the live site, a hot standby that should take over if the live site dies, or a refreshed copy for testing. It then sets everything that answer implies, and shows a checklist of what is done and what is left, including the DNS wiring a takeover needs that no plugin can do for you. * FIXED: A crash that could take the whole admin area down when two CloudScale plugins were active together. A shared class guarded itself against being declared twice in a way that does not work when PHP’s opcache is on, so the second plugin to load could fatal. All the shared classes now use the form that actually holds. * FIXED: Automatic restore refused to run on any site in failover mode, even when that site was only armed to take over rather than actually serving. Those are different things, and the first is the normal state of a standby, so the nightly refresh could never be switched on. It now refuses only when the site is genuinely carrying the live site’s traffic, or when nothing can tell it either way. * FIXED: The Recover tab said you could choose which components to put back and offered no such control; that picker is on the Manual Restore tab, and it now says so. #### 3.2.773 * ADDED: The plugin now has its own top-level menu with an icon, instead of hiding under Tools. This is the screen you open when something has gone wrong, and on a phone the Tools submenu was several taps away. Existing links and bookmarks to the old address still work. * FIXED: The label that marks alerts as coming from a standby or test copy is no longer stored in the database. A standby has the live site’s database restored over it, which erased the label and left the copy’s alerts looking identical to the real site’s. It is now stored in a file that a restore cannot touch, an existing label is moved there automatically, and you can set it in a new Alert Label card on the Environment tab. * FIXED: On hosting where wp-content cannot be written, setting that label now refuses and tells you the line to add to wp-config.php, instead of saving it somewhere a restore would wipe. #### 3.2.769 * ADDED: Automatic restore. A standby site can now refresh itself from your primary site’s newest cloud backup on a schedule: it lists your cloud storage, refuses if the newest backup is too old, copies it to the server and restores from it. Set it up at the bottom of the Restore tab. It uses the same copy and the same restore the buttons on those screens use, so there is no second code path to drift. * FIXED: The Restore tab’s introduction said it rolls back your database. Restores have put your files back as well since 3.2.762, so the most prominent sentence on that screen was describing the old behaviour. * ADDED: A staleness limit, which is the point of the feature rather than a detail. A standby that quietly restores last week’s backup every night looks perfectly healthy and is useless for failover, so a run refuses when the newest backup is older than the limit you set, and the refusal raises an alert. The default is 36 hours: long enough that one missed nightly backup does not alarm you, short enough that two do. * ADDED: The cloud folder to restore from can be named explicitly, so several standby sites (a staging copy and a disaster-recovery copy, say) can both track one primary. Each one only ever reads that folder, so they cannot interfere with each other or with the primary. * ADDED: “Check the source now” answers “would tonight’s run work?” without touching your site, naming the backup it would pick, how old it is, and whether there is room for it on the server. * ADDED: The backup lists now show which backups have already been restored onto this machine, with the time, and the button becomes “Restore again”. Previously a backup restored an hour ago looked identical to one merely downloaded, so the most destructive button in the plugin went on inviting you to repeat work already done. Failed attempts are shown too. * ADDED: A wp csbr auto-restore command, so a server timer can drive the job without relying on WP-Cron. * SECURITY: Automatic restore refuses to run, and refuses to be switched on, on a site marked as the primary, and refuses while failover mode is on, because that means the copy is serving live traffic and holds content that exists nowhere else. Switching it on asks you to type REPLACE THIS SITE. Its settings are stored in a file rather than the database, because every run replaces the database with the primary’s copy, which would otherwise switch the schedule off after the first successful run without saying so. #### 3.2.717 * FIXED: The cloud storage space check could let a backup start that did not fit. It sized the backup from whichever backup file was “newest”, but picked that file by name rather than by date, and ignored what the backup actually contained, so a small database-only backup made overnight could make a full backup look a fraction of its real size. If no backup existed yet it skipped the check altogether, which meant the very first backup after installing, the one most likely to fill a free Google Drive, was never checked. It now uses the same size estimate the local disk check uses. Older versions: see CHANGELOG.md in the plugin folder. ## Meta * Versi **3.2.846** * Diperbarui **7 jam yang lalu** * Instalasi Aktif **Kurang dari 10** * Versi WordPress ** 6.0 atau yang terbaru ** * Diuji hingga **7.1.3** * Versi PHP ** 8.1 atau yang terbaru ** * Bahasa * [English (US)](https://wordpress.org/plugins/cloudscale-backup-restore/) * Tag * [backup](https://id.wordpress.org/plugins/tags/backup/)[database](https://id.wordpress.org/plugins/tags/database/) [maintenance mode](https://id.wordpress.org/plugins/tags/maintenance-mode/)[restore](https://id.wordpress.org/plugins/tags/restore/) [scheduled backup](https://id.wordpress.org/plugins/tags/scheduled-backup/) * [Tampilan lanjut](https://id.wordpress.org/plugins/cloudscale-backup-restore/advanced/) ## Rating No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/cloudscale-backup-restore/reviews/#new-post) [Lihat semua ulasan](https://wordpress.org/support/plugin/cloudscale-backup-restore/reviews/) ## Kontributor * [ andrewjbaker ](https://profiles.wordpress.org/andrewjbaker/) ## Bantuan Ada yang ingin dikatakan? Butuh bantuan? [Lihat forum bantuan](https://wordpress.org/support/plugin/cloudscale-backup-restore/)