备份不是目的，恢复才是
很多站长把“每天自动备份”当成一项已经完成的运维任务，直到某天数据库损坏、服务器迁移或误删文件，才第一次点开恢复流程。结果往往发现：备份文件不完整、密码不知道、恢复步骤没人写过，甚至备份和站点在同一块硬盘上。备份的价值不在生成那一刻，而在需要时能不能把站点还原到可用状态。
先明确要备份什么
- 数据库：文章、用户、评论、配置等动态数据。
- 站点文件：程序、主题、插件、上传的图片和附件。
- 服务器配置：Nginx 或 Apache 规则、PHP 配置、定时任务、SSL 证书。
- 外部服务配置：DNS 解析记录、CDN 回源和缓存规则、对象存储权限。
只备份数据库、不备份上传目录，恢复后会出现文章在、图片全裂的情况。反过来，只打包网站目录、忽略数据库，恢复后的内容还是旧的。把备份范围写成清单，每次检查时逐项打勾。
恢复演练怎么做才不走过场
演练不需要在生产环境上冒险，可以在一台测试机或临时目录里进行。目标不是“能解压”，而是“能访问”。
- 从最近一次备份中取出数据库和文件。
- 在测试环境导入数据库，修改站点地址和数据库连接信息。
- 恢复上传目录和必要的配置文件。
- 用 hosts 绑定或临时域名访问，检查首页、栏目页、详情页、搜索页能否打开。
- 登录后台，确认文章、图片、插件、固定链接正常。
- 记录恢复耗时和卡住的步骤。
演练时最容易暴露的问题，往往不是备份文件坏了，而是没人记得恢复后要改哪些配置。
把恢复步骤写成可执行的文档
恢复流程如果只存在某个人脑子里，一旦他不在线，站点就只能等。文档里至少写清：备份文件存放位置、数据库账号从哪里取、恢复命令或面板操作路径、恢复后需要修改的域名和路径、验证用的检查项。步骤尽量具体到“点哪个菜单、填哪个字段”，而不是“恢复数据库”这种笼统描述。
几个常见的坑
- 备份和站点同机：服务器故障时一起丢，至少留一份异地或对象存储。
- 只保留最近一份：如果误删发生在几天前，最新的备份可能已经把错误状态覆盖进去。
- 备份文件没有权限控制：公开目录下的压缩包可能被直接下载。
- 恢复后忘记更新定时任务：旧路径下的计划任务继续跑，备份可能失败。
- 长期不验证：备份脚本某天开始报错，但没人看通知，直到需要时才发现没有可用文件。
和蜘蛛抓取的关系
站点如果因为故障长时间无法访问，搜索引擎蜘蛛的抓取频率可能下降，恢复后需要一段时间重新观察。备份和恢复演练不能保证收录或排名，但能减少站点不可访问的时间。恢复完成后，可以查看服务器日志，确认蜘蛛是否重新来访，并检查重要页面是否返回正常状态码。
把演练排进日常节奏
不必每天恢复一次，但可以按季度或在大版本更新、服务器迁移前做一次。每次演练后更新文档和备份清单，把发现的问题改成具体动作。备份多一份、恢复快一步，站点在意外面前就多一层缓冲。