备份的价值不在「有备份」，而在「出事时能在半小时内回到某个确定的状态」。判断标准有三条：至少三份副本、两种介质、其中一份不在服务器上。做不到第三条，服务器一旦被删或欠费，备份跟着一起消失。
三份两地的基本盘
一份在服务器本地（快速恢复用），一份在同城另一台机器或对象存储，一份在异地或云端（防机房级故障）。
「两地」听着夸张，实际上把一份同步到对象存储就够了，成本一个月几块钱。
三类内容分别备
| 类型 | 内容 | 频率 |
|---|---|---|
| 文件 | 图片、样式、脚本、HTML | 每次发布前 |
| 数据库 | 文章、页面、设置 | 每天 |
| 配置 | 服务器、域名解析、证书 | 每次变更后记一笔 |
配置最容易被忘。域名解析记录、重定向规则、证书路径，这些丢了比数据丢了还难查。
回滚要能验证
备份脚本跑成功不等于能恢复。每隔一个季度做一次演练：在一台临时机器上还原，看站点能不能正常打开。
没有演练过的备份，只能算「有文件」。
静态站反而更简单
纯静态站的内容就是文件和 HTML，用 Git 管理，每次发布是一个提交，回滚就是切回上一个提交。比起数据库导出，这条路更快也更清楚。
前提是资源与生成脚本一起进版本库，只存 dist 目录就丢了源头。
出事时的顺序
- 先确认影响范围（全站还是单页）
- 切到备份，先恢复可用性
- 再查原因，别在故障现场调试
顺序反了，故障时间会翻倍。安全事件的排查另见网站被挂马。
一次真实回滚的时间线
误删一段配置导致全站 500，回滚的实际过程是这样的：
- 00:07 发现打不开
- 00:11 确认是配置问题，不是服务器故障
- 00:14 从当天凌晨的备份恢复配置文件
- 00:18 站点恢复
- 00:30 比对日志，确认没有数据丢失
- 次日 10:00 补上「改配置前先导出」的流程
恢复用了 11 分钟，其中 7 分钟花在「确认到底是什么坏了」。
这段经历说明两件事：备份要能快速定位到「单个文件」，而不是只能整站还原；以及先恢复再排查，比在故障现场调试快得多。