web.config<\/code> rules there, but those only apply on Apache and IIS - on Nginx they are ignored and the archive is served as an ordinary static file to anyone who knows its name.<\/p>\n\nBecause of that the plugin actively tests the folder before every backup: it requests a temporary file from it over HTTP with no login. If the server hands that file over, the backup is refused rather than created and left downloadable - a backup contains your whole database, so the plugin will not produce one it cannot keep private.<\/p>\n\n
Some hosts block a site from making requests to itself, so the test cannot run. Backups are refused then too: the server's name cannot settle it, because many hosts put Nginx, which ignores .htaccess<\/code>, in front of Apache.<\/p>\n\nTo fix it, move backups out of the web root by adding this to wp-config.php<\/code>:<\/p>\n\ndefine( 'WPCB_BACKUP_DIR', '\/full\/path\/outside\/public_html\/rebuzz-backups' );\n<\/code><\/pre>\n\nThe path must be absolute and writable by PHP, and should sit outside the folder your web server serves. Archives already in the old location are not moved automatically - the Backups tab will tell you they are there so you can move them yourself.<\/p><\/dd>\n
My backup is too big to upload. Now what?<\/h3><\/dt>\nPut the ZIP in wp-content\/uploads\/rebuzz-backup-and-restore\/backups\/<\/code> using FTP or your host's file manager. It appears in the restore list automatically and skips the browser upload limit entirely. The exact path is also shown on the ReBuzz Backup<\/strong> screen, under the backups list.<\/p><\/dd>\nDoes it support Multisite?<\/h3><\/dt>\nYes. A network administrator can back up the whole network, while an individual site admin gets only their own site. Restores enforce the same boundary.<\/p><\/dd>\n
Is the backup checked before it gets restored?<\/h3><\/dt>\nEvery file and the database dump is hashed with SHA-256 when the backup is made, and those hashes are re-checked before the restore writes anything. If one doesn't match, the restore stops rather than continuing with a corrupt archive.<\/p><\/dd>\n
How do scheduled backups run without my browser open?<\/h3><\/dt>\nWordPress's scheduler (WP-Cron) starts the backup at the hour you picked. The site then asks itself for each step in turn, the same small steps a manual backup takes, so the same time and memory limits apply. If those requests are blocked by the host, WP-Cron carries the backup on by itself every few minutes, and a backup that stops making progress for ten minutes is marked failed and reported.<\/p><\/dd>\n
Why didn't my scheduled backup start exactly on time?<\/h3><\/dt>\nWP-Cron only runs when someone visits the site, so on a quiet site a backup can start a little late. If your host offers real cron jobs, point one at wp-cron.php<\/code> every few minutes. If DISABLE_WP_CRON<\/code> is set in wp-config.php, scheduled backups only run when your host runs wp-cron.php<\/code> for you - the Schedule tab tells you when that's the case.<\/p><\/dd>\nWill scheduled backups delete my other backups?<\/h3><\/dt>\nNo. Only backups the schedule made on this site are ever deleted to keep the number you chose. Backups you create yourself, and ones you upload or copy in, are never deleted automatically.<\/p><\/dd>\n
I'm not receiving the emails.<\/h3><\/dt>\nUse Send test email<\/strong> on the Schedule tab. If that email doesn't arrive either, WordPress on your host can't send mail yet - an SMTP plugin usually fixes it. Check the spam folder too.<\/p><\/dd>\nWhich cloud storage can I use?<\/h3><\/dt>\nAmazon S3 and services with the same API - Backblaze B2, Cloudflare R2, DigitalOcean Spaces, Wasabi, or any other S3-compatible storage you give an endpoint for - and Dropbox. Set them up on the Storage tab; Test connection<\/strong> writes a small file and deletes it again, so you know uploads will work before the first backup. Google Drive is planned for a later version.<\/p><\/dd>\nAre my storage keys safe?<\/h3><\/dt>\nThe S3 secret key and the Dropbox access are stored encrypted, with a key made from the secret keys in your wp-config.php<\/code>. Backups include your database but never wp-config.php<\/code>, so a backup only ever carries the encrypted form. The form never shows a saved secret again. After moving the site to a server with different secret keys, enter the secret again or reconnect Dropbox. Restoring a backup onto a site that already has cloud storage set up keeps that site's own connection.<\/p><\/dd>\nMy server died. How do I restore from the cloud?<\/h3><\/dt>\nInstall WordPress and this plugin on the new server, set up the same storage on the Storage tab, click Show backups<\/strong>, then Download to this site<\/strong> next to the backup you want. It then appears on the Restore tab like any other backup.<\/p><\/dd>\nWhat does \"Keep a copy here too\" do?<\/h3><\/dt>\nWith it ticked (the default), each backup stays on your server as well as in the cloud. Untick it to save disk space: the copy on your server is deleted once the backup has reached every place you chose. If any upload fails, the copy on your server is always kept.<\/p><\/dd>\n\n<\/dl>\n\n\n
1.8.0<\/h4>\n\n\n- Added: cloud storage, on a new Storage tab. Backups can go to Amazon S3 and S3-compatible services (Backblaze B2, Cloudflare R2, DigitalOcean Spaces, Wasabi and others, signed with Signature V4) and to Dropbox (connected with a code you paste, into the plugin's own app folder). Test connection writes and deletes a small file.<\/li>\n
- Added: new backups are sent automatically - scheduled ones only, or every backup - in 8 MB pieces across many short requests, so large backups fit shared-hosting limits. A failed upload is retried, then reported as a warning; the backup itself is never lost.<\/li>\n
- Added: keep the last 1 to 100 backups in each place. Only backups this site uploaded automatically are deleted; other files in the bucket or folder, and backups you send by hand, are never touched.<\/li>\n
- Added: Backups in the cloud - list them, download one back to the server to restore it (onto the same site or a new one), or delete one. Send a backup you already have from the same tab.<\/li>\n
- Added: a download or send that stops because its page was reloaded or left carries on from where it stopped, at the top of whichever ReBuzz Backup tab opens next. Cancel stops one at any time and removes the part already transferred, including an unfinished S3 upload.<\/li>\n
- Added: leaving or reloading the page while a backup, restore or transfer is running from it asks first.<\/li>\n
- Added: an option to remove the copy on the server once a backup has reached every place chosen; if any upload fails, the local copy is kept.<\/li>\n
- Added: S3 and Dropbox tags on the Backups tab, and upload results in the finished-backup message and the email.<\/li>\n
- Security: the S3 secret and the Dropbox tokens are stored encrypted with a key derived from wp-config.php's secret keys, so backups - which contain the database - only hold the encrypted form.<\/li>\n
- Changed: a restore keeps the site's cloud connection when one is set up, instead of bringing back the backup's, and keeps track of backups uploaded after the restored backup was made, so keep-the-last-N still deletes them in time.<\/li>\n<\/ul>\n\n
1.7.0<\/h4>\n\n\n- Added: scheduled backups, daily or weekly at an hour in your site's timezone, on a new Schedule tab. They run in the background with no browser open: the site requests each step itself, taking the same small steps as a manual backup, and WP-Cron carries the backup on if those requests are blocked. The chosen hour holds across daylight-saving changes.<\/li>\n
- Added: keep the last 1 to 50 scheduled backups. Older scheduled backups are deleted when a new one finishes; backups you make yourself, upload or copy in are never deleted.<\/li>\n
- Added: email notices to one or more addresses, either only when something goes wrong or after every scheduled backup, with a Send test email button.<\/li>\n
- Added: Run scheduled backup now, a Next backup card on the Backups tab, a Scheduled tag on backups the schedule made, and live progress of a background backup on both tabs.<\/li>\n
- Added: a scheduled backup that makes no progress for ten minutes is marked failed and reported, and releases its lock, instead of blocking later backups.<\/li>\n
- Changed: a scheduled backup never starts while a restore or another backup is running; it is skipped and reported instead.<\/li>\n
- Changed: a restore keeps the schedule's record of the backups it made, so keep-the-last-N still deletes backups made after the restored one.<\/li>\n<\/ul>\n\n
1.6.0<\/h4>\n\n\n- Changed: the plugin's screens are now tabs - Backups, Restore and Settings - under a single ReBuzz Backup menu item, laid out in cards. The Backups tab opens with when the last backup ran, how much space backups use and whether the backup folder is private. Links to the old Restore and Settings pages still work.<\/li>\n
- Added: after a restore, a reminder to open Permalink Settings. The restore rebuilds the link rules before the restored plugins have loaded, so rules those plugins add - shop, product or form pages, for example - could show \"Page not found\". Opening that page rebuilds them and ends the reminder.<\/li>\n
- Added: the Settings tab explains what including WordPress core changes, and now holds the system information that used to fill the top of the dashboard.<\/li>\n
- Fixed: the Temporary Files panel showed on every site, reporting about 723 B, because the temporary folder's own access-blocking files were counted as leftovers. Clearing temporary files also deleted those files; they are now kept.<\/li>\n
- Fixed: other backup plugins' folders are listed only when they hold something to clear, instead of showing \"0 B\".<\/li>\n<\/ul>\n\n
1.5.4<\/h4>\n\n\n- Security: on hosts whose open_basedir setting keeps PHP out of the web root, a WPCB_BACKUP_DIR inside the web root was accepted as private, so backups saved there could be downloaded by anyone. PHP could not look up the web root there, and the check left it out instead of comparing against its path as written. It now compares against the path, so such a folder is refused and backups fall back to the uploads folder and its privacy test.<\/li>\n
- Fixed: on those hosts the same check wrote \"open_basedir restriction in effect\" warnings to the PHP error log during every backup and restore.<\/li>\n<\/ul>\n\n
1.5.3<\/h4>\n\n\n- Security: when the plugin cannot test whether the backups folder is private - some hosts block a site from making requests to itself - backups are now refused, as they already were on Nginx. It used to trust the server's name instead, but many hosts put Nginx in front of Apache: PHP reports Apache while Nginx serves the archive and ignores the .htaccess rule. Setting WPCB_BACKUP_DIR to a folder outside the web root fixes it, as before.<\/li>\n
- Changed: a privacy test that could not run is retried after five minutes instead of a day, so a passing network error does not turn backups off for long.<\/li>\n
- Fixed: a finished backup is discarded only when the backups folder is proven public, not when the test repeated after the backup cannot run.<\/li>\n
- Fixed: a deleted backups folder is recreated, instead of blocking new backups and uploads until the plugin was reactivated.<\/li>\n<\/ul>\n\n
1.5.2<\/h4>\n\n\n- Fixed: on hosts that disable PHP's disk_free_space(), uploading a backup or starting a restore crashed on PHP 8 with \"Call to undefined function\", and on PHP 7.4 was refused for having \"0 B\" free. The free-space check is now skipped there, as it already was when the host could not measure the space; the storage test that runs before every restore still catches a full account.<\/li>\n
- Fixed: on hosts that disable PHP's ini_set(), downloading a backup crashed on PHP 8 when the server had output compression turned on.<\/li>\n<\/ul>\n\n
1.5.1<\/h4>\n\n\n- Fixed: restoring a backup made on a different WordPress version could send wp-admin to the \"Database Update Required\" screen. WordPress core used to be copied file by file across many requests, so the site ran a mix of old and new core, and new core against the old database. Core is now swapped in by folder renames in one request, together with the database; if the database swap fails, the previous core is put back.<\/li>\n
- Fixed: before any plugin, theme or upload is overwritten, the restore now checks that WordPress core can actually be swapped on this server, and stops with the site unchanged if it can't.<\/li>\n
- Fixed: on Windows servers, the core swap could not rename wp-admin while the restore request was running from it. It now swaps that folder's contents one by one instead.<\/li>\n
- Fixed: the new core is swapped in straight from the extracted backup, and the old one is moved into the restore's own folder, so no copy of core sits in the website's root folder during a restore - where a server without .htaccess support, such as Nginx, could serve it.<\/li>\n
- Fixed: a PHP crash while WordPress was still loading, part-way through a restore, reported the error but left the restore marked as running and locked. It now marks the restore failed, puts plugins back and releases the lock.<\/li>\n
- Fixed: a restore killed outright by the host no longer blocks new restores until its record expires; one with no progress for 10 minutes is treated as stopped, as backups already were.<\/li>\n
- Fixed: database export and URL rewrite batches are sized from the real size of the rows about to be read, not from the table's average row length, so a run of small rows followed by very large ones can no longer exhaust PHP's memory limit.<\/li>\n
- Changed: crash messages only suggest raising the time or memory limit when that is what the error actually was.<\/li>\n
- Added: the restore screen warns before a restore when the backup was made on a different WordPress version from this site.<\/li>\n<\/ul>\n\n
1.5.0<\/h4>\n\n\n- Fixed: a failed restore no longer leaves a half-replaced database. The backup is now imported into temporary staging tables while your live site stays untouched, and only swapped in - all tables at once - after every file is in place. If the import fails, the site is exactly as it was.<\/li>\n
- Fixed: the database is now imported before any file is overwritten, so a database error can no longer leave new files running on the old database.<\/li>\n
- Fixed: database views were backed up as tables, rows included, which duplicated data or failed the restore. Views are now saved as definitions only and recreated after the tables. Older backups containing views restore correctly too.<\/li>\n
- Fixed: DEFINER clauses on views, triggers and routines are removed on backup and on restore, so a backup no longer fails on a server where the original database user doesn't exist.<\/li>\n
- Fixed: backups from MySQL 8 now restore onto older MySQL and MariaDB servers - the utf8mb4_0900_* collations and the utf8mb3 name are translated to ones the server knows.<\/li>\n
- Fixed: a PHP crash during a restore now reactivates your plugins, instead of leaving all of them switched off.<\/li>\n
- Fixed: restored PHP files are cleared from OPcache, preventing fatal errors from stale cached code right after a restore.<\/li>\n
- Fixed: the database export no longer runs in a single request, where a large database could hit the server's time limit and fail the backup. It now runs in short chunks like the other steps, and resumes by primary key, so rows added or deleted while the backup runs are never written twice.<\/li>\n
- Fixed: restoring a large database was very slow - every row was saved as its own transaction, waiting for its own disk flush, so a table with a million rows could take hours. Each chunk is now saved in one transaction, about 20 times faster in testing.<\/li>\n
- Fixed: on hosts that disable set_time_limit(), every backup and restore step crashed on PHP 8 with \"Call to undefined function\". The plugin now checks for it first; its chunked steps already stay inside the default time limit.<\/li>\n
- Fixed: an error reading a table's rows during the export now fails the backup with the table named in the log, instead of silently leaving the rest of that table out.<\/li>\n
- Fixed: the database export and URL rewrite size their batches by bytes, not a fixed row count, so tables with large rows no longer exhaust PHP's memory limit.<\/li>\n
- Fixed: a PHP fatal error now shows its real cause on the dashboard (for example the memory limit) instead of \"AJAX request failed\", and a failed job is no longer retried into the same crash.<\/li>\n
- Fixed: uploading a backup larger than the server's post_max_size now shows the \"file too large\" message instead of a blank page.<\/li>\n
- Fixed: a crashed backup no longer blocks new backups for an hour; a backup with no progress for 10 minutes is treated as stopped.<\/li>\n
- Changed: text files and the database dump are now compressed in the backup archive, making archives much smaller - which matters on shared hosting, where a restore needs room for both the archive and its extracted copy.<\/li>\n
- Fixed: protocol-relative URLs (\/\/old-site\/...) stay protocol-relative when the domain is rewritten.<\/li>\n
- Changed: the notice about leftover plugins-old\/themes-old\/uploads-old folders now warns that they may be publicly reachable.<\/li>\n<\/ul>\n\n
1.4.3<\/h4>\n\n\n- Fixed: a restore on shared hosting could run for thousands of files and then fail part-way through because the account was out of storage or had reached its file-count (inode) limit. Before a restore starts, the plugin now actually writes a few megabytes and creates a small number of test files in its own folder, and refuses to start if that fails - naming which limit was reached instead of stopping at an arbitrary file. The old check only asked the server how much space was free, which on shared hosting reports the whole disk rather than what your account is allowed to use, and cannot see inode limits at all.<\/li>\n
- Fixed: the free-space check measured the wrong folder when
WPCB_BACKUP_DIR<\/code> was set, reporting space for a filesystem the restore never writes to.<\/li>\n- Added: the restore log now records what the pre-flight checks saw on every restore, not only on failure.<\/li>\n
- Note: the new test is deliberately smaller than the first batch of a real extraction, so it cannot refuse a restore that would have worked. If it ever misfires on an unusual host,
define('WPCB_RESTORE_PROBE_FILES', 0);<\/code> in wp-config.php<\/code> turns it off.<\/li>\n<\/ul>\n\n1.4.2<\/h4>\n\n\n- Fixed: a failed extraction could report only \"Extraction failed for: \" with no cause. The plugin now identifies why - a full disk or exceeded hosting quota, a folder PHP cannot write to, a damaged or incompletely uploaded archive, a path the filesystem rejects, or the server running out of file handles - so the message says what to fix. It also now recognises the \"Not a directory\" error Linux reports where Windows reports something different.<\/li>\n
- Fixed: a file listed by the scan but missing from the extracted workspace was skipped silently, so a partial extraction could still finish reporting a clean restore. Missing files are now logged by name and counted, which triggers the existing end-of-restore warning.<\/li>\n
- Fixed: during URL rewriting, a database write that failed was still counted as a successful change.<\/li>\n<\/ul>\n\n
1.4.0<\/h4>\n\n\n- Fixed: downloading a backup from the admin panel is much faster. It was reading the archive 8KB at a time and forcing a flush after every read - roughly 77,000 of them for a 600MB file. It now reads 1MB at a time and lets the server flush, which measured about twice as fast locally. A long download is also no longer cut short by
max_execution_time<\/code>, which could leave a truncated ZIP that looked complete.<\/li>\n- Security: the plugin now refuses to create a backup it cannot store privately, instead of creating one anybody could download. Before a backup starts it checks whether the backup folder is reachable over HTTP - by requesting a short-lived file from it with no login - and stops with instructions if it is. A backup archive contains your entire database, including every user account and password hash, so an unguessable filename is not enough on its own.<\/li>\n
- Security: backup archives can be stored outside the public web root. Define
WPCB_BACKUP_DIR<\/code> in wp-config.php<\/code> with an absolute path outside public_html<\/code> and archives are kept there, where no URL maps to them at all. On Nginx, which ignores the .htaccess<\/code> rule the plugin writes, this is the arrangement that prevents a direct download.<\/li>\n- Note: on a server that serves the backup folder - typically Nginx without extra configuration - creating new backups now stops until
WPCB_BACKUP_DIR<\/code> is set. Restoring, listing, downloading and deleting existing backups are unaffected.<\/li>\n- Security: finished archives are written with restrictive file permissions, so on hosts where the web server and PHP run as different users the web server cannot read them.<\/li>\n
- Fixed: backups no longer sweep in other backup plugins' archives. Storage used by BackWPup, BackupBuddy, Duplicator, WPvivid, WP Migrate DB and All In One WP Security is now excluded alongside the folders already recognised, including the ones that live under
uploads<\/code> with a per-install name. Left in, those archives were copied into every new backup, so each one contained the one before it.<\/li>\n- Added: the Dashboard now reports leftover backup storage found under
uploads<\/code>, not just under wp-content<\/code>, so an administrator without FTP can see and reclaim it.<\/li>\n- Changed: the plugin no longer writes a generated PHP file into
wp-content\/mu-plugins<\/code>. WordPress's background auto-updater is held off during a restore with an ordinary filter instead, which does the same job without putting code anywhere plugins are not meant to write.<\/li>\n- Security: backup archive filenames now end in 32 random characters instead of 6 hexadecimal ones. Archives contain a full database dump, and on servers that ignore the
.htaccess<\/code> and web.config<\/code> rules the plugin writes - Nginx among them - an unguessable filename is what actually prevents one being downloaded directly. The storage folder itself is unchanged, so existing backups stay where they are.<\/li>\n- Fixed: mu-plugins that a restore temporarily renames aside are now recorded outside the job, and put back automatically on the next page load if the restore is killed mid-way. Previously a fatal error at the wrong moment could leave them disabled indefinitely.<\/li>\n
- Fixed: failed writes during the database export are now detected instead of ignored. A backup that runs out of disk space part-way now fails with a clear message rather than finishing \"successfully\" with a truncated dump that would restore an incomplete site.<\/li>\n
- Fixed: no output buffer is left open across the request. Buffering is now opened and closed inside the function that needs it, so it can no longer interfere with output from WordPress or other plugins.<\/li>\n
- Changed:
DOING_CRON<\/code> is no longer defined during backup and restore polling. Cron spawning is suppressed for that one request through a filter instead, so other plugins no longer see an ordinary admin request as a cron run.<\/li>\n<\/ul>\n\n1.3.5<\/h4>\n\n\n- Fixed: percent signs in database content were being replaced with an internal placeholder token while the database was exported, corrupting values such as
width: 50%<\/code> and leaving restored pages with broken layouts. Backups created with earlier versions contain this corruption and should be re-created.<\/li>\n- Fixed: URL rewriting now covers every scheme form -
https:\/\/<\/code>, http:\/\/<\/code> and protocol-relative \/\/<\/code> - so media referenced with a different scheme than the destination site's own no longer points at an unreachable address after a restore.<\/li>\n- Changed: uploaded backup archives are now handled by WordPress's own upload API, which applies stricter file-type and destination validation.<\/li>\n<\/ul>\n\n
1.3.4<\/h4>\n\n\n- Initial submission to the WordPress Plugin Directory.<\/li>\n<\/ul>","raw_excerpt":"Full-site backup and restore for WordPress, built to work within the tight PHP time and memory limits of shared hosting.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/357524","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=357524"}],"author":[{"embeddable":true,"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/rebuzz"}],"wp:attachment":[{"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=357524"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=357524"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=357524"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=357524"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=357524"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/dsb.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=357524"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}