UpdraftPlus免费版能把你的网站文件和数据库定时打包丢到Google Drive上，但免费版只做全量备份不做增量，一个100MB的站每天备份一次，Google Drive的15GB免费空间不到半年就满了。Jetpack Backup $9.95/月的方案可以实时增量只传改动的部分，但只保留30天存档，想回溯三个月前的版本得掏$49.95/月。自建方案rclone+BorgBackup一分钱不花，去重压缩后每天增量只增加几十KB，但坏处是你得自己写脚本、自己配告警、自己每月做恢复演练。备份这件事，免费的、省事的、安全的，从来都只能选两样
备份工具选错的结果只有一种：出事那天你发现备份文件是坏的、不全的、或者根本没有。HTMLPAGE团队统计过一个数据：超过一半的网站备份在真正需要恢复时才发现有问题——要么只备份了页面没备份图片，要么数据库dump是空的，要么备份文件存在被黑的那台服务器上一起被删了。这篇文章把WordPress插件、服务器命令行工具、异地存储三个环节串在一起，告诉你怎么搭一套出事那天真能恢复的备份体系。
备份不算数，恢复才算数
备份的价值不在它存在，而在它被验证过。没有恢复演练的备份，本质上是一个未经测试的承诺。你的备份体系是否可靠，看五个信号：①有没有在隔离环境完整恢复过一次？②备份包含哪些内容、不包含哪些内容，有人能说清楚吗？③图片、数据库、配置文件是打包在一起还是散落在不同系统？④恢复步骤有没有文档？⑤如果负责备份的那个人离职了，别人能不能操作？只要有一条答不上来，你的备份就是纸面上的安全。
一、备份到底备什么？拆开看是四个独立的东西
很多人以为"备份网站"就是把整个目录打个包。但网站实际由四层独立的数据组成，它们的备份频率和方式完全不同：
大多数"备份翻车"的根因，是只备了网站文件，忘了数据库、服务器配置和外部依赖这三层。一个典型的翻车案例：某团队网站被误操作覆盖，后台每天生成备份，但备份只包含页面结构不包含上传图片，表单线索存在第三方工具里没进同一份备份，最终恢复了一半，图片和线索数据需人工补救。
二、WordPress备份插件：七个里面挑三个，剩下四个各有各的短板
主力推荐：这三款覆盖了绝大多数场景
⚠️ UpdraftPlus免费版的最大限制：只做全量备份，不做增量。一个100MB的WordPress站每天全量备份一次，一天100MB，一个月3GB，Google Drive免费15GB五个月就满。解决方式：要么花$70/年买付费版开增量备份，要么保留策略设为只保留最近7天（设置→保留计划→7），要么走后面讲的自建方案。
剩下四款，各有各的硬伤
一句话选型：中小站用UpdraftPlus免费版够用、电商站直接上Jetpack实时备份、代理公司管多站点用BlogVault（独立服务器备份不拖慢任何一个客户站）。
三、服务器命令行方案：rsync、BorgBackup、Restic三条路线
WordPress插件解决的是"在WordPress后台点几下就能备份"的问题。但如果你管的是非WordPress站点、或者嫌插件拖慢服务器、或者需要更灵活的备份策略，就得走命令行路线。三条路线在去重、压缩、加密、云推送四个维度上的差异如下：
方案A：rsync + rclone，最简单也最容易被忽略安全细节
rsync负责本地文件同步到备份目录，rclone负责把备份目录推送到云存储。一条典型的备份脚本长这样：
#!/bin/bashset -eDATE=$(date +%F-%H%M)BACKUP_DIR=/tmp/backup_$DATEmkdir -p $BACKUP_DIR# 1. 导出MySQL所有数据库mysqldump --all-databases --single-transaction \-u backup -p'你的密码' > $BACKUP_DIR/mysql_all.sql# 2. 打包网站文件tar -czf $BACKUP_DIR/www.tar.gz /var/www# 3. rclone推送到S3（通过crypt加密层）rclone copy $BACKUP_DIR backup_enc:daily/$DATE \--transfers=4 --checkers=8 \--bwlimit "08:00,2M 22:00,off" \--log-file=/var/log/rclone-backup.log# 4. 删除云端30天前的旧备份rclone delete backup_enc:daily --min-age 30d# 5. 清理本地临时文件rm -rf $BACKUP_DIRecho "Backup done: $DATE" >> /var/log/rclone-backup.log
配好crontab每天凌晨3点跑：0 3 * * * /usr/local/bin/backup-daily.sh。这套方案最大的优势是免费、可控、存储成本极低（S3兼容对象存储如Backblaze B2每GB每月不到$0.006），劣势是出问题需要你自己排查日志。
⚠️ rsync最容易翻车的地方：--delete参数会删除目标目录中源端已经不存在的文件。如果源目录路径写错了（比如把/data/写成了/），目标备份会被清空。安全做法：先用--dry-run预览变更，确认无误再执行实际同步。另外，不要把备份文件和网站放在同一台服务器上——黑客拿到服务器权限后第一件事就是删备份。
方案B：BorgBackup，长期归档空间效率最高的方案
BorgBackup用块级去重+ZSTD压缩，一个每天变化的100MB WordPress站，用Borg备份365天后仓库总大小可能只有1.5-2GB（而rsync全量方案要36.5GB）。核心操作：
# 初始化Borg仓库borg init --encryption=repokey /backup/borg-repo# 创建备份borg create --stats --progress \--compression zstd,3 \/backup/borg-repo::'{hostname}-{now:%Y-%m-%d_%H:%M}' \/var/www /etc/nginx /etc/php# 查看备份列表borg list /backup/borg-repo# 恢复某个备份到/tmp/restoreborg extract /backup/borg-repo::myserver-2026-07-29_03:00# 清理策略：保留最近7天+4周+6个月borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 /backup/borg-repo
Borg的核心限制：单仓库只允许单机写入，多台服务器不能同时往同一个Borg仓库写备份（会损坏仓库）。多机场景要么每台机器单独建仓库，要么改用Restic。
方案C：Restic，多台服务器统一往同一个S3桶写
Restic最大的优势是原生支持S3/Backblaze/Azure/GCS等对象存储，不需要rclone中转。多台服务器可以同时往同一个仓库写备份（通过lock文件协调）。一条命令搞定：
# 初始化S3仓库restic -r s3:s3.amazonaws.com/你的桶名 init# 备份网站目录+数据库dumprestic -r s3:s3.amazonaws.com/你的桶名 \backup /var/www /backup/db_dump.sql \--exclude="node_modules" --exclude="*.log"# 保留策略：最近7天+4周+12月+2年restic forget --keep-daily 7 --keep-weekly 4 \--keep-monthly 12 --keep-yearly 2 --prune
三种方案不是互斥的，生产环境推荐组合：rsync做小时级本地副本 → Borg做天级长期归档 → Restic做异地云端冷存。对应3-2-1原则：3份数据（生产+本地备份+云端备份）、2种介质（磁盘+对象存储）、1份异地。
四、3-2-1原则和保留策略：多数人配错了保留天数
3-2-1原则说起来简单：3份副本、2种介质、1份异地。但落实到具体保留天数上，很多人配错：
本地保留：最近7天每天一份
应对误删、插件更新翻车等"今天才发现昨天出了问题"的场景。超过7天的一般不需要每天一份。
本地保留：最近4周每周一份
应对"某个问题可能一两周前就埋下了但才发现"的场景。每周日或每周一的那份保留即可。
异地保留：最近6-12个月每月一份
应对"半年后才发现被挂马""审计需要追溯历史版本"等场景。云存储便宜，多留几份成本不高。
异地保留：最近2年每年一份
长期合规或历史版本存档。每年1月1日那份保留，其他年份的可以删。成本几乎可忽略。
BorgBackup的一条命令就能实现这个保留策略：borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=6 --keep-yearly=2。Restic同理：restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 12 --keep-yearly 2 --prune。
五、恢复演练：备份体系里最被忽略却最重要的一步
超过一半的网站在真正需要恢复时才发现备份有问题。不是危言耸听——HTMLPAGE团队的实际案例：某团队网站每天生成备份，出事那天才发现备份只包含页面结构不包含上传图片，表单线索在第三方工具里完全没备份。
找一台干净的机器（或本地虚拟机）
不要在源站上做恢复演练。用VirtualBox/Docker或一台闲置VPS，完全隔离。
下载最近一次备份，完整恢复
数据库恢复→网站文件解压→配置Nginx→修改hosts指向测试域名→浏览器打开。
核对五类对象：页面+图片+表单数据+配置+权限
不只是看首页能不能打开。随机点5篇文章检查图片是否加载、登录后台看用户数据是否完整、检查插件配置是否保留。
记录恢复耗时和缺口，更新恢复文档
记录从下载到恢复完成花了多少分钟、缺了什么、哪一步卡住了。更新恢复SOP文档。目标是下次恢复时间缩短一半。
频率建议：每月至少一次。如果觉得太频繁，至少每季度一次。如果从来不做恢复演练，等于承认"备份只是心理安慰，出事那天靠运气"。
六、多站点批量备份：三个方案，按站点数量和技术能力选
七、五个容易被忽视的备份细节，出事那天才能发现
① mysqldump默认锁表，大站备份期间网站会卡住
mysqldump不带参数会锁全表，备份一个500MB的数据库期间整个网站不可写。必须加--single-transaction（InnoDB）或--skip-lock-tables（MyISAM）。InnoDB表用single-transaction可以做到备份期间网站正常运行。
② 备份文件存在网站目录里，等于没备份
UpdraftPlus默认把备份文件存在wp-content/updraft目录下——这个目录在网站目录里面。如果服务器硬盘挂了或被黑客删了网站目录，备份文件一起没了。必须配置远程存储：Google Drive、S3、Dropbox，至少一个。
③ 备份了数据库但不知道mysqldump的用户有没有足够权限
mysqldump需要至少SELECT和LOCK TABLES权限。如果用的用户权限不够，导出的.sql文件可能是空的或者缺表。备份脚本里加一步：if [ ! -s "$BACKUP_DIR/mysql_all.sql" ]; then echo "DB dump empty!"; exit 1; fi。文件大小为0直接报错退出。
④ rclone的sync和copy搞混了，sync会删文件
rclone copy：复制文件，不删除目标已有的。rclone sync：镜像同步，目标端有但源端没有的文件会被删除。备份场景应该用copy而不是sync。一旦用了sync，哪天本地清理了旧备份，云端对应文件也会被同步删除。
⑤ 备份脚本没有失败通知，出问题几个月都不知道
crontab跑了备份脚本但从来不检查日志。最简单方案：用healthchecks.io（免费），备份脚本成功时curl一下它的URL，超过设定时间没收到ping就自动发邮件/短信告警。或者脚本末尾加webhook通知到企业微信/钉钉。
八、四种典型场景的备份方案速查
备份这件事说到底不是技术问题，是习惯问题。技术方案再好，不验证恢复、不设告警、不异地存储，出事了照样抓瞎。把三件事养成肌肉记忆：备份完看一眼日志确认没报错、每月花15分钟在隔离环境做一次恢复演练、每季度核对一次保留策略看存储空间够不够。这三个习惯比任何工具都值钱。
