CloudScale Backup & Restore

Dnevnik promjena

3.2.858

• FIX: Uninstall now removes the plugin’s state files in wp-content. Backup archives, the token naming their folder, and the site-role and alert-label markers shared with other CloudScale plugins are kept on purpose.
• TWEAK: Rewrote the plugin description and FAQ.

3.2.857

• TWEAK: The restore modal’s “Full database, drop and recreate all tables” option is now “Full restore”. It always restored the backup’s files as well as its database, and the label and warning now say so.

3.2.856

• FIX: OneDrive and Dropbox uploads retry a chunk that fails on a dropped connection, a throttle (429) or a server error (5xx), up to 5 attempts, instead of losing the whole upload. They resume where the provider says it is and honour Retry-After. Google Drive follows the same rules and now retries a 429 too.
• FIX: Dropbox refreshes an access token that expires during a long upload.
• FIX: wp csbr restore and wp csbr sync-from-cloud now run the same restore as the Restore button. The password check, file check, drop-in health check and alerts now apply to WP-CLI, and files-only backups work there.
• TWEAK: Removed 12 server actions that nothing in the plugin called.

3.2.855

• FIX: Test Connection for Google Drive, Dropbox and OneDrive failed to detect revoked credentials; it now shows the provider’s error.
• FIX: A failed cloud listing no longer erases which backups are golden, so they can’t be pruned by mistake.
• FIX: Delete oldest on Google Drive could delete the newest backup.
• FIX: Saving the AMI card no longer resets “Max Cloud Backups to Keep” to 10.
• FIX: Backups are verified before old ones are pruned; a corrupt or half-written backup is reported as failed and not uploaded.
• FIX: Database read errors during a backup now fail it instead of producing a short dump.
• FIX: Dropbox can be connected on a fresh install; cloud downloads refresh expired tokens and no longer stop at 300 seconds.
• FIX: CloudScale Managed uploads once, and managed storage is pruned when S3 is unticked.
• FIX: S3, Google Drive and OneDrive listings follow every page.
• FIX: Restore fails if file extraction stops part way; files-only backups restore without touching the database.
• FIX: Clone URL rewrite failures are reported; nested serialized values are rewritten correctly.
• FIX: Crash recovery finds its settings again (alerts and recovery page), and rollback never deletes the plugin before the old version is ready.
• FIX: Auto-restore fixed time is saved; an empty backup-day list stays empty; Telegram test sends once.
• NEW: System Info health checks (PHP, folder, ZIP/AES, WP-Cron, overdue schedule, last result per destination) and wp csbr doctor.
• NEW: S3 Test checks list and delete permissions and removes its test file; Managed Test checks storage credentials.
• NEW: Activity log records skipped uploads, OAuth and token errors, dump/archive timings, skipped days and undelivered alerts.

3.2.854

• FIX: Google Drive’s “Authorised redirect URI” box now shows the URI Connect sends (admin.php), so registering it no longer fails with redirect_uri_mismatch.
• FIX: OneDrive gets the pre-sync space check and Delete oldest, like Dropbox and Google Drive.
• FIX: A skipped cloud upload says to tick the provider under “Include in cloud backup” and Save, instead of “not configured”.
• FIX: S3 Diagnose shows bucket, prefix, credentials source, last sync and the Include setting.
• Changed: S3 and AMI text no longer say the AWS CLI is required; the plugin talks to AWS directly.

3.2.852

• FIX: OneDrive uploads no longer report “OneDrive not configured” after a successful Test Connection. The OneDrive tick under “Include in cloud backup” is now saved; tick it and save once after updating.
• Changed: Dropbox and OneDrive Explain and Diagnose describe the built-in API connection, not rclone, which is not needed.

3.2.848

• Changed: alert-sync hooks use literal, prefixed names for WordPress.org Plugin Check.

3.2.847

• Changed: alert settings (Telegram, environment label, mute) are stored under this plugin’s own prefix, migrated automatically, and kept in sync with the other CloudScale plugins.

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.

Older versions: see CHANGELOG.md in the plugin folder.