BTFU — Back The Files Up
| 开发者 | jkirker |
|---|---|
| 更新时间 | 2026年11月8日 23:35 |
| PHP版本: | 8.2 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
详情介绍:
- One click, one note. "before checkout refactor" — attached to the exact state it describes.
- Hardlinked snapshots. The second snapshot costs only what changed. Twenty snapshots of a 2 GB site is nowhere near 40 GB.
- Honest sizes. Every snapshot shows its unique size — the bytes you actually get back by deleting it — because with shared storage, apparent size is a lie.
- Every restore is undoable. An automatic safety snapshot is taken before any restore. Rolling back can itself be rolled back.
- A standalone rescue script. Restores the site from the command line — or, password-gated, the browser — even when WordPress is a white screen. It is the same code path as normal restores, so it can never quietly rot.
- Exclude what you don't need. File patterns (rsync-style, plus a
.btfuignorefile) and database tables (structure-only, with core tables locked out — see FAQ). - WP-CLI.
wp btfu snap "note",list,restore,verify,prune,doctor,selftest.
- Multisite (refuses to activate — a half-captured network is worse than none)
- Move snapshots between sites/domains (serialized-data search-replace is out of scope)
- Scheduled backups, offsite storage — this is a checkpoint tool, not a backup product
安装:
- First, make sure you have an independent, off-server backup. BTFU is destructive and its snapshots live on the same disk as the site.
- Upload the plugin and activate it.
- Click BTFU in the admin bar → Back it up now…
- Optional but recommended: visit BTFU → Settings, set a rescue password, and generate a rescue script. Save its URL somewhere outside this site.
屏幕截图:
常见问题:
Where do snapshots live?
In a .btfu-store-<random> directory — outside the web root when possible, otherwise inside wp-content guarded by .htaccess/web.config and verified by an actual HTTP canary check (nginx ignores .htaccess, so we prove protection instead of assuming it).
Why can't I exclude wp_posts from the database?
Core tables cross-reference each other by ID. Restoring posts without postmeta produces silent corruption, not a smaller backup. Non-core tables (analytics, logs, queues) can be excluded — they are stored structure-only, restore leaves their live data untouched, and strict-mode restores will never drop them.
What happens if a restore goes wrong?
A safety snapshot is taken automatically before every restore, so you can roll back the rollback. If WordPress itself won't load, the rescue script restores from the CLI: php btfu-rescue-xxxx.php --list then --restore <id>.
Does deleting a snapshot free its full size?
No — and the UI never claims it does. Snapshots share unchanged files via hardlinks. Each snapshot's listed "unique" size is what deleting it actually reclaims.
My host's server backup fails with a "hard link" error. Is that BTFU?
Probably. Snapshots save space by hardlinking unchanged files to the previous snapshot, and some server-level backups — DirectAdmin's hard-link check in particular, and some cPanel and JetBackup setups — abort an account's backup when they find hard links in its home directory.
The fix is to exclude the snapshot store from the server backup; same-server checkpoints don't belong in an off-server backup anyway. BTFU → Settings (and wp btfu doctor) shows the exact directory to exclude when your store sits inside a home directory. On DirectAdmin, add that path, relative to your home directory, as a line in ~/.backup_exclude_paths; if backups still abort, the server admin can turn off DirectAdmin's backup_hard_link_check. The store also carries a CACHEDIR.TAG, which borg, restic and other tools honor automatically.
If you can't exclude it, BTFU → Settings → Storage can store every snapshot as a full copy with no hardlinks. That costs much more disk (every snapshot is a complete copy), makes the server backup larger, and does not convert existing snapshots — delete those afterwards.
Is it safe on a live site?
It's designed for development. It will run in production, but it warns you persistently, and you should listen to it.
Do I still need real backups?
Yes. BTFU snapshots live on the same server as the site — they protect you from your own changes, not from disk failure, a compromised server, or a hosting disaster. Keep your normal off-server backups, and have one before your first restore.
更新日志:
- Server-backup compatibility: when the snapshot store sits inside a home directory, Settings and
wp btfu doctor/selftestnow say exactly which directory to exclude from server-level backups (DirectAdmin, cPanel, JetBackup) that abort on hard links. - The snapshot store now carries a
CACHEDIR.TAG, so borg, restic, rsnapshot andtar --exclude-cachesskip it automatically. Existing stores get it on update. - New opt-in setting (Settings → Storage): store snapshots as full copies with no hardlinks, for hosts whose backups can't exclude the store. Off by default, and its disk cost is spelled out next to the switch.
- Readme: "Tested up to" uses major.minor (7.1), as WordPress.org requires.
- Confirmed compatible with WordPress 7.1.3. No functional changes.
- First-run setup wizard: walks you through the risk, an environment check, your first baseline snapshot, and optional auto-snapshots. Re-runnable from BTFU → Setup.
- Automatic snapshots before plugin/theme/core updates (opt-in, off by default) — the moment you most wish you had a checkpoint. Bounded by their own retention rule.
- Compare page: pick two snapshots and see file adds/modifications/deletions and per-table database row changes — with a one-click "restore from A" on any changed path. (Also
wp btfu diff.) - Diff: see exactly what changed between two snapshots — files (added/modified/deleted) and database (per-table row deltas).
wp btfu diff <a> <b> [--files]. - Selective restore: files only, database only, both, or a single file/folder (WP-CLI
--skip-files/--skip-db/--only=<path>, the admin-bar dialog for files/database, and the rescue script).
- Now requires PHP 8.2+ (PHP 7.4–8.1 are end-of-life; BTFU will not support EOL PHP).
- Restore dialog: explicit overwrite warning, and a prominent alert when restoring without a safety snapshot.
- Clearer guidance everywhere to keep an independent, off-server backup.
- New:
wp btfu selftest— one-command end-to-end health check (snapshot → verify → delete round-trip), exits non-zero on failure. - Hardening: a single store-wide operation lock now prevents a snapshot, restore, prune, import, or delete from running while another is in progress (it self-heals if a process crashes).
wp btfu doctorreports any operation in progress. - Directory listing icon, banner, and screenshots.
- Initial release: snapshots (rsync/PHP engines), restores (single shared engine with standalone rescue script), hardlinked storage, admin bar UI with notes and size pills, file + database excludes, retention/pruning with pinning, WP-CLI commands, production guards.