很多人把备份和回滚归到运维的活里，觉得做站点运营的人只要管内容就行。但真正出事的那一刻，最先被追问的往往是：页面没了、栏目地址变了、旧版本还能不能回来。备份和回滚方案不是技术炫技，它是站点能不能在半天内恢复正常的底线。
先确认备份到底覆盖了什么
很多团队说有备份，仔细一问只备份了数据库。数据库能还原文章，还原不了图片、伪静态规则和证书。自查时逐项对照下面这份清单，缺哪一项就补哪一项：
- 数据库：内容、用户、栏目、设置的唯一来源；
- 上传目录与静态资源：图片、附件、下载文件，丢了很难补；
- 站点配置文件：Web 服务器规则、重定向、伪静态、安全策略；
- SSL 证书与私钥：过期或丢失会直接导致整站打不开；
- 计划任务与自定义脚本：定时发布、清理日志、生成地图；
- 第三方侧的关键配置：CDN、解析记录、搜索平台的验证文件与提交设置。
这份清单不用一次做完美，但要有一份写下来的版本，并且注明每项由谁负责。
备份策略：频率、份数、位置
频率跟着更新节奏走
日更的站点，每日一次全量加多次增量是常见做法；更新很少的站点，也不必为了安心每天跑全量，按每周一次加改版前手动备份更实际。关键是改版、迁移、批量替换之前，先手动做一次完整备份，这一步不能省。
别把备份放在同一台机器上
备份文件和站点放在同一块磁盘，等于没有备份。至少做到本地一份、异地或对象存储一份，并保留多个时间点，比如近七天每天一份、近四周每周一份。保留策略写清楚，才不会磁盘满了被脚本自动删掉关键副本。
没验证过的备份等于没有
定期挑一份备份，在测试环境里真实恢复一次，检查首页和几个栏目页能否打开、图片是否完整、伪静态和重定向是否生效。恢复失败的原因通常是备份本身不完整，或者恢复步骤只有某个人脑子里有。
回滚方案要提前写成步骤
回滚不等于「还原数据库」。按影响范围分层设计，执行时才有余地：
- 单页面层：某篇文章出错，直接改回旧版本即可；
- 单栏目层：新栏目结构有问题，先下线入口、保留旧路径；
- 整站层：模板或配置大面积出错，用最近一次可用快照整体回退；
- 配置层：重定向、缓存、证书等规则类改动，单独留一份可对照的旧配置。
每层都要写清触发条件、执行人、预计耗时和验证方式。回滚完成后别忘了清理页面缓存与 CDN 缓存，否则打开的还是旧副本，容易误判为回滚失败。
判断回滚是否成功的标准，应该提前写下来，比如首页可访问、主要栏目返回 200、关键页面内容与预期一致。没有标准，就只能靠感觉。
演练：把恢复流程真跑一遍
- 每季度安排一次，选访问量低的时段；
- 指定一个人按文档操作，其他人只看不提示，看文档是否写得够清楚；
- 记录实际耗时，和预期对比，找出卡住的环节；
- 演练结束后更新文档、联系人和值班安排。
演练的价值不在于流程多完美，而在于把「谁能做、要多久、先做哪一步」变成团队共识。
几个常见的坑
- 只备份数据库，忽略上传目录；
- 备份脚本报错但没有告警，安静地失败了好几个月；
- 备份被加密，密钥却没人保管；
- 恢复后没有清缓存，误以为数据没回来；
- 直接在正式环境做恢复测试，把问题扩大；
- 备份文件堆在一起没有命名规范，出事时不知道哪份是干净的。
备份和回滚平时看不见价值，出事那天却能决定站点是停半天还是停一周。花一个小时把清单列出来，比事后通宵抢救划算得多。