BackupYourSite
| 开发者 | backupyoursite |
|---|---|
| 更新时间 | 2026年10月4日 16:23 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
BackupYourSite is a WordPress backup plugin that backs up your files and database on a
schedule, stores the archives on your own server, and restores them again from the WordPress
admin in one click. An optional cloud destination adds a verified offsite copy when you want
one — everything else works with no account at all.
It is built for cheap, limited hosting. The backup runs in small steps rather than one long
request, so a short PHP time limit or a small memory limit slows it down instead of breaking
it. If a step is killed, the next one carries on from where it stopped.
Core backup features
- Daily, weekly or manual scheduled backups of files and database.
- A real database dump written by PHP — no
mysqldump, no shell access needed. - Archives split into size-limited zip volumes so nothing has to be handled in one piece.
- Incremental backups measured against the last full backup, so restoring never needs more than two backups.
- Every backup is verified before it counts: the archives are integrity-checked, the database dump must end with its completion marker, and every file the plugin promised to archive must actually be in the archive. A backup that does not pass is marked incomplete, and old backups are never deleted after a run that was not clean.
- One-click restore of files, database, or both — with a snapshot of the current site taken first.
- One retention setting: delete backups older than N days. The most recent working backup is never deleted, and nothing is ever deleted after a backup that did not finish cleanly.
- Failure emails if a scheduled backup does not complete.
wp-config.php is never included in an archive that is uploaded to a cloud destination,
so your WordPress authentication keys, salts and database credentials stay on your own server.
See "External Services" and the FAQ below for exactly what is sent and when.
What it does not do
- It cannot restore a site that no longer runs. This plugin lives inside WordPress; if WordPress cannot start — a white screen, a fatal error, a database connection error, a suspended account — the plugin cannot start either. For that case, download the archive from the Backups screen and restore it through your hosting control panel.
- Backups stored on this server share this server's fate. They protect you from mistakes, bad updates and corruption. They do not protect you from losing the server.
- Multisite is not supported yet.
mysqldump-capable host: small business sites, agencies managing client sites on
budget hosting, and anyone planning to migrate a WordPress site and wanting a verified,
restorable copy of it first.
安装:
- Upload the plugin to
wp-content/plugins/backupyoursiteand activate it. - Open BackupYourSite in the admin menu and press Back up now.
- Check the Are your backups reachable from the web? result on that screen. If it says yes, fix it before relying on the plugin — the archives contain your whole database.
屏幕截图:
常见问题:
Where are my backups stored?
In wp-content/uploads/backupyoursite/archives/. Each backup gets its own folder with a
random name, and the folder is protected by an index.php stub, an .htaccess rule and a
web.config rule. The plugin also tests, over HTTP, whether those rules actually work on
your server, and warns you loudly if they do not.
How do I restore a WordPress backup?
Open BackupYourSite → Restore, pick the backup to restore from, choose files, database, or both, and confirm. The plugin takes a snapshot of the current site first, then restores in small steps and reports progress as it works.
Can I use this plugin to migrate a WordPress site?
Take a backup on the old site, download or transfer the archive, install BackupYourSite on the new site, and restore it there. The database dump and file archive are both verified before they count as a usable backup, so a migration starts from a backup you know is intact.
My site gets very little traffic. Will the backup still run?
WordPress's built-in scheduler only runs when someone visits the site, so it may not. The Settings screen shows a cron line you can paste into your hosting control panel to fix that.
Can it restore my site if it is completely broken?
No. See "What it does not do" above. Download the archive and restore it through your host.
Do I need a BackupYourSite account?
No. Everything the plugin does — scheduled backups, incremental backups, verification, retention, restore — works with no account and with no connection to us. An account only adds the optional offsite cloud destination. Until you connect one, the plugin makes no request to any external service at all.
Is wp-config.php included in my backups?
Not in any backup that leaves your server. As soon as a backup run has an off-server destination selected, the plugin leaves these files out of the archive it builds:
wp-config.php- any
wp-config-*.phpvariant your host or staging setup uses (except the corewp-config-sample.php, which holds only placeholders) wp-salt.phpandwp-salts.php.env
wp-config.php holds your WordPress authentication keys and salts, which
sign this site's login cookies and nonces, plus your database credentials — and none of that
should be sitting on somebody else's storage. One archive is built per run and sent to every
destination you selected, so the exclusion applies to the whole run as soon as any destination
is off-server. A backup run with only "This server" selected still includes these files,
because nothing leaves your server.
Nothing a restore needs is lost. Restoring happens inside a working WordPress that already has
its own wp-config.php, which the plugin never overwrites. A site being rebuilt from nothing
gets a fresh wp-config.php with fresh salts from the WordPress installer, which is the safer
outcome anyway — reusing the salts of a site you have just lost would keep every old session
signable.
What is sent to backupyoursite.com if I do connect an account?
Your backup archives, which contain your files (minus the configuration files listed above) and your whole database. The full list is in the "External Services" section above. No telemetry or usage statistics are ever sent.
Is the database dump consistent?
Per table, yes. Across the whole database, no — the dump runs across many requests, so rows written between two tables being dumped are captured at different moments. This is a real limitation of any backup that runs inside PHP without shell access.
Does this plugin work on cheap or limited hosting?
Yes — that is what it is built for. The backup runs in small steps instead of one long request, so a short PHP time limit or low memory limit slows it down rather than breaking it, and a killed step is simply resumed on the next one.
Does this support WordPress multisite?
Not yet.
更新日志:
1.1.1
- Security:
wp-config.phpis no longer included in a backup archive that leaves your server. It holds your WordPress authentication keys and salts and your database credentials, and uploading it put those on storage you do not control.wp-config-*.phpvariants,wp-salt.php,wp-salts.phpand.envare excluded in the same way. Backups that stay on your own server are unchanged. See the FAQ for why nothing a restore needs is lost. - Every internal name the plugin uses is now prefixed
bysbackup— its options, database tables, scheduled task, hooks and admin page addresses. Your settings, schedule, backup history, stored backups and cloud connection are carried over automatically on the first load after the update; there is nothing to reconnect and nothing to set up again. - Backups written by earlier versions stay restorable.
- Fixed: with both "This server" and "BackupYourSite cloud storage" ticked, a backup could be stored on the server only, with nothing at all going to the cloud — and still report "Backup complete". A single failed upload request (a dropped connection, a brief server error, one part rejected) made the plugin abandon the whole offsite copy for that backup, permanently, because the part-upload was never retried. It is now retried, and an upload interrupted for a reason that passes is resumed on the next pass instead of being thrown away.
- Fixed: a part that failed its checksum was skipped instead of being sent again, so the cloud copy could be finalised with a piece missing from it. Every part is now re-sent until the server confirms it.
- Fixed: destinations are now independent. A destination that fails no longer stops the others from being written to, and no longer fails the whole backup — if your backup folder cannot be written to, the cloud copy still happens, and the other way round. A backup only fails outright when nothing could be stored anywhere.
- Fixed: a backup that did not reach one of your chosen destinations is reported as such — on the Dashboard, on the Settings screen (per destination), in the log, and by email. It is no longer counted as a clean run, and old backups are no longer deleted on the strength of one. A destination that missed a backup is also correctly treated as not having it, so the next backup to it is a full one.
- Fixed: a destination you had ticked could be silently un-ticked by saving the Settings page while it happened to be unavailable (for example a cloud account mid-reconnect).
- Fixed: the Settings screen could show "The folder could not be created or is not writable." directly underneath the backup folder actually in use and working normally. That message is about a folder outside your website that could not be used, and now says so.
- Fixed: connecting cloud storage after you had already been backing up locally could put an incremental backup in the cloud with no full backup behind it — which is not restorable on its own. The plugin decided full-versus-incremental by looking only at your local backups, so a brand-new cloud destination inherited a baseline it did not have a copy of. Whether a full backup already exists is now asked of every destination a backup is being written to, separately; if any of them does not have one, that run takes a full backup. This also covers a cloud copy that was pruned, deleted, or never finished uploading.
- If you are affected, the next scheduled or manual backup after this update takes a full backup by itself — no action needed. Any incremental already sitting in the cloud without a full behind it is now labelled "No full backup behind it" under Stored backups, so it is not mistaken for a working backup.
- New installs now take a fresh full backup every 25 backups instead of every 7. On a daily schedule that is one full a month rather than one a week, so far less is re-uploaded and re-stored for the same protection — each incremental is still measured against the last full, so a restore still needs only two backups. Sites that have already saved their settings keep whatever number they chose; change it under Incremental backups.
- The "your backup files are publicly downloadable" warning now fixes itself instead of
asking you to. On servers that ignore
.htaccess— nginx, and Apache withAllowOverride None— rewriting those files could never have worked, so the plugin used to print the warning and leave the archives sitting at a URL that answered 200 until someone read it, edited wp-config.php over SFTP, or opened a support ticket. It now works through the remedies itself and re-tests after each one: it makes the archives readable only by your own account (decisive wherever the web server is a different user from PHP, which is the usual layout on exactly those hosts), and failing that it moves your backups out of the website folder altogether, where no web address can reach them. - New button, "Move my backups out of the website" — one click, on any host where PHP may write above your website root. It moves what is already stored and remembers the new location itself, so BYSBACKUP_BACKUP_DIR in wp-config.php is no longer needed for this. The constant still works and still wins, as the escape hatch for layouts nothing can infer.
- Two candidate folders outside the website are now tried instead of one, so panels that place the account home directory an extra level above the web root are handled.
- Where a host allows none of the above — it serves the folder, ignores every rule, runs the web server as the PHP user, and confines PHP to the website — the storage folder is renamed to carry 32 random characters, on top of the 16 every backup set already carries. The dashboard says plainly that this is an unguessable address and not protection, rather than reporting the problem as fixed.
- Archives are clamped to owner-only as each one lands, not on a later sweep.
- Fixed: the warning led with "add a BYSBACKUP_BACKUP_DIR constant to wp-config.php" even on the many sites where a button could do it. It now names the button, and only falls back to naming your host when this server genuinely permits nothing else.
- Fixed the "your backup files are publicly downloadable" warning staying on screen after 1.0.4 had already repaired the folder. 1.0.4 rewrote the protection files during the upgrade but never re-tested them, so the warning from before the repair was what you kept reading. The upgrade now re-tests, and an install that already upgraded re-tests itself once.
- When the stored result carries no recorded cause, the warning no longer claims your server ignores .htaccess. That advice was shown on servers that honour it perfectly well.
- Fixed a security bug that could leave the backup folder publicly downloadable. The
protection files (
.htaccess,web.config,index.php) were only written when absent, so a file that existed but was empty or half-written — a truncating "cleanup" plugin, an interrupted write, a host migration that copied names but not contents — passed the check while denying nothing. The folder was then open, and because the file existed it was never repaired: the "your backups are publicly downloadable" warning fired forever and told the user to contact their host about something the plugin could fix itself. Protection is now verified by content, not by existence, and repaired automatically on every backup run. A partial write is deleted rather than left in place. - The exposure self-test now rewrites and re-verifies the deny rules and retests before reporting anything, so a repairable folder is simply repaired and never warned about. Only an exposure that survives a verified repair is reported.
- The exposure warning and email now distinguish the two real causes and give the right
advice for each: a server that ignores
.htaccess(usual on nginx), versus protection files the plugin could not write. Both now point at theBYSBACKUP_BACKUP_DIRconstant, which moves backups outside the website entirely. - Every backup run now re-verifies the deny rules across the whole storage folder, including the folders of backups taken earlier. Previously a run only guarded the folders it created itself, so a set from an earlier run whose protection had since been damaged stayed that way — and it holds the same wp-config.php and database as a fresh one. Activating or updating the plugin repairs the whole tree too.
- The storage folder is now guarded at the moment it is created, closing the short window between creating it and protecting it on first activation.
- Fixed a real data-integrity bug:
fwrite()return values were unchecked at four chunked-copy sites (split-file reassembly and zip-entry extraction during restore, and the staged-file-list writer). A disk-full or short write mid-copy could silently produce a truncated file that the restore then treated as successful. All four now check the return value and fail the restore loudly (with a clear "disk full or write error" message) instead of continuing with a corrupt result. - Replaced 62 bare
// phpcs:ignorecomments and a further ~30 category-only / unreasoned ones (// phpcs:ignore WordPress.DB,WordPress.Security.NonceVerification,Generic.CodeAnalysis.EmptyStatement) with specific sniff names and reviewed justifications, or removed them where nothing was actually being suppressed. A bare ignore silences every sniff on that line, so these lines were never actually examined by the previous Plugin Check pass; each was independently re-verified with the ignore stripped. No other real issue surfaced besides the fwrite bug above. - No other functional/behavioural change to backup or restore.
- WordPress Plugin Check compliance pass: fixed a missing translators comment, removed the now-redundant load_plugin_textdomain() call (translations for WordPress.org-hosted plugins load automatically since WP 4.6) and the stale Domain Path header, and added scoped, reviewed justification comments (with matching notes in this readme's reviewer section) for the direct file-streaming calls a backup/restore engine needs and the table-identifier SQL that $wpdb->prepare() cannot parameterize. No functional/behavioural change to backup or restore.
- Cloud upload and restore now run against the live BackupYourSite backend, not a contract mock.
- Fixed a cloud-restore bug where an already-downloaded volume was fetched again on every step; downloaded volumes are now cached and their size verified before use.
- A failed restore now reports the real reason instead of a generic failure message.
- Restore now reports step-by-step progress in the admin while it runs.
- First release: scheduled backups, incremental backups, verification, local storage with exposure self-check, retention, restore with pre-restore snapshot.