一键避险：WordPress初始备份与恢复方案完整操作手册

备份这件事最危险的状态，叫「我以为我有备份」。文件夹里躺着一个 800M 的压缩包，从来没打开过，也从没恢复过——真出事那天才发现它要么不完整，要么根本解不开。

所以下面不按「怎么备份」讲，按怎么保证能恢复讲。先定目标，再定手段，最后一定要演练一次。

一、先定两个指标：RPO 和 RTO

这两个词听起来专业，其实很好理解：

• RPO（能丢多少数据）：如果每小时备份一次，最坏情况丢一小时的内容。
• RTO（多久能恢复）：从发现故障到站点重新可访问，需要多长时间。

个人博客 RPO 一天、RTO 两小时通常可以接受；有交易或会员数据的站点，RPO 应该压到分钟级。先把这两个数写下来，再决定备份频率和存储方式——没有目标的备份，都只是心理安慰。

二、三层备份，各管一种故障

层级	备份什么	能救什么
数据库	文章、评论、设置、用户	误删文章、插件改坏数据、升级失败
站点文件	wp-content、主题、插件、上传	文件被改、被挂马、误删主题
服务器快照	整机磁盘状态	系统崩溃、内核升级失败、勒索加密

三层不是替代关系。只做数据库备份，主题被改坏时救不回来；只做快照，误删一篇文章要回滚整个系统，代价太大。

三、手动备份：两条命令就够

cd /www/wwwroot/你的站点

# 1. 数据库（用 wp-cli，自动处理字符集）
wp db export /root/backups/db-$(date +%Y%m%d-%H%M).sql --add-drop-table

# 2. 站点文件（排除缓存和备份目录，避免越备越大）
tar czf /root/backups/site-$(date +%Y%m%d-%H%M).tar.gz 
  --exclude='wp-content/cache' 
  --exclude='wp-content/upgrade' 
  --exclude='*.log' 
  wp-content wp-config.php .htaccess

为什么要排除缓存目录：缓存文件体积大、可再生，打进包里会让每个备份都膨胀几倍，还拖慢打包速度。

没有 wp-cli 的话，用 mysqldump 也一样，注意加上 --single-transaction 避免锁表：

mysqldump --single-transaction --quick 数据库名 > /root/backups/db.sql

四、自动备份：定时任务 + 异地

手动备份一定会忘。用 cron 每天跑一次，再写一条清理规则，只保留最近 7 天：

# crontab -e
30 4 * * * /root/backup.sh >> /root/backups/backup.log 2>&1

# /root/backup.sh
#!/bin/bash
D=$(date +%Y%m%d)
cd /www/wwwroot/你的站点
wp db export /root/backups/db-$D.sql
tar czf /root/backups/site-$D.tar.gz --exclude='wp-content/cache' wp-content
find /root/backups -name '*.sql' -mtime +7 -delete
find /root/backups -name '*.tar.gz' -mtime +7 -delete

关键一步：把备份传到另一台机器或对象存储。备份和站点在同一块磁盘上，磁盘一坏两个一起没。用 rclone、s3cmd 或简单的 scp 都行，成本很低。

五、恢复演练：这一步不能省

恢复流程必须在一个不影响正式站的地方跑一遍，比如本地环境或临时目录：

1. 新建一个空数据库，导入 sql 文件
2. 解压站点文件到一个临时目录
3. 改 wp-config.php 指向新库，改站点地址为临时域名
4. 访问首页和一篇内页，确认内容和图片都在
5. 登录后台，确认用户和插件正常
6. 记录整个过程的耗时——这就是你真实的 RTO

正式恢复时，顺序反过来更容易控制：先停站（或进入维护模式）、再导库、再覆盖文件、最后清缓存验证。中途不要把「导库」和「覆盖文件」并行做，出问题无法判断是哪一步错的。

六、备份失败的五种常见原因

现象	原因	处理
sql 文件只有几 KB	导出时权限或库名错误	检查 wp-config 里的库名与用户
压缩包解压报错	打包时磁盘已满	df -h 确认空间，重新打包
恢复后白屏	文件属主不对	chown -R www:www 站点目录
恢复后跳回旧域名	库里的 siteurl 未更新	改 wp_options 两张表或 wp-config 覆盖
定时任务没跑	脚本无执行权限 / PHP 路径错	chmod +x，cron 里用绝对路径

七、上线检查清单

1. 备份文件不在站点目录内（否则可能被直接下载）
2. 每天自动备份，保留至少 7 天
3. 至少一份在异地或对象存储
4. 备份脚本有日志，能看出是否成功
5. 每季度做一次恢复演练，记录耗时
6. 数据库和文件分开备份，便于单独回滚

常见问题

用插件自动备份够不够？

作为第一层是够的，但存在两个隐患：插件本身出问题时备份也会停，且很多插件的备份文件存在站点目录内。建议插件 + 命令行各做一份，并至少一份放到站外。

备份文件存在服务器上安全吗？

不够。磁盘故障、勒索加密、误删目录都会让备份一起消失。而且放在 web 可访问目录下的备份文件可能被直接下载，务必放到站点根目录之外并做好权限。

快照能代替备份吗？

不能。快照恢复的是整机状态，粒度太粗，误删一篇文章也要回滚整个系统；而且快照通常和磁盘在同一区域，遇到区域性故障同样不可用。两者是互补关系。

数据库导出多大算正常？

没有绝对标准，但和内容量要匹配。一个 600 篇文章的站，sql 文件在几十 MB 量级。如果只有几 KB，基本可以确定是导出失败了。

恢复后图片不显示怎么办？

先确认 wp-content/uploads 是否完整解压、属主是否为运行用户，再检查是否开了图片懒加载或 CDN 回源。数据库里记录的图片地址一般不用改，除非换了域名。

小结

一句话总结：备份的验收标准不是”生成成功”，而是”恢复成功”。在没出事的某一天花一小时演练一次，比出事那天熬通宵强得多。

相关阅读：宝塔部署 WordPress 常见错误、VPS 租用与部署上线、如何防止服务器被爆破登录。