Security: wp-config.php is no longer put into a backup that leaves your server. Internal names\nare now prefixed; your settings, history and cloud connection carry over automatically.<\/p>","1.0.9":"
Important if you use cloud storage: a failed upload could leave you with no offsite copy while\nthe backup still reported as complete. Uploads are now retried and destinations are\nindependent. Recommended for everyone.<\/p>","1.0.8":"
Fixes an unrestorable cloud backup: after connecting cloud storage the first cloud backup\ncould be an incremental with no full backup behind it. Recommended for everyone using cloud\nstorage.<\/p>","1.0.7":"
Changes the default full-backup interval for new installs to every 25 backups. Your own\nsetting is untouched if you have ever saved the settings page.<\/p>","1.0.6":"
If you have been seeing "your backup files are publicly downloadable" on an nginx host, this\nrelease fixes it during the upgrade, by itself. No wp-config.php edit and no support ticket.\nRecommended for everyone.<\/p>","1.0.5":"
Clears the false "backups are publicly downloadable" warning left behind by the 1.0.4 upgrade.\nRecommended for everyone who updated to 1.0.4.<\/p>","1.0.2":"
Plugin Check compliance fixes (i18n, translators comment). No functional change \u2014 safe to update.<\/p>","1.0.1":"
Cloud upload and restore now run against the live BackupYourSite service. Restore reports\nreal progress and real error reasons. Recommended for anyone using cloud storage.<\/p>"},"ratings":[],"assets_icons":{"icon-256x256.png":{"filename":"icon-256x256.png","revision":3727082,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-772x250.png":{"filename":"banner-772x250.png","revision":3727081,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.1.1"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3727083,"resolution":"1","location":"assets","locale":"","width":2880,"height":2302},"screenshot-2.png":{"filename":"screenshot-2.png","revision":3727160,"resolution":"2","location":"assets","locale":"","width":2880,"height":2586},"screenshot-3.png":{"filename":"screenshot-3.png","revision":3727157,"resolution":"3","location":"assets","locale":"","width":2880,"height":3404},"screenshot-4.png":{"filename":"screenshot-4.png","revision":3727084,"resolution":"4","location":"assets","locale":"","width":2880,"height":3042},"screenshot-5.png":{"filename":"screenshot-5.png","revision":3727100,"resolution":"5","location":"assets","locale":"","width":2880,"height":760}},"screenshots":{"1":"The Backups screen \u2014 backup history with size, file count and destination for every stored backup.","2":"A backup running \u2014 live progress, phase and step count while it works in small resumable steps.","3":"The Settings screen \u2014 schedule, what to include, volume size, incremental mode and retention.","4":"The restore panel \u2014 choose files\/database\/both, take a pre-restore snapshot, and confirm.","5":"The Account screen \u2014 optional BackupYourSite cloud storage, connected, with plan and quota."}},"plugin_section":[],"plugin_tags":[151,10718,4155,152,265189],"plugin_category":[59],"plugin_contributors":[],"plugin_business_model":[],"class_list":["post-371222","plugin","type-plugin","status-publish","hentry","plugin_tags-backup","plugin_tags-database-backup","plugin_tags-migration","plugin_tags-restore","plugin_tags-scheduled-backup","plugin_category-utilities-and-tools","plugin_committers-nurotech"],"banners":{"banner":"https:\/\/ps.w.org\/backupyoursite\/assets\/banner-772x250.png?rev=3727081","banner_2x":false,"banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/backupyoursite\/assets\/icon-256x256.png?rev=3727082","icon_2x":"https:\/\/ps.w.org\/backupyoursite\/assets\/icon-256x256.png?rev=3727082","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/backupyoursite\/assets\/screenshot-1.png?rev=3727083","caption":"The Backups screen \u2014 backup history with size, file count and destination for every stored backup."},{"src":"https:\/\/ps.w.org\/backupyoursite\/assets\/screenshot-2.png?rev=3727160","caption":"A backup running \u2014 live progress, phase and step count while it works in small resumable steps."},{"src":"https:\/\/ps.w.org\/backupyoursite\/assets\/screenshot-3.png?rev=3727157","caption":"The Settings screen \u2014 schedule, what to include, volume size, incremental mode and retention."},{"src":"https:\/\/ps.w.org\/backupyoursite\/assets\/screenshot-4.png?rev=3727084","caption":"The restore panel \u2014 choose files\/database\/both, take a pre-restore snapshot, and confirm."},{"src":"https:\/\/ps.w.org\/backupyoursite\/assets\/screenshot-5.png?rev=3727100","caption":"The Account screen \u2014 optional BackupYourSite cloud storage, connected, with plan and quota."}],"raw_content":"\n
BackupYourSite is a WordPress backup plugin that backs up your files and database on a\nschedule, stores the archives on your own server, and restores them again from the WordPress\nadmin in one click. An optional cloud destination adds a verified offsite copy when you want\none \u2014 everything else works with no account at all.<\/p>\n\n
It is built for cheap, limited hosting. The backup runs in small steps rather than one long\nrequest, so a short PHP time limit or a small memory limit slows it down instead of breaking\nit. If a step is killed, the next one carries on from where it stopped.<\/p>\n\n
Core backup features<\/strong><\/p>\n\n Optional: offsite cloud backup<\/strong><\/p>\n\n Backups kept on the same server share that server's fate. If you want an offsite copy, you\ncan connect a BackupYourSite account on the Account screen and add \"Cloud\" as a destination.\nThis is entirely optional \u2014 every feature above works without an account, and the plugin\nmakes no connection to our service until you paste a connection code yourself.<\/p>\n\n Your What it does not do<\/strong><\/p>\n\n Who this is for<\/strong><\/p>\n\n Anyone who wants scheduled WordPress backups and a real one-click restore without shell\naccess or a This plugin works completely on its own and makes no outbound connection by default. No\naccount is required, and nothing leaves your server unless you deliberately connect one.<\/p>\n\n Requests to your own site (always, no account needed)<\/strong><\/p>\n\n Both of these stay on your own server and are not an external service.<\/p>\n\n BackupYourSite cloud storage (optional, off until you connect it)<\/strong><\/p>\n\n If \u2014 and only if \u2014 you create a BackupYourSite account and paste a connection code into the\nplugin's Account screen, the plugin talks to the BackupYourSite backup service at\n https:\/\/app.backupyoursite.com, operated by BackupYourSite.<\/p>\n\n What is sent, and when:<\/p>\n\n Nothing is sent before you connect. No usage statistics, telemetry or analytics are ever\nsent, connected or not. Your account password is never asked for and never stored.<\/p>\n\n Service terms: https:\/\/backupyoursite.com\/terms\/\nPrivacy policy: https:\/\/backupyoursite.com\/privacy\/<\/p>\n\n\n In Open BackupYourSite \u2192 Restore<\/strong>, pick the backup to restore from, choose files, database, or\nboth, and confirm. The plugin takes a snapshot of the current site first, then restores in\nsmall steps and reports progress as it works.<\/p><\/dd>\n Take a backup on the old site, download or transfer the archive, install BackupYourSite on the\nnew site, and restore it there. The database dump and file archive are both verified before\nthey count as a usable backup, so a migration starts from a backup you know is intact.<\/p><\/dd>\n WordPress's built-in scheduler only runs when someone visits the site, so it may not. The\nSettings screen shows a cron line you can paste into your hosting control panel to fix that.<\/p><\/dd>\n No. See \"What it does not do\" above. Download the archive and restore it through your host.<\/p><\/dd>\n No. Everything the plugin does \u2014 scheduled backups, incremental backups, verification,\nretention, restore \u2014 works with no account and with no connection to us. An account only\nadds the optional offsite cloud destination. Until you connect one, the plugin makes no\nrequest to any external service at all.<\/p><\/dd>\n Not in any backup that leaves your server. As soon as a backup run has an off-server\ndestination selected, the plugin leaves these files out of the archive it builds:<\/p>\n\n That is deliberate. Nothing a restore needs is lost. Restoring happens inside a working WordPress that already has\nits own Your backup archives, which contain your files (minus the configuration files listed above)\nand your whole database. The full list is in the \"External Services\" section above. No\ntelemetry or usage statistics are ever sent.<\/p><\/dd>\n Per table, yes. Across the whole database, no \u2014 the dump runs across many requests, so rows\nwritten between two tables being dumped are captured at different moments. This is a real\nlimitation of any backup that runs inside PHP without shell access.<\/p><\/dd>\n Yes \u2014 that is what it is built for. The backup runs in small steps instead of one long\nrequest, so a short PHP time limit or low memory limit slows it down rather than breaking it,\nand a killed step is simply resumed on the next one.<\/p><\/dd>\n Not yet.<\/p><\/dd>\n\n<\/dl>\n\n\n\n
mysqldump<\/code>, no shell access needed.<\/li>\nwp-config.php<\/code> is never included in an archive that is uploaded to a cloud destination,\nso your WordPress authentication keys, salts and database credentials stay on your own server.\nSee \"External Services\" and the FAQ below for exactly what is sent and when.<\/p>\n\n\n
mysqldump<\/code>-capable host: small business sites, agencies managing client sites on\nbudget hosting, and anyone planning to migrate a WordPress site and wanting a verified,\nrestorable copy of it first.<\/p>\n\nExternal Services<\/h3>\n\n
\n
admin-ajax.php<\/code> to continue a running backup.<\/li>\n\n
wp-config.php<\/code> and the other site configuration files listed in the\nFAQ below are deliberately left out of any archive that goes to a cloud destination, so your\nWordPress authentication keys and salts are never uploaded.<\/li>\n\n
wp-content\/plugins\/backupyoursite<\/code> and activate it.<\/li>\n\n
Where are my backups stored?<\/h3><\/dt>\n
wp-content\/uploads\/backupyoursite\/archives\/<\/code>. Each backup gets its own folder with a\nrandom name, and the folder is protected by an index.php<\/code> stub, an .htaccess<\/code> rule and a\n web.config rule. The plugin also tests, over HTTP, whether those rules actually work on\nyour server, and warns you loudly if they do not.<\/p><\/dd>\nHow do I restore a WordPress backup?<\/h3><\/dt>\n
Can I use this plugin to migrate a WordPress site?<\/h3><\/dt>\n
My site gets very little traffic. Will the backup still run?<\/h3><\/dt>\n
Can it restore my site if it is completely broken?<\/h3><\/dt>\n
Do I need a BackupYourSite account?<\/h3><\/dt>\n
Is wp-config.php included in my backups?<\/h3><\/dt>\n
\n
wp-config.php<\/code><\/li>\nwp-config-*.php<\/code> variant your host or staging setup uses (except the core\n wp-config-sample.php, which holds only placeholders)<\/li>\nwp-salt.php<\/code> and wp-salts.php<\/code><\/li>\n.env<\/code><\/li>\n<\/ul>\n\nwp-config.php<\/code> holds your WordPress authentication keys and salts, which\nsign this site's login cookies and nonces, plus your database credentials \u2014 and none of that\nshould be sitting on somebody else's storage. One archive is built per run and sent to every\ndestination you selected, so the exclusion applies to the whole run as soon as any destination\nis off-server. A backup run with only \"This server\" selected still includes these files,\nbecause nothing leaves your server.<\/p>\n\nwp-config.php<\/code>, which the plugin never overwrites. A site being rebuilt from nothing\ngets a fresh wp-config.php<\/code> with fresh salts from the WordPress installer, which is the safer\noutcome anyway \u2014 reusing the salts of a site you have just lost would keep every old session\nsignable.<\/p><\/dd>\nWhat is sent to backupyoursite.com if I do connect an account?<\/h3><\/dt>\n
Is the database dump consistent?<\/h3><\/dt>\n
Does this plugin work on cheap or limited hosting?<\/h3><\/dt>\n
Does this support WordPress multisite?<\/h3><\/dt>\n
1.1.1<\/h4>\n\n
\n
wp-config.php<\/code> is no longer included in a backup archive that leaves your server.\nIt holds your WordPress authentication keys and salts and your database credentials, and\nuploading it put those on storage you do not control. wp-config-*.php<\/code> variants,\n wp-salt.php, wp-salts.php<\/code> and .env<\/code> are excluded in the same way. Backups that stay on\nyour own server are unchanged. See the FAQ for why nothing a restore needs is lost.<\/li>\nbysbackup<\/code> \u2014 its options, database\ntables, scheduled task, hooks and admin page addresses. Your settings, schedule, backup\nhistory, stored backups and cloud connection are carried over automatically on the first\nload after the update; there is nothing to reconnect and nothing to set up again.<\/li>\n1.0.9<\/h4>\n\n
\n
1.0.8<\/h4>\n\n
\n
1.0.7<\/h4>\n\n
\n
1.0.6<\/h4>\n\n
\n
.htaccess<\/code> \u2014 nginx, and Apache with\n AllowOverride None \u2014 rewriting those files could never have worked, so the plugin used\nto print the warning and leave the archives sitting at a URL that answered 200 until\nsomeone read it, edited wp-config.php over SFTP, or opened a support ticket. It now works\nthrough the remedies itself and re-tests after each one: it makes the archives readable\nonly by your own account (decisive wherever the web server is a different user from PHP,\nwhich is the usual layout on exactly those hosts), and failing that it moves your backups\nout of the website folder altogether, where no web address can reach them.<\/li>\n1.0.5<\/h4>\n\n
\n
1.0.4<\/h4>\n\n
\n
.htaccess<\/code>, web.config<\/code>, index.php<\/code>) were only written when absent,\nso a file that existed but was empty or half-written \u2014 a truncating \"cleanup\" plugin, an\ninterrupted write, a host migration that copied names but not contents \u2014 passed the\ncheck while denying nothing. The folder was then open, and because the file existed it\nwas never repaired: the \"your backups are publicly downloadable\" warning fired forever\nand told the user to contact their host about something the plugin could fix itself.\nProtection is now verified by content, not by existence, and repaired automatically on\nevery backup run. A partial write is deleted rather than left in place.<\/li>\n.htaccess<\/code> (usual on nginx), versus protection\nfiles the plugin could not write. Both now point at the BYSBACKUP_BACKUP_DIR<\/code> constant, which\nmoves backups outside the website entirely.<\/li>\n1.0.3<\/h4>\n\n
\n
fwrite()<\/code> return values were unchecked at four\nchunked-copy sites (split-file reassembly and zip-entry extraction during restore, and\nthe staged-file-list writer). A disk-full or short write mid-copy could silently produce\na truncated file that the restore then treated as successful. All four now check the\nreturn value and fail the restore loudly (with a clear \"disk full or write error\"\nmessage) instead of continuing with a corrupt result.<\/li>\n\/\/ phpcs:ignore<\/code> comments and a further ~30 category-only \/\nunreasoned ones (\/\/ phpcs:ignore WordPress.DB<\/code>, WordPress.Security.NonceVerification<\/code>,\n Generic.CodeAnalysis.EmptyStatement) with specific sniff names and reviewed\njustifications, or removed them where nothing was actually being suppressed. A bare\nignore silences every sniff on that line, so these lines were never actually examined by\nthe previous Plugin Check pass; each was independently re-verified with the ignore\nstripped. No other real issue surfaced besides the fwrite bug above.<\/li>\n1.0.2<\/h4>\n\n
\n
1.0.1<\/h4>\n\n
\n
1.0.0<\/h4>\n\n
\n