Title: CloudScale Backup & Restore Author: andrewjbaker Published: 31 Maggio 2026 Last modified: 26 Agosto 2026 --- Ricerca i plugin ![](https://ps.w.org/cloudscale-backup-restore/assets/icon-256x256.png?rev=3555613) # CloudScale Backup & Restore Di [andrewjbaker](https://profiles.wordpress.org/andrewjbaker/) [Scarica](https://downloads.wordpress.org/plugin/cloudscale-backup-restore.3.2.700.zip) * [Dettagli](https://it.wordpress.org/plugins/cloudscale-backup-restore/#description) * [Recensioni](https://it.wordpress.org/plugins/cloudscale-backup-restore/#reviews) * [Installazione](https://it.wordpress.org/plugins/cloudscale-backup-restore/#installation) * [Sviluppo](https://it.wordpress.org/plugins/cloudscale-backup-restore/#developers) [Supporto](https://wordpress.org/support/plugin/cloudscale-backup-restore/) ## Descrizione **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 * Failover Mode: a standby server never creates, schedules, or allows a manually- or WP-CLI-triggered backup while flagged as a failover target, and says so on every admin screen * 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 #### 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). ### Files written outside the plugin 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. ### 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. ## Screenshot [⌊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. ## Installazione **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** ## FAQ ### 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 ``` ### 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. ## Recensioni Non ci sono recensioni per questo plugin. ## Contributi e sviluppo “CloudScale Backup & Restore” è un software open source. Le persone che hanno contribuito allo sviluppo di questo plugin sono indicate di seguito. Collaboratori * [ andrewjbaker ](https://profiles.wordpress.org/andrewjbaker/) [Traduci “CloudScale Backup & Restore” nella tua lingua.](https://translate.wordpress.org/projects/wp-plugins/cloudscale-backup-restore) ### Ti interessa lo sviluppo? [Esplora il codice](https://plugins.trac.wordpress.org/browser/cloudscale-backup-restore/) segui il [repository SVN](https://plugins.svn.wordpress.org/cloudscale-backup-restore/), segui il [log delle modifiche](https://plugins.trac.wordpress.org/log/cloudscale-backup-restore/) tramite [RSS](https://plugins.trac.wordpress.org/log/cloudscale-backup-restore/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 3.2.700 * Fixed: The S3 client used direct `curl_setopt()` calls (via the `http_api_curl` filter) to stream file uploads without buffering: `CURLOPT_UPLOAD`/`CURLOPT_INFILE` for files under the multipart threshold, and a progress-only callback for files above it. WordPress.org’s plugin review policy treats any direct cURL usage as a hard rejection regardless of `phpcs:ignore` annotation. Small files (under the 100MB multipart threshold) are now read into memory and sent as a plain ` wp_remote_request()` body, which is bounded and safe at that size; large files already went through bounded 50MB chunks via `wp_remote_request()` in the multipart path, so the only change there is dropping a cosmetic sub-part progress callback that required cURL. No change to the “any size, no memory limit” guarantee: memory use for a single upload is still capped at the multipart part size or the 100MB threshold, whichever path is taken, regardless of total backup size. #### 3.2.699 * Changed: Rewrote the Description and tagline. The opening now quotes named competitor size limits (All-in-One WP Migration’s 512MB import cap, Duplicator’s ~500MB free-version ceiling, UpdraftPlus’s single-destination free tier) to make the“ no size limit” claim concrete, and restructured the flat feature list into headed sections so Managed Cloud Backup pricing, the five simultaneous cloud destinations, EC2 AMI snapshots, Failover Mode, and the security hardening (randomised directory, multi-webserver protection, daily public-access self-check) are no longer buried in the Changelog/FAQ and actually appear on the page. #### 3.2.698 * ADD: Cloud backups uploaded via the CloudScale broker now write to Amazon S3 Glacier Instant Retrieval instead of Standard storage. The 750 GB managed-storage ceiling is priced against Glacier IR ($4.50/month); the same footprint on Standard runs about $17/month. The Retention card now has a “Keep cloud backups for” control( 1-3 months, default 2), with the storage space it allows shown derived rather than typed. * FIX: WP_Error messages describing timeouts and durations reported milliseconds( e.g. “300000 milliseconds” for a 300-second ceiling) instead of seconds. All 32 rendered messages now go through a shared seconds-formatter. * FIX: WordPress.org submission-review pass, 60 findings down to 16 (the remaining 16 are set_time_limit() calls kept deliberately, since removing timeout extension from a backup plugin risks a large operation failing mid-run with no resume path): 10 unescaped attribute echoes fixed, 3 HTML-entity icons converted to literal UTF-8 with proper escaping, the undisclosed PayPal SDK load now documented in External Services, five S3/EC2 endpoint strings annotated as non-offloading, the emoji resource-hint filter matched a host as a substring (incorrectly stripping unrelated hosts like ps.w.org) and now matches exactly, and five set_time_limit()/ ini writes removed where the PHP manual confirms they had no effect on I/O-bound operations. * FIX: The backup zip download sent a Content-Length describing the pre-compression size when zlib.output_compression was active, truncating some downloads; the header is now omitted when compression is on. * FIX: Tested up to bumped from 7.0 to 7.1. * FIX: Telegram notifications now log transport failures and non-200 responses instead of failing silently; PayPal order creation now reports an invalid-JSON broker response distinctly from an HTTP-status failure. * CLEANUP: Removed stale Twilio SMS and ntfy push-notification disclosures (both replaced by Telegram) and a dead Paystack payment disclosure (retired in favour of PayPal) from External Services; merged the readme’s two separate “External Services” sections into one. #### 3.2.692 * ADD: Failover mode. Set CSBR_FAILOVER_MODE, or write /etc/cloudscale/failover- mode, on the host and this install will never create a local backup, schedule one, or allow one to be triggered by hand or by WP-CLI — and it says so on every admin screen: “Not Backing Up: In Failover Mode”. Intended for a DR standby that may be taken live temporarily. It is a constant rather than a setting on purpose: the site-role flag flips to primary during a failover, and a standby is rebuilt by restoring the primary’s database, so anything held in the database comes back switched on. * FIX: Verifying a backup with an empty filename tried to open the backup DIRECTORY as a zip archive, because the empty name concatenates to the directory path and file_exists() is true for a directory. It now reports that no backup file was produced, which is the actual reason. #### 3.2.688 * SECURITY: Local backups were protected only by an .htaccess deny-all, and .htaccess is inert on nginx, Caddy, LiteSpeed without rewrite support, and IIS. On those servers the archives were downloadable by anyone who guessed a filename — and the filenames are sequential (backup_F185, F186, F187), so guessing one gives you all of them. A backup contains your wp-config.php database credentials and auth salts plus a full database dump including password hashes. Found on a live site serving a 2 GB archive as HTTP 200 to an anonymous request. * SECURITY: The backup directory is now uploads/cloudscale-backup-/ instead of a fixed, guessable name. Existing backups are migrated into it on upgrade; a file is only removed from the old location once the copy is confirmed the same size, and anything that cannot be moved is left in place rather than lost. * SECURITY: Protection is no longer Apache-only. The plugin writes an .htaccess covering both mod_authz_core (Require all denied) and 2.2 (Order/Deny) syntax, a web.config for IIS, a silent index.php, and sets the directory to 0700 — which is the only one of these that needs no cooperation from the web server, and blocks the common nginx + PHP-FPM arrangement where the two run as different users. The staging directory used during a restore is hardened the same way, since an extracted backup is the same secrets as loose files. * ADD: A “Public access to backups” check that writes a short-lived canary file and fetches its own URL to find out whether the directory is genuinely readable. A real backup is never requested. The result appears in Retention & Storage and, if the directory is exposed, as a non-dismissible admin warning with the exact nginx rule to add. It re-runs daily, because a server can be reconfigured under a plugin that never rechecks — which is how a fixed .htaccess went on protecting nothing for years. * ADD: CSBR_BACKUP_DIR constant to pin the backup directory, for hosts where it is a mount point and the randomised path would move backups off it. #### 3.2.654 * FIX: The dashboard widget reported “Last backup: Never” in red, and raised NEEDS ATTENTION, on any site with no LOCAL backup copies — even while its own record showed a backup that morning and all three cloud providers showed a successful sync. The recorded time was read only inside the branch that required a local file to exist. A host with no local copies is the normal state right after a restore, which is exactly when this widget gets looked at, and it is also normal if you keep backups off-site only. It now reports the real time, marks it “(off- site)”, and says “stored locally” so a zero beside a recent time is not a contradiction. * FIX: Every admin page could fatal with ‘Undefined constant “FS_CHMOD_FILE”‘ on a clean install. The crash-recovery dropin writer passed that constant at admin_init, where WordPress does not guarantee it is defined: it is set by wp-admin/includes/ file.php, which only happens to be loaded early on sites where another plugin pulled it in. Found on a freshly restored host, which is exactly where this plugin is used, because the first thing you do after a restore is open wp-admin. * FIX: Licence card strings no longer pass a variable text domain to translation functions (Plugin Check NonSingularStringLiteralDomain critical, ~24 call sites); strings are now plain escaped output #### 3.2.637 * ADD: New optional “Site root extras” backup component: .user.ini, php.ini, robots. txt, ads.txt, app-ads.txt, humans.txt, favicon.ico, .well-known/, and search- engine verification files (Google/Bing/Yandex/Pinterest) from the site root. Restored to the target root when cloning. * ADD: New optional “Server config snapshot” backup component: read-only reference copies of readable nginx/Apache config, full PHP runtime settings, and MySQL server variables saved under server-info/ in the zip. Never restored automatically. * ADD: Post-restore environment comparison, when a backup contains a server config snapshot, restoring it reports differences that commonly break a rebuilt site( PHP version, missing PHP extensions, lower memory/upload limits, MySQL version) in the success message, notification, and log. * ADD: Integrity check now validates the two new components when included. * FIX: Clone extraction now rejects zip entry names containing “..” (path traversal hardening for crafted zips). #### 3.2.539 * FIX: Fatal-error-handler drop-in now written via the WordPress Filesystem API instead of raw copy() (resolves Plugin Check PluginDirectoryWrite) * FIX: Crash Recovery config and notification lock moved from the wp-content root into uploads/cloudscale-backup/ per WordPress.org guidelines; old files removed on upgrade * FIX: Removed wp_prime_option_caches() (WordPress 6.4+) so the plugin stays compatible with its declared minimum of WordPress 6.0 * CHANGE: Drop-in notifications now use the non-blocking wp_remote_post() HTTP API instead of cURL * CHANGE: Dev-only crash-test harness and clone module excluded from the release build; removed duplicate Plugin URI header #### 3.2.360 * FIX: Remove four dead `wp_ajax_csbr_do_sync_job_*` handlers that called undefined function `csbr_do_async_sync()`, legacy loopback architecture replaced by `register_shutdown_function()` in v3.2.257 * FIX: Automatic Crash Recovery Explain modal and How It Works list now correctly document all notification channels (email, Twilio SMS, ntfy push) instead of only Twilio * ADD: DocBlocks added to `csbr_set_job()`, `csbr_get_job()`, `csbr_delete_job()`,` csbr_find_rclone()`, `csbr_find_aws()`, `csbr_list_tables_in_dump()`, `csbr_list_backups()` * CLEANUP: Remove unused `csbr_verify_nonce()` helper (all handlers use `check_ajax_referer()` directly) #### 3.2.257 * FIX: PCP compliance: `cs_admin_page()` now independently checks `current_user_can(' manage_options')` * FIX: PCP compliance: `wp_unslash()` added to `$_POST['cs_action']` and `$_POST[' schedule_enabled']`; `phpcs:ignore` annotations added * FIX: PCP compliance: `data-free-bytes` attribute annotated with `phpcs:ignore EscapeOutput.OutputNotEscaped` * FIX: `uninstall.php`: Dropbox options now cleaned up on plugin delete * FIX: Dropbox history pane infinite reload loop resolved * FIX: AMI Save/Create buttons now show feedback message correctly * UX: Copy buttons on all Explain modal code blocks; Dropbox setup wizard guide; italic placeholders #### 3.2.1 * Renamed internal constants with CS_BACKUP_ prefix to avoid collisions with other plugins * Replaced @unlink(), @copy(), @rmdir() with wp_delete_file(), copy(), rmdir() per WordPress coding standards #### 3.2.0 * NEW: Split backup scheduling into two independent cron events: file backup and AMI snapshot each have their own day picker and time selector * NEW: Configurable backup filename prefix (default: bkup), set in the Retention card * NEW: S3 sync auto-retry: on failure a single cron event fires 5 minutes later; UI shows pending state and a manual Retry button * FIX: Scheduled backup run hour never saved due to missing name attribute on the hour select * FIX: Full+ backup type badge now renders distinctly from Full (separate CSS rule) * AMI explain modal updated to document the two-schedule architecture; reboot defaults clarified (off = crash-consistent, no downtime) #### 2.74.2 * FIX: AMI creation failed with “Character sets beyond ASCII are not supported” due to em dash in description * AMI description now stripped to printable ASCII only via regex * AMI name now sanitised to AWS allowed characters (alphanumeric, hyphens, underscores, dots, slashes, parens) and capped at 128 chars * Replaced sanitize_file_name with stricter AWS specific character filter #### 2.74.1 * FIX: AMI panel could vanish if IMDS endpoint was unreachable or curl failed during page render * All IMDS calls now wrapped in try/catch with error suppression so failures cannot break the admin page * Added curl_init availability check before attempting IMDS calls * IMDS results cached in WordPress transients (1 hour TTL) to avoid repeated metadata calls on every page load * AMI panel init block wrapped in top level try/catch, falls back to empty state on any error #### 2.74.0 * NEW: EC2 AMI Snapshot panel: create full machine images of the hosting instance directly from the plugin * AMI name uses configurable prefix with automatic yyyyMMdd_HHmm timestamp suffix * Optional instance reboot for filesystem consistent snapshots * AMI creation history log with status tracking (last 5 shown, 20 stored) * Check Status button to poll AMI state from AWS * Explain modal with IAM policy requirements and restore instructions * Auto detection of EC2 instance ID and region via IMDS (v1 and v2) * Save/create/status operations via self contained AJAX handlers #### 1.0.0 * Initial public release of CloudScale Backup & Restore * Manual and scheduled backup of database, media uploads, plugins folder, and themes folder * Configurable schedule interval in days with specific run hour * Configurable retention with automatic cleanup of oldest backups * Backup history table with type labels, sizes, dates, and ages * Download any backup from the admin panel * Restore from stored backup or uploaded .zip / .sql file * WordPress maintenance mode enabled during restore and always removed after * Restore confirmation modal with snapshot warning and checkbox gate * Smart detection of mysqldump and mysql CLI for native backup and restore * PHP streamed fallback for environments without CLI tool access * Backup directory protected with .htaccess deny-all * System info panel showing detected methods, memory limits, and backup path ## Meta * Versione **3.2.700** * Ultimo aggiornamento **3 giorni fa** * Installazioni attive **Meno di 10** * Versione WordPress ** 6.0 o superiore ** * Testato fino alla versione **7.0.4** * Versione PHP ** 8.1 o superiore ** * Lingua * [English (US)](https://wordpress.org/plugins/cloudscale-backup-restore/) * Tag * [backup](https://it.wordpress.org/plugins/tags/backup/)[database](https://it.wordpress.org/plugins/tags/database/) [maintenance mode](https://it.wordpress.org/plugins/tags/maintenance-mode/)[restore](https://it.wordpress.org/plugins/tags/restore/) [scheduled backup](https://it.wordpress.org/plugins/tags/scheduled-backup/) * [Visualizzazione avanzata](https://it.wordpress.org/plugins/cloudscale-backup-restore/advanced/) ## Valutazioni Non sono state ancora inviate recensioni. [La tua recensione](https://wordpress.org/support/plugin/cloudscale-backup-restore/reviews/#new-post) [Vedi tutte le recensioni](https://wordpress.org/support/plugin/cloudscale-backup-restore/reviews/) ## Collaboratori * [ andrewjbaker ](https://profiles.wordpress.org/andrewjbaker/) ## Supporto Hai qualcosa da dire? Ti serve aiuto? [Chiedi nel forum di supporto](https://wordpress.org/support/plugin/cloudscale-backup-restore/)