很多人把备份和回滚归到运维的活里，觉得做站点运营的人只要管内容就行。但真正出事的那一刻，最先被追問的往往是：頁面没了、栏目地址變了、舊版本還能不能回来。备份和回滚方案不是技術炫技，它是站点能不能在半天内恢复正常的底线。
先確認备份到底覆盖了什么
很多团队说有备份，仔细一問只备份了資料库。資料库能還原文章，還原不了图片、伪静態規則和證书。自查时逐項對照下面這份清單，缺哪一項就补哪一項：
- 資料库：内容、用戶、栏目、設定的唯一来源；
- 上传目錄與静態资源：图片、附件、下载文件，丢了很难补；
- 站点配置文件：Web 服務器規則、重定向、伪静態、安全策略；
- SSL 證书與私钥：過期或丢失會直接導致整站打不開；
- 計划任務與自定义脚本：定时發布、清理日誌、生成地图；
- 第三方侧的關键配置：CDN、解析记錄、搜尋平台的驗證文件與提交設定。
這份清單不用一次做完美，但要有一份寫下来的版本，並且注明每項由谁负责。
备份策略：频率、份數、位置
频率跟着更新节奏走
日更的站点，每日一次全量加多次增量是常见做法；更新很少的站点，也不必為了安心每天跑全量，按每周一次加改版前手動备份更實际。關键是改版、迁移、批量替換之前，先手動做一次完整备份，這一步不能省。
別把备份放在同一台机器上
备份文件和站点放在同一块磁盘，等于没有备份。至少做到本地一份、异地或對象存储一份，並保留多個時間点，比如近七天每天一份、近四周每周一份。保留策略寫清楚，才不會磁盘满了被脚本自動删掉關键副本。
没驗證過的备份等于没有
定期挑一份备份，在測試环境里真實恢复一次，检查首頁和几個栏目頁能否打開、图片是否完整、伪静態和重定向是否生效。恢复失敗的原因通常是备份本身不完整，或者恢复步骤只有某個人脑子里有。
回滚方案要提前寫成步骤
回滚不等于「還原資料库」。按影响范围分层设計，执行时才有余地：
- 單頁面层：某篇文章出错，直接改回舊版本即可；
- 單栏目层：新栏目结构有問题，先下线入口、保留舊路径；
- 整站层：模板或配置大面积出错，用最近一次可用快照整体回退；
- 配置层：重定向、缓存、證书等規則類改動，單獨留一份可對照的舊配置。
每层都要寫清触發條件、执行人、预計耗时和驗證方式。回滚完成後別忘了清理頁面缓存與 CDN 缓存，否則打開的還是舊副本，容易誤判為回滚失敗。
判断回滚是否成功的标准，應该提前寫下来，比如首頁可訪問、主要栏目返回 200、關键頁面内容與预期一致。没有标准，就只能靠感觉。
演练：把恢复流程真跑一遍
- 每季度安排一次，選訪問量低的时段；
- 指定一個人按文档操作，其他人只看不提示，看文档是否寫得够清楚；
- 记錄實际耗时，和预期對比，找出卡住的环节；
- 演练結束後更新文档、联系人和值班安排。
演练的價值不在于流程多完美，而在于把「谁能做、要多久、先做哪一步」變成团队共识。
几個常见的坑
- 只备份資料库，忽略上传目錄；
- 备份脚本报错但没有告警，安静地失敗了好几個月；
- 备份被加密，密钥却没人保管；
- 恢复後没有清缓存，誤以為資料没回来；
- 直接在正式环境做恢复測試，把問题扩大；
- 备份文件堆在一起没有命名規范，出事时不知道哪份是干净的。
备份和回滚平时看不见價值，出事那天却能决定站点是停半天還是停一周。花一個小时把清單列出来，比事後通宵抢救划算得多。