服务器快照回滚；3个时机会白忙一场

快照按钮谁都会点，回滚按钮按下去那一刻才是真考验。服务器快照回滚3个时机会白忙一场——这话我认了很多年，白忙的现场见过太多回，不是哪家平台不行，是时机没挑对。

先搞清楚你要回到的是哪个点

这事听着像废话，真出事的时候十个人里八个都是手忙脚乱挑个最近的快照就回，回完才发现那个点是凌晨打的，上午才出的故障，中间那几个小时的订单、注册、评论全没了。快照给的是 RPO 的一个近似值，不是「回到出事前一秒」。我一般先在本子上写两个时间：故障第一次被发现的时间，和最后一次确认数据还干净的时间，这两点中间的空档越窄，回滚的代价就越小。

挑错点，等于再凿一刀。

服务器快照回滚3个时机会白忙一场，头一个就是库还在写

数据库还在跑的时候给整机打快照，很多人默认就这么干，图省事嘛。可 InnoDB 那堆脏页还在内存里没落盘，redo log 正翻滚着，块设备一冻，拿到的数据文件跟日志对不上，起来就是一次带 crash recovery 的启动，严重点直接起不来。我一般这么处理：能停库就 `systemctl stop mysqld`，几十秒的事；停不了就 `FLUSH TABLES WITH READ LOCK` 之后再补一层 `fsync` 才打快照，锁完立刻解锁，别把写业务拖死。云控制台上那个「创建快照」按钮按下去的时候，你的进程还在往盘里写呢，它可不会替你等啊。

停库再打。

只回滚了数据盘，配置留在「未来」

还有一种白忙，数据回对了，服务起不来。原因说来简单——nginx 的 conf、证书文件、crontab、systemd 的 unit、/etc/fstab 这些东西要么在系统盘上没跟着回，要么跟着回了，把后来打的补丁一起抹掉。我吃过这个亏：整机回滚，配置退到一个旧版本，那个版本里 SSL 证书早换过一轮，证书文件跟着一起消失，站点直接红锁。现在动手前我先 `diff` 一遍关键目录，把这个窗口里改过的东西单独 tar 到另一台机器上，回滚完再挑着往回贴，累是累点，总比站点起不来强。

顺带一个特别容易踩的坑，LVM 快照拿到别的机器上验证的时候，XFS 会因为 UUID 一样拒绝挂载，得敲 `mount -o nouuid /dev/vg0/snap /mnt/check`，不然日志里就一句超级块认不出来。我第一次碰见还以为快照坏了，折腾半天。

快照链不是备份，别搞混

快照跟源盘共用底层那一份数据。源盘所在的宿主机、存储、控制器一出毛病，快照跟着一起没。真不是吓唬人。我自己定的规矩是：快照只当最近一两天的后悔药，真正的备份至少留一份在别的地点，能离线就离线。快照链也别拖太长，一层套一层，合并起来慢得要死。真要回滚，多等那十几分钟，业务那边早就炸锅了。

快照只是后悔药。

还有个更阴的地方：不少平台的自动快照策略是一天一份、保留几天就轮转覆盖，等你真要用才发现最早那份早被吃掉，能回的点只剩最近的，而最近那个点偏偏就在故障之前几分钟。策略页上的保留天数，动手前先去看一眼呗，具体以控制台提示或服务商说明为准。

回滚完先别放流量

最冤的一种是回滚成功、服务起来、流量一放，用户数据全写进了旧结构里，等发现表结构对不上，新写入已经把旧数据盖了一层，想再回都回不去了。我现在回滚完先挂内网，起只读，拿几条真实请求打一遍，看日志、看 `chrony` 时间是不是跳了、看证书有效期、看网卡 MAC 和 IP 变没变——整机回滚之后 MAC 换了、内网 IP 也换了，防火墙白名单和授权不跟着改，外面照样连不上，你以为回滚失败，其实只是网络没通。

先挂内网读一遍。

回滚时机比回滚技术重要

老实说，能回滚不代表该回滚。误删、被勒索加密、被程序写坏，这三种情况回滚的收益差得远：误删回滚很香，勒索病毒回滚完可能连病毒一起请回来。所以按下去之前先想清楚故障是「写坏了」还是「被删了」，是程序 bug 还是人手动错了，判断不清就先隔离、先取证。

别一按了事。

我自己的回滚清单

真动手的时候，我按这个顺序走。写在纸上，因为那种时候脑子不太靠得住。

一，故障时间点先写下来，别凭记忆。记下来。二，最近一份一致性备份的时间和位置确认清楚，快照不能顶替它。三，这次要回滚的资源列全：数据盘、系统盘、对象存储里的文件、数据库、缓存，一个都别漏。四，这个窗口里改过的配置，单独备份出去。五，回滚后先在内网验证，能不能挂载、能不能起服务、数据对不对、时间对不对、网络通不通。六，验证过了再逐步放流量，先放一小股就好。七，快照别急着删，留到确认业务正常之后再清。

真出事那天，手别抖。先想清楚要回到哪一秒、哪些东西必须跟着回、回完拿什么验证，这三件事想明白了，回滚才不是赌博。想不明白就先别按，多花二十分钟总比白忙一场强，对吧。