Initial release.<\/p>"},"ratings":[],"assets_icons":{"icon-128x128.png":{"filename":"icon-128x128.png","revision":3555613,"resolution":"128x128","location":"assets","locale":"","width":128,"height":128},"icon-256x256.png":{"filename":"icon-256x256.png","revision":3555613,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["3.2.526","3.2.548","3.2.592","3.2.594","3.2.600","3.2.604","3.2.605","3.2.617","3.2.627","3.2.637","3.2.639","3.2.653","3.2.654","3.2.698","3.2.700"],"block_files":[],"assets_screenshots":{"screenshot-1.jpg":{"filename":"screenshot-1.jpg","revision":3555507,"resolution":"1","location":"assets","locale":"","width":1280,"height":980},"screenshot-2.jpg":{"filename":"screenshot-2.jpg","revision":3555507,"resolution":"2","location":"assets","locale":"","width":1280,"height":790}},"screenshots":{"1":"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.","2":"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."}},"plugin_section":[262246],"plugin_tags":[151,153,1281,152,265189],"plugin_category":[59],"plugin_contributors":[258042],"plugin_business_model":[],"class_list":["post-293223","plugin","type-plugin","status-publish","hentry","plugin_section-dashboard-widgets","plugin_tags-backup","plugin_tags-database","plugin_tags-maintenance-mode","plugin_tags-restore","plugin_tags-scheduled-backup","plugin_category-utilities-and-tools","plugin_contributors-andrewjbaker","plugin_committers-andrewjbaker"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/cloudscale-backup-restore\/assets\/icon-128x128.png?rev=3555613","icon_2x":"https:\/\/ps.w.org\/cloudscale-backup-restore\/assets\/icon-256x256.png?rev=3555613","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/cloudscale-backup-restore\/assets\/screenshot-1.jpg?rev=3555507","caption":"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."},{"src":"https:\/\/ps.w.org\/cloudscale-backup-restore\/assets\/screenshot-2.jpg?rev=3555507","caption":"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."}],"raw_content":"\n
Most backup plugins fail exactly when you need them most: on your biggest site, or the site that's grown since you installed them.<\/strong> 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.<\/p>\n\n CloudScale Backup & Restore has no site-size limit, no destination limit, and no plan wall.<\/strong> 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.<\/p>\n\n Choose any combination, packaged into one Automatic backups are off by default.<\/strong> Run your first backup manually to confirm everything works on your server, then configure a schedule if you need one.<\/p>\n\n Clicking Restore DB opens a confirmation modal that:<\/p>\n\n During restore, WordPress's native 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.<\/p>\n\n When Telegram is configured, the plugin sends backup, restore, and plugin\nrollback notifications, plus error alerts, to the administrator-configured\nTelegram chat via the Telegram Bot API. The message contains the site name,\nevent status, and (for error alerts) a summary of the PHP error, file name,\nand line number. No personal visitor data, post content, or backup data is\ntransmitted. No data is sent unless a Telegram bot token and chat ID have\nbeen entered in the plugin's Notifications settings.\nAPI endpoint contacted: https:\/\/api.telegram.org\/bot{token}\/sendMessage\nTerms of Service: https:\/\/telegram.org\/tos\nPrivacy Policy: https:\/\/telegram.org\/privacy\nTelegram Bot API documentation: https:\/\/core.telegram.org\/bots\/api<\/p>\n\n When S3 settings are configured, the plugin uploads backup zip files directly\nto the administrator's own S3 bucket via the AWS S3 REST API (no external\ntools required). Only the backup zip file is transmitted. Credentials (bucket\nname, access key ID, secret access key, region) are stored in the WordPress\noptions table and are never sent anywhere except to the AWS S3 endpoint.\nAPI endpoint contacted: https:\/\/s3.{region}.amazonaws.com\/\nTerms of Service: https:\/\/aws.amazon.com\/service-terms\/\nPrivacy Policy: https:\/\/aws.amazon.com\/privacy\/<\/p>\n\n When Google Drive settings are configured, the plugin transfers backup zip files\nto the administrator's own Google Drive account using the Google Drive v3 REST\nAPI and OAuth 2.0. No data is sent unless the administrator has completed the\nOAuth authorisation flow (entered a Client ID and Client Secret from Google\nCloud Console and clicked \"Connect to Google Drive\"). Only the backup zip file\nis uploaded. OAuth tokens (access token and refresh token) are stored in the\nWordPress options table.\nAPI endpoint contacted: https:\/\/www.googleapis.com\/ and https:\/\/oauth2.googleapis.com\/\nTerms of Service: https:\/\/policies.google.com\/terms\nPrivacy Policy: https:\/\/policies.google.com\/privacy<\/p>\n\n When Dropbox settings are configured, the plugin transfers backup zip files to\nthe administrator's own Dropbox account using the Dropbox v2 REST API and\nOAuth 2.0. No data is sent unless the administrator has completed the OAuth\nauthorisation flow (entered an App Key and App Secret from the Dropbox App\nConsole and clicked \"Connect to Dropbox\"). Only the backup zip file is\nuploaded. OAuth tokens are stored in the WordPress options table.\nAPI endpoint contacted: https:\/\/api.dropboxapi.com\/ and https:\/\/content.dropboxapi.com\/\nTerms of Service: https:\/\/www.dropbox.com\/terms\nPrivacy Policy: https:\/\/www.dropbox.com\/privacy<\/p>\n\n When OneDrive settings are configured, the plugin transfers backup zip files to\nthe administrator's own Microsoft OneDrive account using the Microsoft Graph\nREST API and OAuth 2.0. No data is sent unless the administrator has completed\nthe OAuth authorisation flow (entered an Azure App Client ID and Client Secret\nand clicked \"Connect to OneDrive\"). Only the backup zip file is uploaded.\nOAuth tokens are stored in the WordPress options table.\nAPI endpoint contacted: https:\/\/graph.microsoft.com\/ and https:\/\/login.microsoftonline.com\/\nTerms of Service: https:\/\/www.microsoft.com\/en-us\/servicesagreement\/\nPrivacy Policy: https:\/\/privacy.microsoft.com\/en-us\/privacystatement<\/p>\n\n When the administrator subscribes to the optional CloudScale Managed Cloud Backup\nservice, the plugin contacts the CloudScale broker to request a short-lived,\nprefix-scoped Amazon S3 access token, then uploads backup zip files directly to\nCloudScale's managed S3 storage (hosted in the EU, eu-west-1). Only the site's\ndomain name, the subscription licence key, and the backup zip file are involved;\nthe backup bytes are uploaded straight to S3 and do not pass through the broker.\nNo data is sent unless the administrator has subscribed and entered a licence key.\nAPI endpoint contacted: https:\/\/api.cloudscale.consulting\/ (broker) and\nhttps:\/\/cloudscale-backup-restore-global.s3.eu-west-1.amazonaws.com\/ (storage)\nTerms of Service: https:\/\/cloudscale.consulting\/terms\nPrivacy Policy: https:\/\/cloudscale.consulting\/privacy<\/p>\n\n Subscription payments for the optional CloudScale Managed Cloud Backup service are\nprocessed by PayPal. Payment details are entered on PayPal's own hosted checkout\npage and are never collected, stored, or transmitted by this plugin. When the\nadministrator starts a subscription, the subscriber's email address and a PayPal\norder amount ($5.00 USD) are sent directly from the WordPress server to the PayPal\nREST API (api-m.paypal.com) to create a checkout session; no payment-card data is\nhandled by the plugin or the WordPress site. No data is sent unless the administrator\nchooses to subscribe to the paid service.\nAPI endpoint contacted: https:\/\/api-m.paypal.com\/ (live) or\nhttps:\/\/api-m.sandbox.paypal.com\/ (sandbox testing)\nBrowser-loaded script: https:\/\/www.paypal.com\/sdk\/js - PayPal's JavaScript SDK, loaded\ninto the plugin's admin screen only after an administrator opens the subscription\ncheckout. PayPal requires the SDK be served from its own origin so a compromised build\ncan be revoked, so it cannot be bundled with the plugin.\nTerms of Service: https:\/\/www.paypal.com\/us\/legalhub\/useragreement-full\nPrivacy Policy: https:\/\/www.paypal.com\/us\/legalhub\/privacy-full<\/p>\n\n When the AMI snapshot feature is used, the plugin reads instance metadata\n(instance ID and region) from the local EC2 Instance Metadata Service at\nhttp:\/\/169.254.169.254. This address is only reachable from within an EC2\ninstance and no data leaves the server at this step. AMI creation, status poll,\nderegister, and snapshot delete requests are then issued directly to the AWS\nEC2 REST API (no external tools required). The same AWS credentials\n(access key ID and secret key) used for S3 are used; if none are configured\nthe plugin attempts to use the EC2 instance role via IMDS.\nAPI endpoint contacted: https:\/\/ec2.{region}.amazonaws.com\/\nTerms of Service: https:\/\/aws.amazon.com\/service-terms\/\nPrivacy Policy: https:\/\/aws.amazon.com\/privacy\/<\/p>\n\n When Automatic Crash Recovery is enabled, the plugin periodically sends an HTTP\nrequest to the administrator-configured health check URL to verify the site is\nresponding. The URL defaults to the site's own home URL. No personal data is\ntransmitted. The request is a plain GET with no authentication payload. The\nsame probe is made when the administrator clicks \"Test Health Check\" in the\nplugin settings. If a system-cron watchdog script is installed on the server,\nthat script also probes this URL independently via curl. The health check URL\nis set by the administrator and is never shared with any third party.\nNo Terms of Service or Privacy Policy apply (the request goes to a URL you own).<\/p>\n\n The Automatic Crash Recovery feature writes a single file outside the plugin\nfolder when it is enabled: The file is written using the WordPress Filesystem API (WP_Filesystem). It is\nonly written when the feature is enabled, only overwritten if it was written by\nthis plugin (identified by an internal marker), and is deleted when the feature\nis disabled or the plugin is uninstalled. No personal data is stored in this file.<\/p>\n\n CloudScale Backup & Restore does not collect, transmit, or store any personal data. All backups are stored locally in the Option 1: WordPress admin (recommended)<\/strong><\/p>\n\n Option 2: Manual via FTP\/SFTP<\/strong><\/p>\n\n In a dedicated No. The plugin sets PHP 8.1 or higher. The plugin uses typed parameters, Yes. The 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 Yes. The restore function extracts 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:<\/p>\n\n 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.<\/p><\/dd>\n Yes. Use WP-CLI to trigger a backup from the command line:<\/p>\n\n Adjust the four boolean arguments ( Each zip may contain:<\/p>\n\n 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 Any Size, No Limits<\/h4>\n\n
\n
$wpdb<\/code>; never loads the full database into memory, regardless of size<\/li>\nset_time_limit(0)<\/code> and ignore_user_abort(true)<\/code> on every backup and restore, so PHP's execution-time limit never cuts a large operation off mid-run<\/li>\nINSERT<\/code> statements, on files of any size<\/li>\nBack Up to Five Destinations at Once<\/h4>\n\n
\n
What It Backs Up<\/h4>\n\n
.zip<\/code> with a descriptive filename (for example backup_db-media-plugins_2026-02-21_09-10-00.zip<\/code>) that reflects exactly what it contains:<\/p>\n\n\n
\/wp-content\/uploads\/<\/code>)<\/li>\n\/wp-content\/plugins\/<\/code>)<\/li>\n\/wp-content\/themes\/<\/code>)<\/li>\nphp.ini<\/code>, robots.txt<\/code>, favicon, .well-known\/<\/code>, and search-engine verification files<\/li>\nbackup-meta.json<\/code>: plugin version, creation timestamp, WordPress version, site URL, table prefix, and which components were included, so you can verify a backup without restoring it<\/li>\n<\/ul>\n\nRestore Safely<\/h4>\n\n
\n
.maintenance<\/code> 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.<\/p>\n\nDisaster Recovery<\/h4>\n\n
\n
Security<\/h4>\n\n
\n
.htaccess<\/code> syntaxes), nginx, IIS (web.config<\/code>), and a silent index.php<\/code>, plus 0700<\/code> permissions, not just an .htaccess<\/code> that nginx and IIS ignore<\/li>\nDeveloper & Automation<\/h4>\n\n
\n
.zip<\/code> or .sql<\/code> file, on the same host or a new one<\/li>\n<\/ul>\n\nExternal services<\/h3>\n\n
Telegram Bot API (optional notifications)<\/h4>\n\n
Amazon S3 (optional cloud backup)<\/h4>\n\n
Google Drive (optional cloud backup)<\/h4>\n\n
Dropbox (optional cloud backup)<\/h4>\n\n
Microsoft OneDrive (optional cloud backup)<\/h4>\n\n
CloudScale Managed Cloud Backup (optional, paid service)<\/h4>\n\n
PayPal (optional, payment for Managed Cloud Backup)<\/h4>\n\n
AWS EC2 \/ AMI snapshots (optional, AMI snapshot feature only)<\/h4>\n\n
Automatic Crash Recovery: health check probe (optional)<\/h4>\n\n
Files written outside the plugin folder<\/h3>\n\n
wp-content\/fatal-error-handler.php<\/code>. This is a\nWordPress-recognised drop-in file (documented in the WordPress Developer\nHandbook under get_dropins()<\/code>). WordPress core checks for this file on every\nrequest; if present, it replaces the default fatal-error screen with a custom\nhandler. The plugin uses this mechanism to show a branded recovery page to\nvisitors while a crash is being fixed, instead of a blank white screen.<\/p>\n\nPrivacy Policy<\/h3>\n\n
cloudscale-backups\/<\/code> 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.<\/p>\n\n\n\n
cloudscale-backup.zip<\/code><\/li>\n\n
cloudscale-backup.zip<\/code><\/li>\ncloudscale-backup<\/code> folder to \/wp-content\/plugins\/<\/code><\/li>\n\n
Where are backups stored?<\/h3><\/dt>\n
cloudscale-backups\/<\/code> folder inside your WordPress uploads directory. This folder is created automatically on activation and protected with an .htaccess<\/code> deny-all rule. Download backups using the Download button in the admin panel, which uses a nonce-secured handler.<\/p><\/dd>\nWill it time out on large sites?<\/h3><\/dt>\n
set_time_limit(0)<\/code> and ignore_user_abort(true)<\/code> 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.<\/p><\/dd>\nWhat PHP version is required?<\/h3><\/dt>\n
match<\/code> expressions, str_contains()<\/code>, and first-class callable syntax introduced in PHP 8.0\/8.1.<\/p><\/dd>\nIs ZipArchive required?<\/h3><\/dt>\n
ZipArchive<\/code> 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<\/code> PHP extension.<\/p><\/dd>\nHow does the scheduling work?<\/h3><\/dt>\n
wp-cron.php<\/code> 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.<\/p><\/dd>\nCan I restore just the database and keep my current media?<\/h3><\/dt>\n
database.sql<\/code> 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.<\/p><\/dd>\nCan I restore on a different server or after a domain change?<\/h3><\/dt>\n
wp search-replace 'olddomain.com' 'newdomain.com' --path=\/path\/to\/wordpress\n<\/code><\/pre><\/dd>\nThe restore failed. Is the site broken?<\/h3><\/dt>\n
Can I trigger a backup from WP-CLI or a system cron job?<\/h3><\/dt>\n
wp eval 'csbr_create_backup(true, true, true, true); csbr_enforce_retention();' --path=\/path\/to\/wordpress\n<\/code><\/pre>\n\n$include_db<\/code>, $include_media<\/code>, $include_plugins<\/code>, $include_themes<\/code>) as needed.<\/p><\/dd>\nWhat is inside the backup zip?<\/h3><\/dt>\n
\n
database.sql<\/code>: complete SQL dump of all WordPress tables<\/li>\nuploads\/<\/code>: full media uploads directory tree<\/li>\nplugins\/<\/code>: full plugins directory tree<\/li>\nthemes\/<\/code>: full themes directory tree<\/li>\nbackup-meta.json<\/code>: metadata including plugin version, creation timestamp, WordPress version, site URL, table prefix, and which components were backed up<\/li>\n<\/ul><\/dd>\nCan I use this to migrate my site to a new host?<\/h3><\/dt>\n
uploads\/<\/code>, plugins\/<\/code>, and themes\/<\/code> folders manually from the zip if needed, or use the backup of those folders.<\/p><\/dd>\n\n<\/dl>\n\n\n3.2.700<\/h4>\n\n
\n
curl_setopt()<\/code> calls (via the http_api_curl<\/code> filter) to stream file uploads without buffering: CURLOPT_UPLOAD<\/code>\/CURLOPT_INFILE<\/code> 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<\/code> annotation. Small files (under the 100MB multipart threshold) are now read into memory and sent as a plain wp_remote_request()<\/code> body, which is bounded and safe at that size; large files already went through bounded 50MB chunks via wp_remote_request()<\/code> 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.<\/li>\n<\/ul>\n\n3.2.699<\/h4>\n\n
\n
3.2.698<\/h4>\n\n
\n
3.2.692<\/h4>\n\n
\n
3.2.688<\/h4>\n\n
\n
3.2.654<\/h4>\n\n
\n
3.2.637<\/h4>\n\n
\n
3.2.539<\/h4>\n\n
\n
3.2.360<\/h4>\n\n
\n
wp_ajax_csbr_do_sync_job_*<\/code> handlers that called undefined function csbr_do_async_sync()<\/code>, legacy loopback architecture replaced by register_shutdown_function()<\/code> in v3.2.257<\/li>\ncsbr_set_job()<\/code>, csbr_get_job()<\/code>, csbr_delete_job()<\/code>, csbr_find_rclone()<\/code>, csbr_find_aws()<\/code>, csbr_list_tables_in_dump()<\/code>, csbr_list_backups()<\/code><\/li>\ncsbr_verify_nonce()<\/code> helper (all handlers use check_ajax_referer()<\/code> directly)<\/li>\n<\/ul>\n\n3.2.257<\/h4>\n\n
\n
cs_admin_page()<\/code> now independently checks current_user_can('manage_options')<\/code><\/li>\nwp_unslash()<\/code> added to $_POST['cs_action']<\/code> and $_POST['schedule_enabled']<\/code>; phpcs:ignore<\/code> annotations added<\/li>\ndata-free-bytes<\/code> attribute annotated with phpcs:ignore EscapeOutput.OutputNotEscaped<\/code><\/li>\nuninstall.php<\/code>: Dropbox options now cleaned up on plugin delete<\/li>\n3.2.1<\/h4>\n\n
\n
3.2.0<\/h4>\n\n
\n
2.74.2<\/h4>\n\n
\n
2.74.1<\/h4>\n\n
\n
2.74.0<\/h4>\n\n
\n
1.0.0<\/h4>\n\n
\n