{"id":286309,"date":"2026-07-08T12:07:10","date_gmt":"2026-07-08T12:07:10","guid":{"rendered":"https:\/\/wordpress.org\/plugins\/backupridge-backup-restore\/"},"modified":"2026-08-10T16:17:39","modified_gmt":"2026-08-10T16:17:39","slug":"backupridge","status":"publish","type":"plugin","link":"https:\/\/tw.wordpress.org\/plugins\/backupridge\/","author":23460127,"comment_status":"closed","ping_status":"closed","template":"","meta":{"version":"1.34.1","stable_tag":"1.34.1","tested":"7.0.3","requires":"6.7","requires_php":"8.0","requires_plugins":null,"header_name":"BackupRidge","header_author":"Stava Tech","header_description":"Reliable WordPress backup plugin with resumable backups and remote storage","assets_banners_color":"285373","last_updated":"2026-08-10 16:17:39","external_support_url":"","external_repository_url":"","donate_link":"","header_plugin_uri":"https:\/\/backupridge.com","header_author_uri":"https:\/\/stavatech.no","rating":0,"author_block_rating":0,"active_installs":0,"downloads":409,"num_ratings":0,"support_threads":0,"support_threads_resolved":0,"author_block_count":0,"sections":["description","installation","faq","changelog"],"tags":{"1.29.0":{"tag":"1.29.0","author":"stavatech","date":"2026-07-08 12:06:52"},"1.29.1":{"tag":"1.29.1","author":"stavatech","date":"2026-07-15 10:52:50"},"1.29.2":{"tag":"1.29.2","author":"stavatech","date":"2026-07-29 09:17:49"},"1.29.3":{"tag":"1.29.3","author":"stavatech","date":"2026-07-30 15:44:32"},"1.30.0":{"tag":"1.30.0","author":"stavatech","date":"2026-07-31 15:32:53"},"1.30.1":{"tag":"1.30.1","author":"stavatech","date":"2026-07-31 17:39:38"},"1.31.0":{"tag":"1.31.0","author":"stavatech","date":"2026-08-01 20:00:37"},"1.32.0":{"tag":"1.32.0","author":"stavatech","date":"2026-08-02 19:09:52"},"1.33.0":{"tag":"1.33.0","author":"stavatech","date":"2026-08-06 12:35:23"},"1.34.0":{"tag":"1.34.0","author":"stavatech","date":"2026-08-10 10:34:08"},"1.34.1":{"tag":"1.34.1","author":"stavatech","date":"2026-08-10 16:17:39"}},"upgrade_notice":[],"ratings":[],"assets_icons":{"icon.svg":{"filename":"icon.svg","revision":3600265,"resolution":false,"location":"assets","locale":false}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3600265,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3600265,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.29.0","1.29.1","1.29.2","1.29.3","1.30.0","1.30.1","1.31.0","1.32.0","1.33.0","1.34.0","1.34.1"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3600265,"resolution":"1","location":"assets","locale":"","width":1400,"height":900},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3600265,"resolution":"2","location":"assets","locale":"","width":1400,"height":900},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3600265,"resolution":"3","location":"assets","locale":"","width":1400,"height":900},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3600265,"resolution":"4","location":"assets","locale":"","width":1400,"height":900},"screenshot-5.png":{"filename":"screenshot-5.png","revision":3600265,"resolution":"5","location":"assets","locale":"","width":1400,"height":900},"screenshot-6.png":{"filename":"screenshot-6.png","revision":3600265,"resolution":"6","location":"assets","locale":"","width":1400,"height":900}},"screenshots":{"1":"Dashboard \u2014 backup status, history, and one-click start, stop, continue, and retry.","2":"Backup in progress \u2014 live phase timeline, per-destination upload progress, and an honest ETA.","3":"Settings \u2014 backup scope, schedules, and the performance and reliability tuning that adapts to your host.","4":"Remote Storage \u2014 add S3, R2, FTP, SFTP and more destinations, each with a connection test.","5":"Restore \u2014 choose exactly which components to restore before anything is touched.","6":"Log Viewer \u2014 the full per-job log, readable and downloadable, plus the one-click Support Bundle."}},"plugin_section":[],"plugin_tags":[151,10698,10718,4155,152],"plugin_category":[59],"plugin_contributors":[270580],"plugin_business_model":[],"class_list":["post-286309","plugin","type-plugin","status-publish","hentry","plugin_tags-backup","plugin_tags-cloud-backup","plugin_tags-database-backup","plugin_tags-migration","plugin_tags-restore","plugin_category-utilities-and-tools","plugin_contributors-stavatech","plugin_committers-stavatech"],"banners":{"banner":"https:\/\/ps.w.org\/backupridge\/assets\/banner-772x250.png?rev=3600265","banner_2x":"https:\/\/ps.w.org\/backupridge\/assets\/banner-1544x500.png?rev=3600265","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":"https:\/\/ps.w.org\/backupridge\/assets\/icon.svg?rev=3600265","icon":"https:\/\/ps.w.org\/backupridge\/assets\/icon.svg?rev=3600265","icon_2x":false,"generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/backupridge\/assets\/screenshot-1.png?rev=3600265","caption":"Dashboard \u2014 backup status, history, and one-click start, stop, continue, and retry."},{"src":"https:\/\/ps.w.org\/backupridge\/assets\/screenshot-2.png?rev=3600265","caption":"Backup in progress \u2014 live phase timeline, per-destination upload progress, and an honest ETA."},{"src":"https:\/\/ps.w.org\/backupridge\/assets\/screenshot-3.png?rev=3600265","caption":"Settings \u2014 backup scope, schedules, and the performance and reliability tuning that adapts to your host."},{"src":"https:\/\/ps.w.org\/backupridge\/assets\/screenshot-4.png?rev=3600265","caption":"Remote Storage \u2014 add S3, R2, FTP, SFTP and more destinations, each with a connection test."},{"src":"https:\/\/ps.w.org\/backupridge\/assets\/screenshot-5.png?rev=3600265","caption":"Restore \u2014 choose exactly which components to restore before anything is touched."},{"src":"https:\/\/ps.w.org\/backupridge\/assets\/screenshot-6.png?rev=3600265","caption":"Log Viewer \u2014 the full per-job log, readable and downloadable, plus the one-click Support Bundle."}],"raw_content":"<!--section=description-->\n<p><strong>BackupRidge is the WordPress backup plugin engineered to finish \u2014 even on cheap shared hosting.<\/strong> Most backup plugins assume a fast server, then quietly die when a 30-second PHP limit or a missed WP-Cron event cuts them off. BackupRidge saves a checkpoint at every step and resumes across requests, a watchdog revives stalled jobs, and pacing adapts to your host's measured speed \u2014 so a full-site backup completes on hosting where other plugins give up.<\/p>\n\n<p>Back up your database and files on a schedule, send the archives off-site, restore the whole site or only the pieces you need, and migrate a site to a new domain or host \u2014 from a dashboard that reports what actually happened, per destination, with real logs.<\/p>\n\n<h4>Back up to storage you control<\/h4>\n\n<p>Every backup can upload to one or more destinations:<\/p>\n\n<ul>\n<li><strong>Amazon S3 backup<\/strong> \u2014 including any S3-compatible service<\/li>\n<li><strong>Cloudflare R2 backup<\/strong><\/li>\n<li><strong>FTP backup<\/strong> and <strong>SFTP backup<\/strong> to your own server<\/li>\n<li><strong>Local backup<\/strong> on the web server, protected from direct web access<\/li>\n<li><strong>Google Drive backup<\/strong>, <strong>Dropbox backup<\/strong>, <strong>OneDrive backup<\/strong>, and <strong>Backblaze B2 backup<\/strong> with <a href=\"https:\/\/backupridge.com\/pricing\">BackupRidge Pro<\/a><\/li>\n<\/ul>\n\n<p>Your archives live in accounts <em>you<\/em> own. There is no vendor cloud in the middle, and nothing about restore depends on our servers.<\/p>\n\n<h4>Built for hosts that kill long requests<\/h4>\n\n<ul>\n<li><strong>Resumable everything<\/strong> \u2014 database export, file archiving, and uploads all checkpoint and continue across requests, so strict execution limits pause a backup instead of killing it.<\/li>\n<li><strong>Backup watchdog<\/strong> \u2014 a cron-based watchdog detects stalled jobs (missed cron, loopback failures, hard process kills) and resumes them automatically.<\/li>\n<li><strong>Host-aware tuning<\/strong> \u2014 the plugin measures your server's real disk and upload throughput and sizes its work slices, archive parts, and pacing to match.<\/li>\n<li><strong>Backup intensity control<\/strong> \u2014 pace backup I\/O so a running backup doesn't slow down your live visitors.<\/li>\n<li><strong>Split archives<\/strong> \u2014 large sites are split into right-sized numbered parts that upload reliably and download individually.<\/li>\n<\/ul>\n\n<h4>Honest by design<\/h4>\n\n<ul>\n<li><strong>Restore is not a paywall.<\/strong> Restore, including component selection and migration receive, ships in this plugin at no cost \u2014 and archives are self-describing, so they restore on a brand-new install too.<\/li>\n<li><strong>Per-destination truth.<\/strong> If a backup reaches two destinations and fails a third, the job says exactly that \u2014 no false green checkmarks.<\/li>\n<li><strong>Real logs.<\/strong> Every job writes a readable log you can view and download, plus a one-click diagnostics bundle for support.<\/li>\n<\/ul>\n\n<h4>Free Features<\/h4>\n\n<ul>\n<li><strong>Resumable backups<\/strong> \u2014 Long-running backups save progress and resume from the last checkpoint so they finish on any host, including shared hosting with 30-second limits.<\/li>\n<li><strong>Database backup<\/strong> \u2014 MySQL\/MariaDB export via mysqldump (when available) or native PHP streaming with optional table filtering and row-level resumption.<\/li>\n<li><strong>File backup<\/strong> \u2014 Back up wp-content (and optionally the full WordPress root) with exclusion patterns, compression, and optional archive splitting for large sites.<\/li>\n<li><strong>Local storage<\/strong> \u2014 Store completed backups on the server filesystem. Optional subfolder under uploads (base: <code>wp-content\/uploads\/backupridge<\/code>).<\/li>\n<li><strong>Remote storage<\/strong> \u2014 Add multiple destinations and upload completed backups to Amazon S3, Cloudflare R2, FTP, or SFTP.<\/li>\n<li><strong>Scheduled backups<\/strong> \u2014 Run backups automatically on a daily, weekly, or custom schedule via WP-Cron, with a REST endpoint available for triggering from an external system cron.<\/li>\n<li><strong>Restore<\/strong> \u2014 Restore from a local backup, remote storage, or an uploaded archive, with component-level selection (database, themes, plugins, uploads, core) so you only restore what you need.<\/li>\n<li><strong>Site migration (receive)<\/strong> \u2014 Bring another WordPress site into this one: upload its backup archive via Import Backup on the Dashboard (split\/multi-part archives supported) and restore it \u2014 old domain URLs are replaced with this site's URL automatically. The Migrate admin page handles live site-to-site transfer (receiving a push sent from BackupRidge Pro, plus history).<\/li>\n<li><strong>WP-CLI discover\/import<\/strong> \u2014 <code>wp backupridge discover<\/code> scans for archives already placed under <code>wp-content\/uploads\/backupridge\/backups\/<\/code> (e.g. copied over via <code>scp<\/code>) and registers them in Backup History; <code>wp backupridge import &lt;path&gt;<\/code> does the same for a single archive file anywhere on disk. Both are the scriptable equivalent of the Dashboard's \"Discover local backups\" \/ \"Import Backup\" buttons \u2014 useful for disaster-recovery runbooks that rebuild a site entirely from the command line.<\/li>\n<li><strong>Dashboard<\/strong> \u2014 View backup status, history, progress, and logs. Start, stop, continue, or retry backups from the admin UI.<\/li>\n<li><strong>Backup watchdog<\/strong> \u2014 A cron-based watchdog recovers backups that stall due to missed cron events or loopback failures.<\/li>\n<li><strong>Custom backup filenames<\/strong> \u2014 Choose a filename prefix (BackupRidge, site URL, or site name) with automatic date\/time stamping.<\/li>\n<li><strong>Multi-part downloads<\/strong> \u2014 Download each archive part from the dashboard, or use Download All to queue sequential direct downloads (reliable on shared hosting).<\/li>\n<li><strong>Log viewer<\/strong> \u2014 Browse and download per-job log files directly from the admin UI.<\/li>\n<li><strong>Webhook notifications<\/strong> \u2014 Optional HTTP POST after a successful and\/or failed backup (you choose): generic JSON, Slack incoming webhook, or Discord webhook format; URL, format, and which outcomes to notify are in Settings.<\/li>\n<li><strong>Update-screen warning<\/strong> \u2014 See a notice on WordPress update screens when no backup has been created in the last 24 hours.<\/li>\n<\/ul>\n\n<h4>Pro Features<\/h4>\n\n<ul>\n<li><strong>More cloud providers + OAuth<\/strong> \u2014 Connect Google Drive, Dropbox, OneDrive, and Backblaze B2 with easy OAuth sign-in\u2014no manual API keys required.<\/li>\n<li><strong>Incremental backups<\/strong> \u2014 Only back up files that changed since the last run, reducing time and storage.<\/li>\n<li><strong>Archive encryption<\/strong> \u2014 AES-256-GCM authenticated encryption for backup archives before upload (legacy AES-256-CBC archives are still decryptable for restore). The encryption key can be downloaded from Settings \u2192 Encryption and imported on another site \u2014 save a copy before you need it, since the key lives only on this site and encrypted backups cannot be recovered without it.<\/li>\n<li><strong>Advanced scheduling<\/strong> \u2014 Multiple independent schedules with time-of-day, day-of-week, 5-field cron expression support, and per-schedule settings overrides.<\/li>\n<li><strong>Backup verification<\/strong> \u2014 SHA-256 integrity checks on every archive part after backup completes.<\/li>\n<li><strong>System cron integration<\/strong> \u2014 Managed system cron setup and WP-CLI commands for triggering and automating backups, instead of relying on WP-Cron.<\/li>\n<li><strong>Custom filename templates<\/strong> \u2014 Build filenames from placeholders (<code>{type}<\/code>, <code>{seq}<\/code>, and more) instead of a fixed prefix.<\/li>\n<\/ul>\n\n<h4>Requirements<\/h4>\n\n<p>PHP 8.0 or higher, WordPress 6.7 or higher. The backup directory (default <code>wp-content\/uploads\/backupridge<\/code>) must be writable by the web server.<\/p>\n\n<h3>Support<\/h3>\n\n<p><strong>Without a license:<\/strong> please open a thread in BackupRidge's support forum \u2014 the Support tab on this plugin's directory page. We read every thread.<\/p>\n\n<p><strong>Pro license holders<\/strong> get a priority support channel: use the <strong>Support<\/strong> link in the plugin footer (Dashboard, Settings, Log Viewer, etc.) or go directly to <a href=\"https:\/\/backupridge.com\/contact\">backupridge.com\/contact<\/a>. When your license is active, the in-plugin link automatically carries your license key and plan so your ticket is prioritised at intake.<\/p>\n\n<p>Whichever channel you use, attaching diagnostics up front avoids back-and-forth over \"what PHP version \/ what host \/ is cron working?\":<\/p>\n\n<ul>\n<li><strong>Log Viewer<\/strong> (BackupRidge \u2192 Logs) \u2014 copy or download the log for a specific backup job as plain text.<\/li>\n<li><strong>Support Bundle<\/strong> (also in the Log Viewer) \u2014 a one-click report combining your host environment, host capabilities, WP-Cron status, and a redacted summary of your settings. Copy it to your clipboard or download it as a <code>.txt<\/code> file and attach it to your ticket.<\/li>\n<\/ul>\n\n<h3>External services<\/h3>\n\n<p>BackupRidge can upload backup archives to third-party cloud storage services configured by the user. No data is sent to any external service unless the user explicitly configures a storage provider.\nLinks to backupridge.com and stavatech.no are informational website links and do not receive backup data from the plugin.<\/p>\n\n<h4>Amazon S3<\/h4>\n\n<p>Used to store backup archives via the S3 API. Signed requests with user-provided credentials and backup files are transmitted when the user configures S3 storage.\n* <a href=\"https:\/\/aws.amazon.com\/agreement\/\">AWS Customer Agreement<\/a>\n* <a href=\"https:\/\/aws.amazon.com\/privacy\/\">AWS Privacy Notice<\/a><\/p>\n\n<h4>Cloudflare R2<\/h4>\n\n<p>Used to store backup archives via S3-compatible API calls. Signed requests with user-provided credentials and backup files are transmitted when the user configures R2 storage.\n* <a href=\"https:\/\/www.cloudflare.com\/terms\/\">Cloudflare Terms<\/a>\n* <a href=\"https:\/\/www.cloudflare.com\/privacypolicy\/\">Cloudflare Privacy Policy<\/a><\/p>\n\n<h4>FTP<\/h4>\n\n<p>Used to upload backup archives to a host, port, and credentials supplied by the site administrator. Data is transmitted only when the user configures FTP storage.\nThis connection targets a user-selected server endpoint (self-hosted or third-party chosen by the site owner), so no single provider Terms or Privacy policy applies.<\/p>\n\n<h4>SFTP<\/h4>\n\n<p>Used to upload backup archives over SSH file transfer to a host, port, and credentials (or key) supplied by the site administrator. Data is transmitted only when the user configures SFTP storage.\nThis connection targets a user-selected server endpoint (self-hosted or third-party chosen by the site owner), so no single provider Terms or Privacy policy applies.<\/p>\n\n<h4>Google Drive (BackupRidge Pro only)<\/h4>\n\n<p>Not included in the WordPress.org download. When installed separately, BackupRidge Pro can upload backups via the Google Drive API using OAuth and user-granted access. Backup file data and metadata needed for the upload are sent to Google when the user configures this provider and runs a backup. Setup requires enabling the Google Drive API on your Google Cloud project (not only OAuth credentials). See https:\/\/backupridge.com\/docs\/cloud-storage#google-drive<\/p>\n\n<ul>\n<li><a href=\"https:\/\/policies.google.com\/terms\">Google Terms of Service<\/a><\/li>\n<li><a href=\"https:\/\/policies.google.com\/privacy\">Google Privacy Policy<\/a><\/li>\n<\/ul>\n\n<h4>Dropbox (BackupRidge Pro only)<\/h4>\n\n<p>Not included in the WordPress.org download. When installed separately, BackupRidge Pro can upload backups via the Dropbox API using OAuth. Backup file data is sent to Dropbox when the user configures this provider and runs a backup. Setup requires enabling file permissions on your Dropbox app and clicking Submit in the Permissions tab before OAuth. See https:\/\/backupridge.com\/docs\/cloud-storage#dropbox<\/p>\n\n<ul>\n<li><a href=\"https:\/\/www.dropbox.com\/terms\">Dropbox Terms<\/a><\/li>\n<li><a href=\"https:\/\/www.dropbox.com\/privacy\">Dropbox Privacy Policy<\/a><\/li>\n<\/ul>\n\n<h4>Microsoft OneDrive (BackupRidge Pro only)<\/h4>\n\n<p>Not included in the WordPress.org download. When installed separately, BackupRidge Pro can upload backups via Microsoft Graph \/ OneDrive using OAuth. Backup file data is sent to Microsoft when the user configures this provider and runs a backup. Setup requires an Azure app registration with a redirect URI of wp-admin\/admin.php (no query string) and account types matching your Microsoft sign-in. See https:\/\/backupridge.com\/docs\/cloud-storage#onedrive<\/p>\n\n<ul>\n<li><a href=\"https:\/\/www.microsoft.com\/servicesagreement\">Microsoft Services Agreement<\/a><\/li>\n<li><a href=\"https:\/\/privacy.microsoft.com\/privacystatement\">Microsoft Privacy Statement<\/a><\/li>\n<\/ul>\n\n<h4>Backblaze B2 (BackupRidge Pro only)<\/h4>\n\n<p>Not included in the WordPress.org download. When installed separately, BackupRidge Pro can upload backups to Backblaze B2 via the Backblaze B2 Native API. It calls <code>https:\/\/api.backblazeb2.com<\/code> to authorize the session with the user-provided Key ID and Application Key, then uploads the backup archive parts. Backup file data is sent to Backblaze only when the user configures this provider and runs a backup.<\/p>\n\n<ul>\n<li><a href=\"https:\/\/www.backblaze.com\/company\/policy\/terms-of-service\">Backblaze Terms of Service<\/a><\/li>\n<li><a href=\"https:\/\/www.backblaze.com\/company\/policy\/privacy\">Backblaze Privacy Policy<\/a><\/li>\n<\/ul>\n\n<h4>HTTP webhooks (backup status)<\/h4>\n\n<p>When webhooks are enabled in Settings, the plugin can send an HTTP POST to the URL you provide after a backup succeeds and\/or after it fails, depending on the checkboxes you set. Choices: generic JSON (job id, status, size, duration, timestamp), Slack incoming webhook (JSON with a text field), or Discord webhook (JSON with a content field). Data is sent only to your URL; the receiving service\u2019s terms apply if you use Slack or Discord.<\/p>\n\n<h4>REST \/ cron trigger (this plugin)<\/h4>\n\n<p>Optional: a REST URL with a secret key can be called by system cron so the site can run backup segments without WP-Cron or loopback. Requests go only to the same WordPress site; no third party receives data unless the site owner configures something else.<\/p>\n\n<p>Preferred authentication: send the key in the <code>X-BackupRidge-Cron-Key<\/code> request header. Legacy <code>?key=<\/code> query authentication remains supported for compatibility, but query strings can be logged by proxies and web servers.<\/p>\n\n<h3>Source Code<\/h3>\n\n<p>This plugin ships its full, human-readable source. Every minified script in <code>assets\/js\/dist\/<\/code> has its un-minified source in <code>assets\/js\/src\/<\/code>, and the minified stylesheet <code>assets\/css\/admin.min.css<\/code> has its source in <code>assets\/css\/admin.css<\/code>, inside the same plugin package, so each compiled file can be reviewed and rebuilt. No source is removed during packaging.<\/p>\n\n<p>Build tools and steps to regenerate the compiled assets:<\/p>\n\n<ul>\n<li>Requirements: Node.js 18+ and npm.<\/li>\n<li>Install dependencies: <code>npm install<\/code><\/li>\n<li>Build JS and CSS (terser minifies each <code>assets\/js\/src\/*.js<\/code> into <code>assets\/js\/dist\/<\/code>, and PostCSS\/cssnano minifies <code>assets\/css\/admin.css<\/code> into <code>assets\/css\/admin.min.css<\/code>): <code>npm run build<\/code><\/li>\n<\/ul>\n\n<p>PHP dependencies are managed with Composer (<code>composer install<\/code>). No third-party JavaScript libraries are bundled in a minified-only form; all shipped scripts are first-party and their sources are included as described above.<\/p>\n\n<!--section=installation-->\n<ol>\n<li>Upload the plugin zip via Plugins \u2192 Add New \u2192 Upload, or install it from the WordPress plugin directory.<\/li>\n<li>Activate the plugin through the Plugins screen.<\/li>\n<li>Go to BackupRidge in the admin menu to configure settings, storage, and schedules.<\/li>\n<li>Use the Dashboard to start a manual backup or view history and logs.<\/li>\n<\/ol>\n\n<p>For first-time setup, ensure the backup directory (Settings \u2192 Backup directory) is writable. The plugin creates <code>wp-content\/uploads\/backupridge<\/code> by default for backups, logs, and temporary files.<\/p>\n\n<!--section=faq-->\n<dl>\n<dt id=\"my%20host%20has%20a%2030-second%20php%20limit.%20will%20backups%20actually%20complete%3F\"><h3>My host has a 30-second PHP limit. Will backups actually complete?<\/h3><\/dt>\n<dd><p>Yes \u2014 this is the problem BackupRidge was built around. A backup runs as a series of short slices: each slice saves a checkpoint before the host's time limit hits, then a WP-Cron event (or a loopback self-call, or even the dashboard status poll) continues from that checkpoint. A watchdog catches jobs that stall because cron never fired. Large sites on slow shared hosting take longer, but they finish.<\/p><\/dd>\n<dt id=\"does%20restoring%20cost%20anything%2C%20or%20is%20it%20locked%20behind%20a%20license%3F\"><h3>Does restoring cost anything, or is it locked behind a license?<\/h3><\/dt>\n<dd><p>Restore ships in this plugin at no cost, with no nags in the middle of it: full-site restore, component selection (database, themes, plugins, uploads, core), restore from remote storage, and restore of uploaded archives are all included. Each archive embeds a self-describing manifest, so it can be restored on a fresh WordPress install \u2014 you are never locked out of your own backups.<\/p><\/dd>\n<dt id=\"where%20are%20backups%20stored%3F\"><h3>Where are backups stored?<\/h3><\/dt>\n<dd><p>By default, backups are stored in <code>wp-content\/uploads\/backupridge\/backups<\/code>. In Settings, you can optionally set a subfolder under <code>wp-content\/uploads\/backupridge\/<\/code> (for example <code>staging\/site-a<\/code>), but absolute custom paths are not allowed. You can also configure remote storage \u2014 Amazon S3, Cloudflare R2, FTP, SFTP, and more with BackupRidge Pro \u2014 to upload completed backups off-site. Archives always land in storage accounts you own.<\/p><\/dd>\n<dt id=\"can%20i%20back%20up%20to%20google%20drive%2C%20dropbox%2C%20or%20onedrive%3F\"><h3>Can I back up to Google Drive, Dropbox, or OneDrive?<\/h3><\/dt>\n<dd><p>Yes, with <a href=\"https:\/\/backupridge.com\/pricing\">BackupRidge Pro<\/a>, which adds Google Drive backup, Dropbox backup, OneDrive backup, and Backblaze B2 backup with OAuth sign-in. The base plugin includes Amazon S3, Cloudflare R2 (and any S3-compatible service), FTP, SFTP, and local storage.<\/p><\/dd>\n<dt id=\"can%20i%20resume%20a%20backup%20if%20it%20stops%3F\"><h3>Can I resume a backup if it stops?<\/h3><\/dt>\n<dd><p>Yes. BackupRidge saves progress at regular checkpoints and can resume from the last one. If a backup stalls, click \"Continue\" on the Dashboard to pick up where it left off. A built-in watchdog also detects stalled backups and re-schedules them automatically.<\/p><\/dd>\n<dt id=\"will%20a%20backup%20slow%20down%20my%20site%20while%20it%20runs%3F\"><h3>Will a backup slow down my site while it runs?<\/h3><\/dt>\n<dd><p>You can decide. The backup intensity setting (Unrestricted \/ Light \/ Moderate \/ Aggressive) paces file and upload batches so a running backup yields disk and CPU to live visitors. Auto-detect measures your host's disk throughput and recommends a preset; slower hosts get gentler pacing automatically.<\/p><\/dd>\n<dt id=\"what%20happens%20if%20wp-cron%20is%20unreliable%20on%20my%20host%3F\"><h3>What happens if WP-Cron is unreliable on my host?<\/h3><\/dt>\n<dd><p>BackupRidge has several fallback mechanisms: a loopback self-call, a cron trigger REST endpoint for system cron, and the ability to run a backup segment during the dashboard status poll. Even on hosts where WP-Cron is disabled or unreliable, backups can make progress whenever someone visits the admin.<\/p><\/dd>\n<dt id=\"how%20large%20a%20site%20can%20backupridge%20handle%3F\"><h3>How large a site can BackupRidge handle?<\/h3><\/dt>\n<dd><p>There is no built-in size limit. Large sites are split into numbered archive parts sized to what your host and storage destination can reliably handle, and every phase \u2014 database export, archiving, upload \u2014 is resumable, so total runtime is not bounded by any single request. Multi-gigabyte sites complete on slow shared hosts; the work is spread across as many slices as the host needs.<\/p><\/dd>\n<dt id=\"can%20i%20restore%20specific%20parts%20of%20a%20backup%3F\"><h3>Can I restore specific parts of a backup?<\/h3><\/dt>\n<dd><p>Yes. The restore dialog lets you choose which components to restore: database, themes, plugins, uploads, and\/or core files. You can optionally save a safety copy of the current database on the server before starting (recommended for large sites only if you accept the extra time).<\/p><\/dd>\n<dt id=\"can%20i%20migrate%20a%20site%20to%20this%20one%3F\"><h3>Can I migrate a site to this one?<\/h3><\/dt>\n<dd><p>Yes, at no cost. Upload the backup archive exported from the other site via Import Backup on the Dashboard, then restore it \u2014 split (multi-part) archives are supported, and old domain URLs are replaced with this site's URL automatically during restore. The Migrate admin page is for live site-to-site transfer: it can receive a push from another BackupRidge install, and BackupRidge Pro adds pushing a migration directly to another site (including staging clones).<\/p><\/dd>\n<dt id=\"how%20do%20i%20restore%20to%20a%20new%20server%20after%20the%20old%20one%20is%20gone%3F\"><h3>How do I restore to a new server after the old one is gone?<\/h3><\/dt>\n<dd><p>Install WordPress and BackupRidge on the new host, then get the backup archive onto it: upload it via Import Backup on the Dashboard, drop the files into <code>wp-content\/uploads\/backupridge\/backups\/<\/code> over FTP\/SFTP and use Discover local backups, or \u2014 if the old site uploaded to remote storage \u2014 configure that same destination under Storage and use Find backups in this storage to locate and download it. Restore it from Backup History like any other backup; domain URLs are replaced automatically if you're moving to a new domain. A full step-by-step walkthrough ships with the plugin in <code>docs\/RESTORE_TO_NEW_SITE.md<\/code>.<\/p><\/dd>\n<dt id=\"i%27m%20switching%20from%20backwpup%20%E2%80%94%20what%20do%20i%20need%20to%20know%3F\"><h3>I'm switching from BackWPup \u2014 what do I need to know?<\/h3><\/dt>\n<dd><p>Scheduled backups, restore, and uploading each backup to several destinations at once are all included in the free version. S3, R2, FTP, SFTP, and local storage need no upgrade; Google Drive, Dropbox, and OneDrive require Pro \u2014 the same split BackWPup applies in its paid plans. Keep the backup archives made by your old plugin until BackupRidge has completed a few scheduled runs and you have verified a restore. Releases are incremental and changelog-driven: every version ships with a full changelog entry (see below), and settings are migrated automatically on update.<\/p><\/dd>\n<dt id=\"i%27m%20switching%20from%20all-in-one%20wp%20migration%20%E2%80%94%20is%20there%20a%20size%20limit%3F\"><h3>I'm switching from All-in-One WP Migration \u2014 is there a size limit?<\/h3><\/dt>\n<dd><p>No. BackupRidge has no size caps on backups, imports, or restores in any version. Large sites are handled by splitting archives into numbered parts and resuming from checkpoints, not by limiting how much data you can move. Backups are standard ZIP archives that any unzip tool can open \u2014 there is no proprietary format. Existing <code>.wpress<\/code> archives can't be imported, though: start with a fresh BackupRidge backup of your site instead.<\/p><\/dd>\n<dt id=\"how%20does%20archive%20splitting%20work%3F\"><h3>How does archive splitting work?<\/h3><\/dt>\n<dd><p>When a backup exceeds the configured maximum archive size, BackupRidge splits it into multiple numbered parts (e.g. <code>backup_001.zip<\/code>, <code>backup_002.zip<\/code>). All parts are uploaded to remote storage and can be downloaded individually or all at once via Download All (sequential direct downloads).<\/p><\/dd>\n<dt id=\"import%20backup%20is%20slow%20or%20fails%20with%20larger%20upload%20chunks.%20what%20should%20i%20change%3F\"><h3>Import Backup is slow or fails with larger upload chunks. What should I change?<\/h3><\/dt>\n<dd><p>Import Backup uploads use chunked <code>admin-ajax<\/code> requests. Larger chunks reduce request overhead and are often faster, but each chunk must fit PHP limits.<\/p>\n\n<p>BackupRidge automatically detects and applies a safe max chunk size from:<\/p>\n\n<ul>\n<li><code>upload_max_filesize<\/code><\/li>\n<li><code>post_max_size<\/code> (minus multipart form overhead)<\/li>\n<\/ul>\n\n<p>If uploads fail above a certain chunk size (for example above 8 MB), increase PHP limits so they are above your target:<\/p>\n\n<ul>\n<li><code>upload_max_filesize = 16M<\/code><\/li>\n<li><code>post_max_size = 24M<\/code><\/li>\n<\/ul>\n\n<p>Then set <strong>Settings \u2192 Upload \u2192 Upload chunk size<\/strong> to a value below those limits (8 MB in this example). Keep <code>post_max_size<\/code> higher than <code>upload_max_filesize<\/code>.<\/p><\/dd>\n<dt id=\"what%20is%20the%20difference%20between%20this%20plugin%20and%20backupridge%20pro%3F\"><h3>What is the difference between this plugin and BackupRidge Pro?<\/h3><\/dt>\n<dd><p>This plugin is complete backup software, not a demo: resumable full-site backups, scheduling, S3\/R2\/FTP\/SFTP\/local storage, full restore, and migration receive are all included, with no artificial limits. <a href=\"https:\/\/backupridge.com\/pricing\">BackupRidge Pro<\/a> adds the OAuth cloud providers (Google Drive, Dropbox, OneDrive, Backblaze B2), incremental backups, archive encryption, backup verification, advanced scheduling, system cron + WP-CLI integration, custom filename templates, and push migration\/staging.<\/p><\/dd>\n<dt id=\"what%20happens%20to%20my%20backups%20if%20backupridge%20disappears%3F\"><h3>What happens to my backups if BackupRidge disappears?<\/h3><\/dt>\n<dd><p>You keep everything. Backup archives are standard ZIP files containing your files and a plain SQL export, stored in your own hosting account and your own storage accounts \u2014 there is no BackupRidge cloud. Restore runs entirely on your server and never calls our infrastructure. The plugin is GPL-licensed, so the software itself remains yours to run.<\/p><\/dd>\n<dt id=\"what%20wordpress%20and%20php%20versions%20are%20supported%3F\"><h3>What WordPress and PHP versions are supported?<\/h3><\/dt>\n<dd><p>WordPress 6.7 or higher and PHP 8.0 or higher. The plugin is tested on WordPress 6.8, 6.9, and 7.0 with PHP 8.0 through 8.3.<\/p><\/dd>\n<dt id=\"is%20the%20backup%20directory%20protected%20from%20web%20access%3F\"><h3>Is the backup directory protected from web access?<\/h3><\/dt>\n<dd><p>Yes. BackupRidge creates an <code>.htaccess<\/code> file and an <code>index.php<\/code> file in the backup directory to prevent direct web access on Apache and most hosting environments. For Nginx, add a <code>location<\/code> block to deny access to the backup directory.<\/p><\/dd>\n<dt id=\"what%20happens%20to%20my%20data%20if%20i%20uninstall%20the%20plugin%3F\"><h3>What happens to my data if I uninstall the plugin?<\/h3><\/dt>\n<dd><p>Deleting BackupRidge from Plugins \u2192 Installed Plugins removes its settings, scheduled cron events, and its backup storage directory (<code>wp-content\/uploads\/backupridge<\/code>), including any backup archives stored there. If you want to keep your backups, move or download them to another location, or switch to a remote storage destination, before deleting the plugin. Simply deactivating the plugin (without deleting it) leaves all settings and stored backups untouched.<\/p><\/dd>\n\n<\/dl>\n\n<!--section=changelog-->\n<h4>1.34.1<\/h4>\n\n<p><strong>Bugfix release.<\/strong><\/p>\n\n<ul>\n<li>Fix: The WordPress.org listing correctly shows \"BackupRidge Pro\" again (a packaging bug had rewritten it to \"BackupRidge Advanced\").<\/li>\n<li>Fix: Pinning or unpinning a completed backup no longer corrupts its displayed Duration.<\/li>\n<li>Fix: The \"leftover job temp\" advisory no longer counts a running job's own working files as debris from a failed job.<\/li>\n<li>Fix: The \"throughput is decaying\" health advisory no longer false-fires during the upload phase on a steady, bursty multipart transfer.<\/li>\n<\/ul>\n\n<h4>1.34.0<\/h4>\n\n<p><strong>Pre-update snapshots with one-click rollback, cross-site adopt\/restore, encryption key export, and a ZIP-only archive format.<\/strong><\/p>\n\n<ul>\n<li>Feature: Pre-update snapshots -- before a plugin, theme, or core update runs (including unattended WP-Cron auto-updates), the plugin takes an automatic snapshot; a new Restore Points widget lets you roll back to it in one click.<\/li>\n<li>Feature: (Premium) Export and back up the archive-encryption key on its own, so encrypted archives stay restorable even after a fresh WordPress install.<\/li>\n<li>Feature: New <code>wp backupridge discover<\/code>\/<code>import<\/code> WP-CLI commands register existing archive files already on disk as restorable jobs.<\/li>\n<li>Feature: The adopt flow now recognizes and can restore backups authored by another site or domain -- a rebuilt site, a host move, or a custom filename prefix.<\/li>\n<li>Feature: Onboarding wizard adds a dedicated \"I'm restoring or moving an existing site\" branch alongside the fresh-setup path.<\/li>\n<li>Changed: Backup archives are now ZIP-only; tar.gz support has been removed following its part-convergence and resumption issues.<\/li>\n<li>Changed: Restore and migration now correct the site URL immediately after the database import, before the full search-and-replace sweep runs.<\/li>\n<li>Changed: Imported and adopted jobs now persist their full backup manifest for accurate URL and table-prefix detection during restore.<\/li>\n<li>Fix: A backup that finished archiving could be incorrectly marked failed over entries that were re-archived but not actually a problem.<\/li>\n<li>Fix: Skipped-file counts are now reported correctly across a backup that resumes more than once.<\/li>\n<li>Fix: R2\/S3 multipart upload completion failures now surface the storage provider's actual error in the job log instead of a generic message.<\/li>\n<li>Fix: The onboarding wizard now reliably resumes instead of restarting.<\/li>\n<\/ul>\n\n<h4>1.33.0<\/h4>\n\n<p><strong>Faster backups and restores from measured host performance, parallel destination uploads, and a broad set of reliability and accuracy fixes.<\/strong><\/p>\n\n<ul>\n<li>Feature: Parallel destination uploads -- backups with more than one storage destination can now upload to all of them at the same time instead of one after another. Off by default; Settings suggests enabling it when your setup is a good fit.<\/li>\n<li>Feature: A completed backup that failed to reach one destination can now be pushed to that destination again afterward, without re-running the whole backup.<\/li>\n<li>Feature: A \"Local temporary files\" panel on the Storage page lets you view and remove leftover backup working files immediately.<\/li>\n<li>Feature: A new notice lets you know when your saved settings no longer match what the plugin has measured about your server, with a one-click way to apply the recommended values.<\/li>\n<li>Feature: (Premium) Backup verification results are now viewable from the backup history via a \"Verify\" action.<\/li>\n<li>Changed: Archive part sizing, restore import pacing, and the measured I\/O tier used for tuning are now derived from real backup performance rather than fixed defaults, improving speed most noticeably on fast hosts and remote\/S3-type destinations.<\/li>\n<li>Changed: Database export now writes larger, more efficient statements, reducing export and restore time on large sites.<\/li>\n<li>Changed: Job log messages label file\/entry counts more clearly and report upload progress per part and per destination.<\/li>\n<li>Fix: A destination that failed partway through an upload could retry indefinitely without succeeding.<\/li>\n<li>Fix: A backup that finished but failed to reach one of its destinations could be reported as fully successful instead of naming the affected destination.<\/li>\n<li>Fix: Backup checksum verification could stop partway through a large backup instead of covering every archive part.<\/li>\n<li>Fix: \"Delete local backup after upload\" did not delete the local copy.<\/li>\n<li>Fix: (Premium) Backup verification could report a backup as fully checked even when only part of it was actually checksummed.<\/li>\n<li>Fix: Clicking \"Continue\" on a manually stopped backup produced an error page; stopped backups now offer \"Retry\" instead.<\/li>\n<li>Fix: Archive part sizing could occasionally run past its time budget and be interrupted by the host mid-write.<\/li>\n<li>Fix: The backup-health advisor could raise a false slowdown warning during the upload phase.<\/li>\n<li>Fix: The mobile actions menu on the backup history list did not respond to taps for most actions.<\/li>\n<li>Fix: A small number of files could be archived twice after a backup resumed from an interruption; this is now flagged in the verification log instead of reading like a normal pass.<\/li>\n<li>Fix: Several smaller logging, display, and diagnostic accuracy improvements.<\/li>\n<\/ul>\n\n<h4>1.32.0<\/h4>\n\n<p><strong>A new backup intensity setting to pace backups on shared hosting, IO-aware auto-detect, and further reliability fixes for large backups on slow-IO hosts.<\/strong><\/p>\n\n<ul>\n<li>Added: A \"backup intensity\" setting (Unrestricted \/ Light \/ Moderate \/ Aggressive) paces file and upload batches, yielding IO\/CPU to live site traffic during a backup.<\/li>\n<li>Added: Auto-detect now measures disk write\/read throughput and uses it to recommend a more conservative preset on slow-IO hosts.<\/li>\n<li>Added: The measured disk I\/O tier and throughput are now recorded in the backup manifest and support bundle.<\/li>\n<li>Fix: The database embed now rotates onto a new archive part first when the part left open by the files phase is already large, instead of embedding into it directly.<\/li>\n<li>Fix: The resumption attempt-streak ceiling now only counts slices with no forward progress, instead of every slice once the attempt cap is reached.<\/li>\n<li>Fix: The committed-throughput stall guard now also monitors the database-embed finalize step.<\/li>\n<li>Fix: Archive part rotation now also considers marginal throughput, not only part size.<\/li>\n<li>Fix: Several log and status accuracy improvements from a field review of a slow-host backup.<\/li>\n<\/ul>\n\n<h4>1.31.0<\/h4>\n\n<p><strong>Reliability fixes for large backups on slow or resource-constrained hosts, plus quieter progress estimates and rate-limited health-advisory emails.<\/strong><\/p>\n\n<ul>\n<li>Fix: Archive part rotation now recognizes a hand-off close as forward progress, preventing a full-part budget from repeatedly landing on the same size ceiling during long-running backups.<\/li>\n<li>Fix: Archive part-size budgeting is now based on usable slice time rather than the full slice, so a full-part rewrite reliably completes within one resumption slice.<\/li>\n<li>Fix: Added a throughput-based stall guard that detects near-zero committed progress and forces a restart, complementing the existing time-based stall detection.<\/li>\n<li>Fix: The backup-health advisor now keeps its running state when a phase re-enters, instead of resetting its projections.<\/li>\n<li>Fix: Estimated time to completion now requires a minimum sample size and is capped for display, preventing implausible multi-hundred-thousand-hour estimates from brief, noisy throughput samples.<\/li>\n<li>Fix: A user-requested stop mid-slice no longer logs a stray resumption warning after the stop has already been recorded.<\/li>\n<li>Fix: Job log messages now use plain ASCII dashes, avoiding mojibake in downloaded or emailed logs on some mail clients.<\/li>\n<li>Changed: Health-advisory emails are now rate-limited per job to avoid repeated notifications for the same ongoing issue.<\/li>\n<li>Security: Added automated dependency vulnerability scanning to CI.<\/li>\n<\/ul>\n\n<h4>1.30.1<\/h4>\n\n<p><strong>Backup logs are now quieter on long-running jobs.<\/strong><\/p>\n\n<ul>\n<li>Changed: Backup logs no longer repeat the same job header and per-resumption boilerplate lines on every WP-Cron\/self-call segment; status poll lines now only appear with debug logging enabled, and a stalled segment logs an explicit no-progress warning with restart count and elapsed time.<\/li>\n<\/ul>\n\n<h4>1.30.0<\/h4>\n\n<p><strong>Auto-detect improvements: one-click recommended settings, a backup health advisor, and archive reliability fixes for large sites on slow hosts.<\/strong><\/p>\n\n<ul>\n<li>Feature: Auto-detect's recommended settings can now be applied with one click from a banner, instead of requiring a manual visit to settings.<\/li>\n<li>Feature: A backup health advisor projects estimated completion time and flags degrading throughput while a job is running, surfacing an early advisory instead of only a final result.<\/li>\n<li>Feature: The plugin now remembers measured host performance across jobs, so Auto-detect uses previously observed behavior rather than only a fresh probe each time.<\/li>\n<li>Fix: Archive part size is now bounded by measured close throughput, so a full-part rewrite always fits within a single resumption slice, closing a feedback loop that could shrink a host's flush buffer over the course of a large backup.<\/li>\n<li>Fix: Plugin auto-update is now deferred while a backup job is active, so an update landing mid-job can no longer change the code a later resumption checkpoint reads.<\/li>\n<li>Fix: The built-in-exclusion count in the backup log now renders as plain digits on all locales.<\/li>\n<li>Fix: Fixed a crash affecting <code>tar.gz<\/code> archives across multi-part flushes.<\/li>\n<li>Fix: Failed jobs now clean up their temporary directory at failure time; the log's built-in-exclusion count no longer includes debris left behind by the plugin's own storage exclusions.<\/li>\n<\/ul>\n\n<h4>1.29.3<\/h4>\n\n<p><strong>Reliability update: more reliable database backups for large sites, plus new remote-storage cleanup tools.<\/strong><\/p>\n\n<ul>\n<li>Fix: Database backups on hosts with tight per-request time limits could restart the same portion of work indefinitely without completing, when the database was large enough that adding it to the archive didn't fit within a single time slice. The database is now added to the archive in smaller, resumable pieces so backups complete reliably regardless of database size or host speed.<\/li>\n<li>Fix: If the database export file became unavailable partway through a backup (for example, a disk cleanup timing issue), the backup could complete without including a database export. This condition is now detected and retried automatically, and the backup fails with a clear message if the file never becomes available again.<\/li>\n<li>Compatibility: Restores now support backups whose database was split into multiple pieces (see above); backups made before this update continue to restore exactly as before.<\/li>\n<li>Feature: Added a \"detected remote orphans\" view to find and clean up files left behind in remote storage from interrupted or superseded backups, with per-group delete and dismiss options.<\/li>\n<li>Fix: The Pro license reactivation prompt now appears correctly when a Pro build has an inactive license.<\/li>\n<li>Fix: Remote storage retention cleanup now runs before local job-record cleanup, closing a race that could leave orphaned files in remote storage.<\/li>\n<\/ul>\n\n<h4>1.29.2<\/h4>\n\n<p><strong>Reliability update: fixes for slow\/tightly-limited hosts, backup verification, and remote storage retention.<\/strong><\/p>\n\n<ul>\n<li>Fix: On hosts that hard-kill the backup process mid-run, file entries added just before the kill could be silently dropped from the archive while the backup still reported 100% complete. The checkpoint is now only advanced after the archive part has actually been closed, so a kill during close is retried instead of silently skipped.<\/li>\n<li>Fix: On hosts whose real process-kill limit is shorter than what PHP reports, the backup now detects a stall and shrinks its own timing budget accordingly, instead of repeatedly losing the same slice to the same kill window.<\/li>\n<li>Fix: Closing a large archive part or embedding a large database export could still be killed mid-operation on a tightly time-limited host; the plugin now learns this host's speed and defers these operations to the next resumption when there isn't enough time left to finish them safely.<\/li>\n<li>Fix: Files that vanished or became unreadable between the file scan and the archive step were counted as successfully backed up, which could make the archive-completeness check introduced in 1.29.1 fail a backup that was actually complete. These files are now tracked and logged separately instead.<\/li>\n<li>Fix: A backup that failed for a genuine reason could be automatically resumed and re-run, producing a second, unrelated error and abandoning the archive parts the failed run had already built. A hard failure now cancels any pending continuation and can no longer be resurrected.<\/li>\n<li>Fix: The backup log's per-component built-in exclusion counts could report far more excluded data than a component actually contained, when multiple components shared the same scan area.<\/li>\n<li>Fix: Testing an SFTP connection failed for a brand-new destination folder that didn't exist yet, even with fully correct credentials. It now succeeds as long as any parent directory exists, matching how the actual upload creates the folder.<\/li>\n<li>Fix: If deleting one part of a multi-part backup from remote storage failed, retention cleanup silently left the rest of that backup's parts in place with no indication anything went wrong. A failed deletion now stops only that backup's cleanup and reports the error, without blocking cleanup of other backups.<\/li>\n<\/ul>\n\n<h4>1.29.1<\/h4>\n\n<p><strong>Reliability update: safer backup completion checks, retention fixes, and a new pin-to-keep option.<\/strong><\/p>\n\n<ul>\n<li>New: Pin a backup to exclude it from automatic retention cleanup, so it stays in place even as older backups are cleaned up.<\/li>\n<li>New: One-click Support Bundle \u2014 export a diagnostics bundle (settings, logs, environment info) to share when contacting support.<\/li>\n<li>New: Support links now route Free users to the WP.org support forum and licensed users to direct support, based on your plan.<\/li>\n<li>Fix: Backups now verify the completed archive's file count before marking the job successful, so an incomplete archive is caught immediately.<\/li>\n<li>Fix: Hardened the backup watchdog against starting a duplicate continuation of a job that was still running, on hosts with slow or irregular cron timing.<\/li>\n<li>Fix: Backup lock handling now checks whether the process holding the lock is still alive, rather than elapsed time alone, on hosts under heavy load.<\/li>\n<li>Fix: Retention cleanup no longer removes the newest full-site backup when the most recent run was a database-only backup.<\/li>\n<li>Fix: Retention cleanup now correctly removes old backups from remote storage destinations in configurations where it previously left extra backups \u2014 and extra storage usage \u2014 behind.<\/li>\n<li>Fix: Local and remote copies of the same backup are now retained consistently.<\/li>\n<li>Fix: Backups added via import or re-attach are now retained in the correct order.<\/li>\n<li>Fix: Cloud storage file listings are now paginated and correctly distinguish an empty folder from a listing error.<\/li>\n<li>Fix: Interrupted multipart cloud uploads are now cleaned up automatically instead of leaving incomplete fragments in remote storage.<\/li>\n<li>Change: The backup log now records built-in exclusion counts and plugin\/WordPress\/PHP versions, to make diagnosing issues easier.<\/li>\n<\/ul>\n\n<h4>1.29.0<\/h4>\n\n<p><strong>Major update: redesigned incremental backups, Pro push migration &amp; staging, safer restores, and license\/security hardening.<\/strong><\/p>\n\n<ul>\n<li>New (Pro): Direct push migration &amp; staging \u2014 push a full site to another WordPress install with pre-flight checks, chunked resumable transfer, automatic URL search-replace, and a post-migration health check. Staging mode clones to a staging target behind a typed production-push confirmation.<\/li>\n<li>New (Pro): Incremental backups now use a differential model (delta since the last full\/baseline) instead of a forward chain. A restore needs only two archives \u2014 the baseline plus the chosen differential \u2014 removing the old dependency on an unbroken chain of every prior run.<\/li>\n<li>New: Each archive now embeds a self-describing file manifest (paths, hashes, baseline reference), so restores are deletion-correct and portable \u2014 an archive can be restored on a new site, or after a license lapse, without depending on stored site state. Restore remains a free feature.<\/li>\n<li>New: Backup history now labels each backup as Full or Differential so you can identify the baseline at a glance.<\/li>\n<li>Fix: Restoring a standalone differential without its baseline is now blocked with a clear explanation instead of silently producing an incomplete site.<\/li>\n<li>Fix: Retention never prunes a baseline that a later differential still depends on, and manually deleting a depended-on baseline now requires confirmation.<\/li>\n<li>Fix: Incremental change detection compares file size alongside modification time, so content changes that preserve the original mtime are no longer skipped. Incremental backups also re-baseline automatically on a configurable cadence.<\/li>\n<li>New: Site migration now performs serialization-safe search-replace across plugin tables (not only core WordPress tables) on the destination.<\/li>\n<li>Security: Hardened the migration chunk assembler against path traversal via unvalidated identifiers, confining all archive writes and deletes to the migration work area.<\/li>\n<li>Security (Pro): License plan tiers are now enforced, so a Personal license no longer unlocks Business-tier features. License validation adds a 14-day offline grace period so a license-server outage no longer disables Pro features for paying customers, sends a site-ownership proof on license detail and transfer calls, and includes the license key when connecting cloud storage via Quick Connect.<\/li>\n<li>Change: Clearer upgrade information \u2014 accurate plan names and pricing on the in-plugin upgrade screens, and the readme now documents site migration and the WP-Cron vs. system-cron scheduling split.<\/li>\n<li>Fix: On a slow or contended host, a batch of many small files during file backup could go long enough without a heartbeat that a background watchdog started a duplicate resumption while the original was still running, silently dropping archive entries while the backup still reported success. The heartbeat now refreshes throughout the batch, not only once it finishes.<\/li>\n<li>Fix: Uninstalling no longer leaves job-scheduled cron events behind.<\/li>\n<li>Fix: Removed the \"use custom database tables\" setting, which never had a backing implementation.<\/li>\n<\/ul>\n\n<h4>1.28.8<\/h4>\n\n<ul>\n<li>Fix: On a Pro install, the \"Go Pro\" upgrade link in the page header kept showing even after successfully activating a license, and the header never showed a badge for the active plan. Pro now shows an \"Activate License\" prompt only while unlicensed, and the plan's badge once a license is active.<\/li>\n<\/ul>\n\n<h4>1.28.7<\/h4>\n\n<ul>\n<li>Fix: During restore, a brief window existed where a concurrent status check could see the source backup's job as still \"running\" and start it again, overwriting the backup archive while it was being restored from. Restore now holds the source job's lock for its full duration so this can't happen.<\/li>\n<li>Fix: A backup restored from a mysqldump-based export could resurrect and re-run its own source backup job, overwriting the original archive, because the exported database dump included the plugin's own in-progress job data. Database exports now exclude this data, matching the existing PHP-export path.<\/li>\n<li>Fix: A backup could run twice in a row and duplicate its database dump in the archive when two internal triggers (e.g. a manual start and a scheduled resumption check) raced to start the same job within the same second. The second trigger now always sees the job's true up-to-date status instead of a stale cached copy.<\/li>\n<li>Fix: Large-file backups could produce an oversized archive part exceeding the configured maximum size; the flush threshold is now capped by the space actually remaining in the current part.<\/li>\n<li>Fix: Restores could appear frozen for 20+ seconds on modern hosts due to an overly conservative pause between each database table; the pause is now much shorter while remaining safe for older MySQL versions.<\/li>\n<li>Fix: Backup log filenames now consistently match their corresponding archive filenames.<\/li>\n<li>Change: Removed the plugin's custom dark-mode styling, which only recolored the plugin's own content area and looked inconsistent with the rest of the WordPress admin.<\/li>\n<\/ul>\n\n<h4>1.28.6<\/h4>\n\n<ul>\n<li>Fix: On slow hosts, a large backup could log \"completed successfully\" while actually storing nothing \u2014 the finished archive was lost when a background watchdog restarted the job during the final archive step (embedding the database and closing the archive). That final step is now reliable: it keeps the job alive while it runs, resumes correctly if interrupted, and \u2014 as a safety net \u2014 the backup now fails with a clear error instead of reporting success when no archive was produced. If you run large backups on a slow host, please run a fresh backup and confirm it completes with archives present.<\/li>\n<li>Change: Per-component backup log lines now report each component's full file count instead of only the files added in the final resumption segment, so the log accurately reflects how much was archived.<\/li>\n<\/ul>\n\n<h4>1.28.5<\/h4>\n\n<ul>\n<li>Fix: Backups containing a few very large files now split into properly-sized parts instead of one oversized part that could far exceed the configured maximum (and be rejected by storage providers with a per-file size limit). The time limit is also checked while those large files are added, so backups still pause and resume in time on slow hosts.<\/li>\n<li>Change: Clearer backup logs \u2014 a missing optional mu-plugins directory is now logged as informational rather than an error, and a remote upload that continues across requests logs \"Resuming provider\" instead of \"Starting provider\".<\/li>\n<\/ul>\n\n<h4>1.28.4<\/h4>\n\n<ul>\n<li>Fix: When a backup moves many large archive parts into local storage on a slow host, it now pauses and resumes cleanly between parts instead of risking a timeout part-way through the transfer.<\/li>\n<li>Change: Clarified the \"Resumption attempts\" setting \u2014 it is now labelled a soft limit, with help text explaining that it never fails a backup on its own (a genuinely stuck backup is stopped automatically by stall detection).<\/li>\n<\/ul>\n\n<h4>1.28.3<\/h4>\n\n<ul>\n<li>Fix: On hosts that allow longer PHP execution, backups now run in fewer, longer segments instead of restarting roughly every 90 seconds. This cuts resumption overhead and the number of background hand-offs on large sites; total backup time is unchanged on restrictive hosts.<\/li>\n<li>Fix: A backup that stops making progress is now detected and stopped with a clear error after several idle resumptions, instead of resuming indefinitely. This closes a gap where a stuck database-export or upload phase could loop forever.<\/li>\n<li>Fix: Split archive parts no longer exceed the configured maximum part size. Previously a single batch of files could push a part well over the limit, which could cause a remote destination with a hard per-part size limit to reject the upload.<\/li>\n<li>Change: The backup log is more diagnostic. It now warns (with the specific reason) when the slower pure-PHP archive method is used, and lists the largest subdirectories by file count in each component, making it easier to spot and exclude caches or other bloat that slow backups down.<\/li>\n<\/ul>\n\n<h4>1.28.2<\/h4>\n\n<ul>\n<li>Change: Backup downloads now run through WordPress's standard request handling instead of a separate download script. This improves compatibility with hosts that block direct PHP execution under the uploads directory. Existing download links keep working; no action is required.<\/li>\n<li>Security: Removed all directly-accessible standalone PHP files from the plugin and stopped writing any PHP into the uploads directory.<\/li>\n<\/ul>\n\n<h4>1.28.1<\/h4>\n\n<ul>\n<li>Fix: Dropbox uploads failed with a \"not_found\" error because the upload session id was parsed incorrectly, and files were written to a doubled \"\/backups\/backups\/\" path. Both are resolved.<\/li>\n<li>Fix: OneDrive and Google Drive uploads now send the correct total file size in the Content-Range header, so OneDrive no longer rejects chunks and Google Drive reliably finalizes the uploaded file.<\/li>\n<li>Fix: Backblaze B2 uploads now stream large archives via the B2 large-file API instead of loading the whole file into memory, eliminating out-of-memory fatals on large backups.<\/li>\n<li>Fix: Each remote destination now keeps its own resumable-upload checkpoint, preventing one provider from reusing another provider's in-progress upload when the same archive is sent to multiple destinations.<\/li>\n<li>Fix: A backup destination that exhausts its retries is now recorded and skipped on later resumptions, so an unreachable destination can no longer loop a backup indefinitely; the backup completes with warnings instead.<\/li>\n<li>Fix: Resuming between destinations now advances the resumption counter correctly, preventing duplicate work and intermittent upload errors during multi-destination backups.<\/li>\n<\/ul>\n\n<h4>1.28.0<\/h4>\n\n<ul>\n<li>New: S3 and Cloudflare R2 destinations now include a cleanup tool to list and abort orphaned incomplete multipart uploads left behind by interrupted backups. AWS and R2 charge for stored parts until they are explicitly aborted; the new admin endpoints expose this via the storage settings page.<\/li>\n<li>Fix: Google Drive, Dropbox, and OneDrive uploads now stream archive data in chunks instead of loading the entire file into memory, eliminating out-of-memory fatals when uploading large archives. Google Drive additionally recovers the server-side byte offset on WP-Cron resumption so interrupted uploads continue cleanly.<\/li>\n<li>Fix: Out-of-memory fatals during the upload phase now show a specific message advising users to reduce the maximum archive size (Settings \u2192 Archive) rather than the generic batch-size message, which does not apply to upload memory usage.<\/li>\n<li>Fix: Eleven upload pipeline stability fixes: multipart upload abort on failure, per-provider retry budget enforcement, resumption slice guard to prevent starvation, progress stall detection, and more.<\/li>\n<\/ul>\n\n<h4>1.27.1<\/h4>\n\n<ul>\n<li>Fix: Resolved an infinite resumption loop during the upload phase when <code>resumption_slice_seconds<\/code> is configured and one or more remote providers fail before an S3\/R2 destination. The per-provider retry delay could exhaust the execution slice budget, causing the S3 chunked upload to yield immediately on every segment without sending any data. The retry delay now yields the slice instead of blocking when the deadline is approaching. Additionally, already-completed provider uploads are now preserved across resumption segments so they are not re-run unnecessarily.<\/li>\n<\/ul>\n\n<h4>1.27.0<\/h4>\n\n<ul>\n<li>New: Upload failures are now logged per provider and recorded in job history. Jobs that succeed to at least one destination (but fail others) complete with a \"Complete with Warnings\" status and a yellow badge, keeping them restorable while surfacing the partial failure.<\/li>\n<li>New: Storage providers that fail a connection test are marked \"Unavailable\" and disabled as backup destinations until re-tested \u2014 preventing silent backup omissions.<\/li>\n<li>New: If the site's encryption key has changed since credentials were last saved, affected providers are flagged with a \"Key mismatch\" badge and disabled until credentials are re-entered. An admin notice lists the affected providers and links to the storage settings page.<\/li>\n<li>New: OAuth providers (Google Drive, OneDrive, Dropbox) now run an automatic connection test immediately after authorization redirect, so any permission or scope issue surfaces instantly.<\/li>\n<li>New: Configurable per-provider upload retry: if an upload to a provider fails after all chunk-level retries are exhausted, BackupRidge retries the entire provider upload up to N times (default: 2) with a configurable delay (default: 30 s). If all retries fail, the provider is marked unavailable. Configure under Settings \u2192 Upload.<\/li>\n<li>Improved: AjaxHandler refactored into nine focused handler classes, reducing the largest file from ~5,200 to ~460 lines and making the codebase easier to audit.<\/li>\n<li>Improved: Reviewer-parity error count reduced from 230 to 45 (structural floor \u2014 remaining items are genuine WordPress coding standards edge cases with inline justifications).<\/li>\n<\/ul>\n\n<h4>1.26.2<\/h4>\n\n<ul>\n<li>Fixed: Plugin Check gate now correctly handles the per-file output format introduced in Plugin Check 1.9.0, preventing findings from being silently missed.<\/li>\n<li>Fixed: Applied <code>esc_sql()<\/code> to the migration preflight test table name in HandshakeValidator to satisfy Plugin Check 1.9.0's new database parameter check.<\/li>\n<li>Improved: Replaced string interpolation with concatenation in SearchReplace queries to remain compatible with Plugin Check's annotation-stripping PHPCS mode.<\/li>\n<li>Improved: Suppression baseline lowered from 16 to 14 (two now-unnecessary suppressions removed).<\/li>\n<\/ul>\n\n<h4>1.26.1<\/h4>\n\n<ul>\n<li>Fixed: Removed unnecessary <code>ini_set('memory_limit')<\/code> fallback \u2014 <code>wp_raise_memory_limit()<\/code> is always available on supported WordPress versions.<\/li>\n<li>Fixed: Replaced <code>strip_tags()<\/code> with <code>wp_strip_all_tags()<\/code> per WordPress coding standards.<\/li>\n<li>Improved: Added inline code comments explaining SQL identifier escaping, dynamic IN() list patterns, cron interval necessity, base64 encoding usage, and standalone download gateway patterns \u2014 making the codebase easier to audit and reducing false-positive flags during WordPress.org review.<\/li>\n<li>Improved: Log file download now applies <code>wp_strip_all_tags()<\/code> before output.<\/li>\n<li>Improved: Input sanitization applied at the point of read for array parameters in AJAX handlers.<\/li>\n<\/ul>\n\n<h4>1.26.0<\/h4>\n\n<p><strong>Security release \u2014 please review the cron note below if you use system cron.<\/strong><\/p>\n\n<ul>\n<li>Important: The system-cron trigger now authenticates with an HTTP header (<code>X-BackupRidge-Cron-Key<\/code>) instead of a key in the URL, so the secret no longer leaks into server access logs or Referer headers. <strong>If you run BackupRidge from a system cron job, update it to the new command shown on the Settings page<\/strong> \u2014 the old <code>?key=<\/code> URL will now return 403. To keep using the URL-key method, add <code>define( 'BACKUPRIDGE_ALLOW_CRON_QUERY_KEY', true );<\/code> to wp-config.php.<\/li>\n<li>Security: Backup archives and logs are now protected against direct web access with deny rules and an unguessable token in each filename.<\/li>\n<li>Security: Blocked PHP object injection during restore search-and-replace.<\/li>\n<li>Security: Test-only scaffolding AJAX handlers are no longer registered in production builds.<\/li>\n<li>Security: The standalone download endpoint is now confined to the backup directory (path-traversal hardening).<\/li>\n<li>Security: Backup downloads now send <code>Referrer-Policy<\/code> and <code>X-Robots-Tag: noindex<\/code> headers.<\/li>\n<li>Security: Database identifiers are escaped through a single helper and ID lists use prepared statements.<\/li>\n<li>Changed: On multisite, backup, restore, storage, and migration actions now require a network super-admin.<\/li>\n<li>Changed: Documentation clarifies that archive encryption uses AES-256-GCM authenticated encryption (legacy AES-256-CBC archives remain decryptable for restore).<\/li>\n<\/ul>\n\n<p>For the complete version history, see the plugin's SVN changelog.<\/p>","raw_excerpt":"Backups that finish \u2014 even on slow shared hosting. Resumable WordPress backup, restore, and migration to S3, R2, FTP, SFTP, and more.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/286309","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=286309"}],"author":[{"embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/stavatech"}],"wp:attachment":[{"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=286309"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=286309"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=286309"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=286309"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=286309"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/tw.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=286309"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}