3. 回滚策略设计：全量回滚 vs 增量回滚、回滚粒度选择
回滚策略，说白了就是「出事了怎么把系统拉回来」。我见过不少团队，镜像备份做得挺勤快，但真到回滚的时候，要么耗时太长，要么影响面太大，最后搞得比故障本身还痛苦。
这一节，我们重点聊两个核心问题：怎么回滚（全量 vs 增量），以及回滚到什么粒度（整机/磁盘/文件）。
3.1 全量回滚 vs 增量回滚
先看一个我早年踩过的坑。有一次线上数据库出问题，需要回滚。我当时的方案是全量回滚——把整个系统盘和数据盘一起恢复。结果呢？一个 500GB 的数据盘，恢复花了将近 40 分钟。业务中断时间完全不可接受。
从那以后，我开始认真区分这两种回滚方式。
| 对比维度 | 全量回滚 | 增量回滚 |
|---|---|---|
| 恢复数据量 | 整个镜像或磁盘 | 仅变更的数据块/文件 |
| 恢复速度 | 慢（取决于数据总量） | 快（取决于变更量） |
| 依赖关系 | 独立，不需要基础镜像 | 依赖上一次全量快照 |
| 适用场景 | 重大故障、环境重建 | 日常发布回退、小范围修复 |
| 存储成本 | 高（每次全量备份） | 低（仅存储差异） |
我的建议：日常发布用增量回滚，重大变更或故障恢复用全量回滚。两者不是互斥的，而是互补的。
举个例子。我们团队现在的策略是：每周日凌晨做一次全量快照，每天凌晨做一次增量快照。回滚时，优先尝试增量回滚——如果增量链路完整，5 分钟内就能恢复。如果增量链路断了（比如中间某次快照损坏），就回退到最近的全量快照。
小技巧：增量回滚的链路完整性检查，建议每次生成增量快照后立即做一次校验。我曾经因为没做这个检查，回滚时才发现中间缺了一块，结果还是得全量恢复，白白浪费时间。
3.2 回滚粒度选择：整机 / 磁盘 / 文件
回滚粒度，决定了你能「精准打击」还是「地毯式轰炸」。我个人的经验是：粒度越细，恢复越快，但管理复杂度也越高。
3.2.1 整机回滚
整机回滚，就是把整个虚拟机或物理机恢复到某个时间点的状态。包括系统盘、数据盘、配置、甚至网络设置。
- 优点：简单粗暴，一次搞定，不需要关心内部细节。
- 缺点：影响面大，恢复时间长，所有服务都会中断。
- 适用场景：系统级故障、内核升级失败、安全补丁导致系统不可用。
注意：整机回滚会丢失回滚点之后的所有数据变更。如果业务有持续写入，一定要先确认数据一致性，或者配合数据库的日志回放。
3.2.2 磁盘级回滚
磁盘级回滚，只恢复某个磁盘（比如系统盘或数据盘），其他磁盘保持不变。
我记得有一次，我们升级了 Nginx 版本，结果配置不兼容，导致所有静态资源 404。这时候如果整机回滚，数据库那边也会跟着回退，影响太大。我们只回滚了系统盘，Nginx 配置恢复，数据库完全不受影响。
- 优点：精准，不影响其他磁盘上的业务。
- 缺点：需要提前规划好磁盘分区策略，系统盘和数据盘必须分离。
- 适用场景：应用升级回退、配置变更恢复、中间件版本回滚。
3.2.3 文件级回滚
文件级回滚，只恢复特定的文件或目录。这是最细的粒度。
说实话，文件级回滚在镜像回滚场景中用得不多，更多是配合文件系统快照（比如 LVM 快照、ZFS 快照）来实现。但如果你用的是分布式文件系统（比如 CephFS），文件级回滚就很有用了。
- 优点：恢复速度极快，影响面最小。
- 缺点：依赖文件系统特性，管理复杂，不适合大规模批量恢复。
- 适用场景：配置文件误修改、单个程序文件损坏、日志文件误删。
避坑指南：我曾经遇到过一个案例，开发人员只回滚了一个配置文件，但没注意到这个文件依赖的库版本也变了，结果服务启动失败。文件级回滚一定要检查依赖关系，不能「头痛医头」。
3.3 回滚策略选择矩阵
下面这张图，是我在实际项目中总结的选择逻辑。你可以根据故障类型和影响范围，快速定位应该用哪种回滚策略。
3.4 实际项目中的策略组合
说了这么多理论，最后分享一个我目前在用的组合策略。你想想看，实际运维中很少只用一种策略，都是组合拳。
# 回滚策略配置示例（伪代码）
rollback:
# 日常发布回滚
daily_deploy:
strategy: incremental
granularity: disk
target: system_disk
max_rollback_time: 5min
# 重大变更回滚
major_change:
strategy: full
granularity: whole_machine
pre_check: true
data_consistency_check: true
# 配置修复回滚
config_fix:
strategy: incremental
granularity: file
target: /etc/nginx/nginx.conf
dependency_check: true
核心原则：回滚策略不是一成不变的。我建议每个季度 review 一次，根据业务变化和故障复盘结果，调整策略的优先级和参数。
嗯，回滚策略这块就聊这么多。记住一点：没有最好的策略，只有最适合你业务场景的策略。全量和增量、整机和文件，都是工具，关键是你怎么组合使用。