站点做久了，最怕的不是流量下滑，而是一次误操作之后才发现备份根本用不了。备份本身不难，难的是把范围想全、把恢复路径真正走通。下面这份清单偏实务，按做一次完整备份和一次恢复演练的顺序来梳理。
先列清楚要备份哪些东西
很多人对备份的理解就是导一份数据库，真出事的时候才发现图片、主题、插件配置都不见了。
- 数据库：文章、页面、评论、用户、选项表。导出时留意字符集，避免恢复后中文乱码。
- 上传目录：图片、附件、用户上传的文件，体量往往比数据库还大。
- 主题与插件：尤其是自己改过代码的部分，插件市场不一定还能找到同一个版本。
- 配置文件：数据库连接信息、伪静态规则、环境变量文件。
- 证书与密钥：HTTPS 证书私钥、第三方接口密钥，丢了重新申请很麻烦。
- 服务器侧配置：定时任务、站点配置、防火墙规则、DNS 解析记录。
建议把这份清单写成文档放在仓库里，每次新增服务就补一行，别靠记忆。
频率和保留策略怎么定
没有统一标准，按更新节奏来定比较实际：
- 每天更新内容的站点：每日增量备份加每周一次全量。
- 更新很少的企业站：每周全量基本够用。
- 保留上，7 份日备、4 份周备、12 份月备是常见组合。
存放方式可以遵循 3-2-1 思路：至少三份副本、两种不同介质、一份放在异地。只把备份文件留在同一台服务器上，遇到磁盘故障或误删就一起没了。
备份文件不要放在网站目录里
这是很常见的问题。备份文件被顺手放在网站根目录，命名又比较好猜，等于给扫站工具留了一个下载入口。
备份目录要么放在 web 根目录之外，要么用服务器规则明确禁止访问，并且定期验证拦截是否真的生效。
上传到对象存储时，建议开启版本管理并把访问权限设为私有。备份包里通常含有数据库导出，一旦泄露，风险比丢数据更大。
恢复演练比备份本身更重要
很多人只确认了备份任务没有报错，却从没验证过能不能恢复。建议每季度做一次演练：
- 在测试环境或临时域名上恢复一份最近的备份。
- 检查首页、文章页、栏目页能否正常打开，图片是否显示。
- 登录后台，发布一篇测试文章，确认写入正常。
- 记录整个恢复过程耗时，评估是否在可接受范围内。
- 演练结束后删除临时环境，避免留下可被访问的副本。
恢复完成后的收尾检查
恢复不是把文件拷回去就结束了，跨域名或跨环境恢复时尤其要注意：
- 确认站点地址、canonical、sitemap 里的域名指向当前正式域名，而不是备份时的旧域名或测试域名。
- 检查 robots.txt 是否是从测试环境带过来的，避免里面留着屏蔽全站的规则。
- 翻一下服务器日志，看恢复后有没有出现大量 404，及时补上重定向或修正链接。
- 重新提交一次 sitemap，让蜘蛛按新的状态重新抓取。
几个常见的坑
- 备份任务失败没人知道：设置告警，连续两次失败就该有人处理。
- 备份把磁盘塞满：保留策略要配合磁盘监控，数据量大的站点尤其要注意。
- 只测了压缩包能不能解开：能解压不代表数据库能导入、站点能跑起来。
- 恢复后忘记改回配置：调试模式、缓存开关、临时关闭的抓取规则，都记得恢复原状。
备份和恢复是站点运营里最不出成绩的一环，平时看不出价值，出事那天就是全部价值。花一个下午把流程走通，比事后补救便宜得多。