跨版本回滚的数据库陷阱

每次遇到要紧急打补丁的安全事件，我脑子里第一个冒出来的念头都差不多：先升，真出问题再回滚。听着挺稳，对吧。可这回认真把 GitLab 那个 CVE-2026-97229 的处置流程从头读了一遍之后，我发现自己这个念头里藏着一个挺要命的误解——回滚这事的难点，根本不在把包换回去。

包能退，数据库退不了

应用版本是可以降级的，一条带降级参数的安装命令下去，程序就回到旧版本了。但数据库不行。

像 GitLab 这类系统，升级到修复版本（19.4.2、19.3.5、19.2.8 这几条线）时，往往一并跑掉了数据库 schema 迁移。包版本能倒回去，已经执行过的迁移不会自己倒放。原文那句我读了两遍：跨小版本降级不支持直接回退运行，必须从升级前创建的热备镜像或全量备份文件执行恢复。

翻译成人话就是：回滚的成本不在那行命令，而在于你有没有一份“升级前那一刻”的备份。没有的话，那不叫回滚，那叫重建。

所以升级前真正该紧张的，是备份这件事，而不是升级本身。我现在的做法是：动手前先确认已有一份可用的全量备份，记下备份时间戳，因为恢复时就靠这个去指定；同时把升级前的崩溃日志保留下来，别急着清理。恢复之后还要再做一遍配置加载和服务重启，让系统真正跑在恢复后的数据上。

这几步里，任何一步图省事，都会让“出事再回滚”变成一句空话。

回滚之后，敞口就回来了

还有个更容易被忽略的点：如果真的被迫退回受影响版本，你的系统就重新暴露在漏洞面前了。

补丁的意义本来是把那个可以被恶意配置触发的解析问题堵上，退回去等于自己把门重新打开。这时候别再指望“先观察两天”——要么让实例进维护模式，要么切断公网访问，只保留可信内网的堡垒机入口，等新补丁出来再排期。这一步不是可选项，是回滚动作的一部分。

我自己的判断标准变简单了：能不能回滚，不看我会不会敲那条命令，而看备份在不在、时间戳记没记、退回去之后我敢不敢让它继续对外提供服务。三个都答“是”，才叫有回滚方案。

下次再冒出“出事大不了回滚”这个念头时，先问自己一句：备份在哪？