很多站点出事，不是因为被攻击，而是因为一次手滑：清理缓存时删错目录、迁移时覆盖了数据库、插件升级把表结构改坏。备份这件事人人都在做，但真正能救命的备份，是那种被验证过、确实能恢复的备份。
为什么“有备份”不等于“能恢复”
不少站点的备份状态是这样的：脚本每天跑，压缩包确实生成，但从来没人打开看过。等到真出问题，才发现压缩包是 0 字节、数据库只导出了结构没有数据、或者恢复时字符集对不上，中文全变问号。备份的价值不在于文件数量，而在于恢复时的可用性。
常见的三个误区
- 只备份数据库，不管上传目录：文章丢了能补，图片和附件丢了几年的积累很难重新上传。
- 备份和站点放在同一台机器：服务器磁盘损坏或整机故障时，备份和源数据一起消失。
- 备份频率看心情：更新最频繁的栏目反而没有当天备份，出了问题只能回退到一周前。
一次完整备份应该覆盖什么
把下面这些列成清单，逐项确认，能避免“以为备了其实没备”的情况：
- 数据库完整导出，包含表结构和数据，注意字符集与排序规则。
- 上传目录、图片、附件、用户生成内容。
- 主题模板、插件、自定义代码，尤其是被直接改过的文件。
- 站点配置文件、伪静态规则、SSL 证书与私钥。
- 定时任务列表、邮件配置、第三方接口密钥的存放位置说明。
除了文件本身，建议同时留一份“恢复说明”：这套站跑在什么环境、什么版本、恢复时先做哪一步。半年后回来看，你会庆幸当时写了这几行字。
恢复演练：把备份真正跑一遍
演练不需要在生产环境做，找一台测试机或本地环境即可。流程大致如下：
- 从备份包里取出最新一份，按恢复说明逐步还原。
- 检查首页、栏目页、详情页能否正常打开，图片是否显示。
- 随机抽查几篇较早的文章，确认正文完整、没有乱码。
- 检查后台能否登录，发布一篇测试文章再删除。
- 记录整个恢复耗时，评估这个时间是否可接受。
建议把演练安排在版本升级、服务器迁移这类高风险操作之前做一次，效果最明显。
演练中容易暴露的问题
- 备份包里缺少某个目录，恢复后页面样式错乱。
- 数据库版本不一致，导入时报语法错误。
- 域名或路径写死在配置里，换环境后无法访问。
- 恢复脚本依赖某个已经不存在的账号权限。
备份文件的存放与访问控制
一个经常被忽略的细节是：备份文件被随手放在网站根目录下，文件名又比较好猜，很容易被扫描器扫到，也可能被搜索蜘蛛抓到并留下记录。压缩包一旦可公开下载，等于把整个站点的数据挂在公网上。
更稳妥的做法是把备份放在 Web 根目录之外，或者放到独立的存储空间；如果确实要放在站点目录内，至少通过服务器规则限制访问，并给文件名加上随机串。同时定期清理过期备份，避免磁盘被写满，反而拖停站点。
日常检查清单
- 备份任务最近一次执行时间是否正常，文件大小是否合理。
- 是否至少有一份异地或异机备份。
- 备份文件是否可被外部直接访问。
- 最近三个月内是否做过一次恢复演练。
- 升级、迁移、批量改数据之前，是否手动做过一次快照。
备份不是一项装完就不用管的功能，而是一套需要定期验证的流程。花半小时做一次演练，可能省下的是几个月的返工。