很多站点第一次真正关心备份，是在数据丢了以后。备份这件事的麻烦之处在于：配置一次很容易，验证它到底能不能用，却需要主动花时间。等到出事再发现备份是空的、解压失败、或者数据库导不进去，代价就大了。这篇把备份和恢复演练拆成一份自查清单，按顺序过一遍即可。
一、先明确到底要备份什么
只备份数据库是常见的疏漏。一个能完整还原的备份，通常包含下面几类内容：
- 程序文件与模板：主题、插件、自定义的静态资源，出了问题时能直接覆盖回去。
- 上传目录与媒体库：图片、附件、用户上传文件，这部分体积往往最大，也最容易被忽略。
- 数据库：文章、用户、评论、设置项，导出时记得带上建表语句。
- 配置文件：数据库连接、伪静态规则、定时任务、环境变量。
- 证书与密钥：SSL 证书、部分接口的密钥文件。
- 外部配置的记录：DNS 解析、CDN 回源规则、防护策略。它们不在服务器上，但恢复时一定会用到。
二、备份频率与保留策略
频率跟着更新节奏走。内容每天更新的站点，数据库建议每天一次；文件变化不大，可以每周一次，或者在每次改版、装插件前手动做一次全量。保留策略上，至少留 7 份日常备份加 4 份周备份，再留几份月度归档，用来应对那种「很久以后才发现被改坏」的情况。
只有一份备份，等于没有备份。它和源数据同时损坏的概率，比想象中高。
三、存放位置：别和源站睡在一台机器上
备份文件和站点放在同一块硬盘、同一台服务器上，遇到整机故障、误删目录、勒索加密，基本是一起没。比较稳妥的做法是两份：一份放在本地或挂载盘，用于快速回滚；一份推到对象存储或异地服务器，用于兜底。放在 Web 可访问目录下的备份包，还要确认目录没有被浏览、没有被搜索引擎抓到。
四、恢复演练：把流程真的走一遍
先准备一个隔离环境
用测试域名、独立的数据库实例，并且断开对外的邮件、短信、支付接口。演练的目的是验证数据完整，不是让测试站点真的对外发通知。
演练步骤
- 解压备份包，核对文件数量与总体积，和上次备份对比是否有异常缩减。
- 导入数据库，检查表数量、关键表的行数是否与预期接近。
- 调整配置里的域名、数据库账号等环境相关项。
- 依次访问首页、栏目页、详情页、搜索页和表单提交，看是否正常渲染与响应。
- 抽查几个关键页面，和线上内容做比对，确认不是旧版本。
- 记录整个恢复耗时、卡住的环节和报错信息，补进恢复手册。
五、几个验证备份可用性的小检查
- 备份文件大小是否和上次接近，突然变小要立刻查原因。
- 压缩包能否正常解压，是否设置了口令而口令没人记得。
- 数据库导出文件里是否包含完整的建表语句，而不只是数据。
- 恢复后图片、附件能否正常显示，路径是否需要重写。
- 定时备份任务是否真的有成功记录，而不是静默失败。
六、记录与权限
把恢复流程写成一份可执行的文档：备份放在哪、怎么下载、用什么命令导入、遇到报错找谁。备份文件本身建议加密，访问权限收窄到必要的人。人一换、时间一久，没有文档的流程等于不存在。
七、常见的坑
- 只备份数据库，忘了上传目录，恢复后满站图片丢失。
- 定时任务失败没有告警，连续几个月没有新备份。
- 备份包放在可下载目录，被扫描工具抓走。
- 演练时误把测试站连到生产数据库，反而制造了事故。
备份的价值不在文件本身，而在恢复那一刻。建议把恢复演练排进固定的运营节奏，比如每季度一次，让流程保持可用，也让接手的人心里有底。