Title: CloudScale Backup & Restore
Author: andrewjbaker
Published: 31. 5. 2026
Last modified: 21. 9. 2026
---
Prohledat pluginy
# CloudScale Backup & Restore
Autor: [andrewjbaker](https://profiles.wordpress.org/andrewjbaker/)
[Stáhnout](https://downloads.wordpress.org/plugin/cloudscale-backup-restore.3.2.817.zip)
* [Podrobnosti](https://cs.wordpress.org/plugins/cloudscale-backup-restore/#description)
* [Hodnocení](https://cs.wordpress.org/plugins/cloudscale-backup-restore/#reviews)
* [Instalace](https://cs.wordpress.org/plugins/cloudscale-backup-restore/#installation)
* [Vývojáři](https://cs.wordpress.org/plugins/cloudscale-backup-restore/#developers)
[Podpora](https://wordpress.org/support/plugin/cloudscale-backup-restore/)
## Popis
**Most backup plugins fail exactly when you need them most: on your biggest site,
or the site that’s grown since you installed them.** All-in-One WP Migration’s free
version caps imports at 512MB (its Unlimited extension costs $69/year to remove
the cap). Duplicator’s free version starts failing and timing out around 500MB,
with no chunking until you upgrade to Pro. UpdraftPlus has no hard site-size limit,
but its free version is restricted to a single cloud storage destination, so you’re
stuck with whatever free-tier space that one provider gives you.
**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, reliably,
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, and every destination you enable gets
a copy of every backup.
#### Any Size, No Limits
* Streams the database in 500-row chunks via `$wpdb`; never loads the full database
into memory, regardless of size
* `set_time_limit(0)` and `ignore_user_abort(true)` on every backup and restore,
so PHP’s execution-time limit never cuts a large operation off mid-run
* 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
* Configurable retention: keep the last N backups on every destination, deleted
automatically after each run. Managed copies are additionally capped at 90 days
in storage, enforced even if the site stops running; your own cloud destinations
follow whatever lifecycle rules you set on your own bucket
* 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`: plugin version, creation timestamp, WordPress
version, site URL, table prefix, and which components were included, so you can
verify 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 modal that:
1. Shows the exact backup file name and creation date you are restoring from
2. Displays a warning box explaining what will happen step by step
3. Requires you to tick a checkbox: _„I have taken a server snapshot and understand
this will overwrite the live database“_
4. Only enables the Restore button after that checkbox is ticked
During restore, WordPress’s native `.maintenance` file is created so visitors see
the standard maintenance page. It is always removed when restore finishes, whether
the restore succeeded or failed. The plugin header shows a live badge indicating
whether the site is online or in maintenance mode.
#### 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, so a standby quietly restoring last week’s backup
cannot look healthy. If the backup is late it waits for up to three hours, looking
every 15 minutes, before alerting
* 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 polls the primary, repoints one DNS record at the standby after three
consecutive failures, and points it back after ten consecutive clean probes.
Every failback prints a reconcile reminder, because work done on the standby
while it served exists nowhere else and the standby’s next refresh erases it.
Not included in this zip, which carries no shell scripts
* 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
* Configurable scheduling: any interval in days, and the exact hour of day to run
* Full backup history: view all stored backups with filename, type label, size,
creation date, and age; download any backup directly from the WordPress admin
* 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)
When Telegram is configured, the plugin sends backup, restore, and plugin
rollback
notifications, plus error alerts, to the administrator-configured Telegram chat
via the Telegram Bot API. The message contains the site name, event status, and (
for error alerts) a summary of the PHP error, file name, and line number. No personal
visitor data, post content, or backup data is transmitted. No data is sent unless
a Telegram bot token and chat ID have been entered in the plugin’s Notifications
settings. API endpoint contacted: https://api.telegram.org/bot{token}/sendMessage
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)
When S3 settings are configured, the plugin uploads backup zip files directly
to
the administrator’s own S3 bucket via the AWS S3 REST API (no external tools required).
Only the backup zip file is transmitted. Credentials (bucket name, access key ID,
secret access key, region) are stored in the WordPress options table and are never
sent anywhere except to the AWS S3 endpoint. API endpoint contacted: https://s3.{
region}.amazonaws.com/ Terms of Service: https://aws.amazon.com/service-terms/ Privacy
Policy: https://aws.amazon.com/privacy/
#### Google Drive (optional cloud backup)
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 endpoint contacted: https://www.googleapis.com/ and https://oauth2.googleapis.
com/ Terms of Service: https://policies.google.com/terms Privacy Policy: https://
policies.google.com/privacy
#### Dropbox (optional cloud backup)
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 endpoint contacted: https://api.dropboxapi.com/
and https://content.dropboxapi.com/ Terms of Service: https://www.dropbox.com/terms
Privacy Policy: https://www.dropbox.com/privacy
#### Microsoft OneDrive (optional cloud backup)
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://privacy.microsoft.com/en-us/
privacystatement
#### CloudScale Managed Cloud Backup (optional, paid service)
When the administrator subscribes to the optional CloudScale Managed Cloud Backup
service, the plugin contacts the CloudScale broker to request a short-lived, prefix-
scoped Amazon S3 access token, then uploads backup zip files directly to CloudScale’s
managed S3 storage (hosted in the EU, eu-west-1). Only the site’s domain name, the
subscription licence key, and the backup zip file are involved; the backup bytes
are uploaded straight to S3 and do not pass through the broker. No data is sent
unless the administrator has subscribed and entered a licence key. API endpoint
contacted: https://api.cloudscale.consulting/ (broker) and https://cloudscale-backup-
restore-global.s3.eu-west-1.amazonaws.com/ (storage) Terms of Service: https://cloudscale.
consulting/terms Privacy Policy: https://cloudscale.consulting/privacy
#### PayPal (optional, payment for Managed Cloud Backup)
Subscription payments for the optional CloudScale Managed Cloud Backup service are
processed by PayPal. Payment details are entered on PayPal’s own hosted checkout
page and are never collected, stored, or transmitted by this plugin. When the administrator
starts a subscription, the subscriber’s email address and a PayPal order amount (
$5.00 USD) are sent directly from the WordPress server to the PayPal REST API (api-
m.paypal.com) to create a checkout session; no payment-card data is handled by the
plugin or the WordPress site. No data is sent unless the administrator chooses to
subscribe to the paid service. API endpoint contacted: https://api-m.paypal.com/(
live) or https://api-m.sandbox.paypal.com/ (sandbox testing) Browser-loaded script:
https://www.paypal.com/sdk/js – PayPal’s JavaScript SDK, 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/useragreement-full Privacy Policy: https://www.paypal.com/us/legalhub/
privacy-full
#### AWS EC2 / AMI snapshots (optional, AMI snapshot feature only)
When the AMI snapshot feature is used, the plugin reads instance metadata
(instance
ID and region) from the local EC2 Instance Metadata Service at http://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: https://ec2.{region}.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).
### 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) transmit data
only when explicitly configured by the site administrator. See the External services
section above.
## Snímky obrazovky
[⌊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.
## Instalace
**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**
## Nejčastější dotazy
### 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.
## Recenze
Pro tento plugin nejsou žádné recenze.
## Autoři
CloudScale Backup & Restore je otevřený software. Následující lidé přispěli k vývoji
tohoto pluginu.
Spolupracovníci
* [ andrewjbaker ](https://profiles.wordpress.org/andrewjbaker/)
[Přeložte “CloudScale Backup & Restore” do svého jazyka.](https://translate.wordpress.org/projects/wp-plugins/cloudscale-backup-restore)
### Zajímá vás vývoj?
[Prohledejte kód](https://plugins.trac.wordpress.org/browser/cloudscale-backup-restore/),
podívejte se do [SVN repozitáře](https://plugins.svn.wordpress.org/cloudscale-backup-restore/),
nebo se přihlaste k[ odběru protokolu vývoje](https://plugins.trac.wordpress.org/log/cloudscale-backup-restore/)
pomocí [RSS](https://plugins.trac.wordpress.org/log/cloudscale-backup-restore/?limit=100&mode=stop_on_copy&format=rss).
## Přehled změn
#### 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.
#### 3.2.716
* ADDED: Failover mode can now be switched on from the Environment tab. Failover
mode makes a site refuse to create any backup at all, stronger than the standby
role, which only stops cloud uploads and pruning. It is for a copy of your site
that is temporarily serving live traffic, so it cannot start a second backup
history alongside the real one. Previously it could only be set in wp-config.
php or by your hosting provider, so on most shared hosting it could not be reached
at all, even though the dashboard described it. If your host has pinned the setting,
that still wins and the screen says so.
* ADDED: Turning failover mode on asks you to type STOP BACKUPS first. It stops
every backup on the site, including scheduled ones, and nothing warns you afterwards,
a site that has stopped backing up is silent. Turning it off again is a single
click.
* FIXED: The dashboard notice now says what set failover mode, a constant, your
hosting provider, or this site, instead of telling everybody it could not be
changed.
#### 3.2.715
* ADDED: Copy a cloud backup straight to this server. The Restore tab could only
download a backup to your own computer, so restoring a 2.5 GB backup meant downloading
2.5 GB and uploading it back again, to put a file on a server that can already
reach the same storage. Every provider (S3, Google Drive, Dropbox, OneDrive and
CloudScale Managed) now has a „Copy to server“ button beside Download. The backup
lands under Local Backups, ready to restore. Restoring stays a separate step,
because fetching a file should never overwrite your site by itself.
* ADDED: Copying checks free space first, and downloads to a temporary name so
a dropped transfer cannot leave a half-finished file looking like a backup you
could restore from. Nothing is deleted to make room, it tells you how much space
it needs instead.
* ADDED: Restores now check there is room before writing anything. A restore that
fills the disk half way leaves your site both broken and unable to write anything
else; this one stops first and leaves the site untouched. The size is read from
the backup file itself and counts only the parts you are actually restoring.
#### 3.2.713
* ADDED: A backup can no longer fill the disk, and no longer has to be abandoned
when space is tight. Before writing anything, the plugin estimates the size of
the backup it is about to take and checks that free space is at least three times
that estimate. If it is not, the oldest backups are aged out one at a time until
there is enough room, and the backup goes ahead. Only when there is nothing left
to age out is the backup failed, because running the volume to zero does not
simply lose a backup, it stops MySQL and PHP being able to write at all.
* ADDED: When older backups have to be aged out early, the backup report says so,
stating how many backups are being kept against the number you asked to retain,
which files were removed, and how much space would be needed to stop it happening.
A backup history quietly shorter than the one you configured is otherwise only
discovered when you reach for a backup that is not there. The last remaining
backup is never deleted to make room for a new one.
Older versions: see CHANGELOG.md in the plugin folder.
## Meta
* Verze **3.2.817**
* Poslední aktualizace **před 2 dny**
* Aktivních instalací **Méně než 10**
* Verze WordPressu ** 6.0 nebo novější **
* Testováno až do WordPressu **7.1.2**
* Verze PHP ** 8.1 nebo novější **
* Jazyk
* [English (US)](https://wordpress.org/plugins/cloudscale-backup-restore/)
* Štítků
* [backup](https://cs.wordpress.org/plugins/tags/backup/)[database](https://cs.wordpress.org/plugins/tags/database/)
[maintenance mode](https://cs.wordpress.org/plugins/tags/maintenance-mode/)[restore](https://cs.wordpress.org/plugins/tags/restore/)
[scheduled backup](https://cs.wordpress.org/plugins/tags/scheduled-backup/)
* [Podrobnosti](https://cs.wordpress.org/plugins/cloudscale-backup-restore/advanced/)
## Hodnocení
Zatím nebyly zadány žádné recenze.
[Vaše hodnocení](https://wordpress.org/support/plugin/cloudscale-backup-restore/reviews/#new-post)
[Zobrazit všechny recenze](https://wordpress.org/support/plugin/cloudscale-backup-restore/reviews/)
## Spolupracovníci
* [ andrewjbaker ](https://profiles.wordpress.org/andrewjbaker/)
## Podpora
Potřebujete pomoc?
[Fórum podpory](https://wordpress.org/support/plugin/cloudscale-backup-restore/)