快照回滚3个前提：少一样就回不去

快照不是撤销键，它更像一台复印机——复印的只是按下按钮那一刻的纸面，纸上后来添的字它一概不知。所以「快照回滚3个前提，少一样就回不去」这句话不是吓唬人：回滚按钮谁都会点，能不能回得去、回去之后还能不能开机干活，差的全在按钮背后那几样东西。先把前提摆清楚，再聊细节。

快照回滚3个前提少一样就回不去，第一条：那份快照本身得是完片

什么叫完片？拍的瞬间，机器得相对安静。要是有进程正往磁盘里灌数据——数据库写日志、后台上传大文件、编译打包——拍下来的东西就可能是半成品：文件系统的元数据对得上，文件内容对不上。开机之后轻则跑一遍恢复日志，重则表空间坏掉、目录里躺一排零字节文件，看着都在，点开全是空的。

所以通常的做法是先让写停下来。能停就停机拍，最保险；停不了就先把数据库 flush 一下、短暂锁表，或者用平台提供的那种一致性快照（有的叫应用一致性，有的只在关机状态下才保证，具体叫什么、能保证到什么程度，以控制台提示或服务商文档为准，别听谁一句话就上车）。拍之前多花十分钟，回滚的时候少哭一晚上。

还有个更隐蔽的坑：增量链。不少平台第一份是全量，后面全是增量，你在列表里看到排着长长一串时间点，能独立拿出来用的其实只有第一份，其余都挂在前一份上。中间哪一份因为保留策略被清掉、或者同步中断过，后面那些就成了断线的珠子，看着一长串，真去回滚，控制台直接给你报个错。这时候才发现自己手里这份是残的。

这一点被误解得最厉害。有人以为回滚能把误删的那个目录捞回来，别的东西该不动还不动。做不到。回滚是把整块系统盘或者数据盘覆盖成快照那一刻的样子，之后产生的所有写入——新订单、新评论、刚传的图、刚改的配置——一笔勾销。它不讲道理，也不给你勾选。

真想只捞一个文件、一个目录，路子是把快照挂载成一块只读盘，或者用快照克隆出一个新实例，进去把东西拷出来再传回去。这个功能多数平台都有，位置和叫法各不相同，找「快照挂载」「从快照创建实例」这类入口就行。前提还是那句老话：快照本身得是完整的，不然挂上去也是一盘乱码。

所以真要点回滚，当前状态先另存一份。哪怕你觉得现在这堆数据是垃圾，也先拍一份或者导出到别的地方，隔天再删。见过回滚完发现「要救的没救回来，后来的也一并没了」的场面，那表情不好形容，反正当天谁都没敢多说话。

快照是跟盘绑的，不是跟一个抽象的服务名绑。中途扩过盘、换过系统盘、加过数据盘、调整过实例规格，回滚就可能卡壳——要么要求实例先关机，要么要求盘的大小和类型跟快照时一致，要么干脆不让你点。这些规则每家不一样，以控制台弹出的提示和官方文档为准，别拿上次在别家平台的经验硬套。

权限这块更日常。点回滚的那个账号到底有没有这个权限，主账号和子账号的边界划在哪，API 密钥是不是早就换了，账户有没有欠费导致控制台受限，登录要不要过二次验证——平时都不算事，真出事那天全成了拦路虎。提前把能操作的人拉个小群，把账号、密钥、验证器的归属写清楚，比事后满世界找密码快得多。

还有快照的保留期，这条特别容易吃亏。不少平台是按天数或者按份数滚动保留的，新的进来旧的自动清掉。你心里那份「上周状态最干净」的快照，可能前两天就已经没了。回滚前先确认那份还在不在、时间点对不对、是不是关机状态下拍的，这几秒钟能省掉后面几小时。

开机之后先别急着喊好了。先看服务起没起来：数据库能不能连上、主从关系还在不在、缓存里那些旧数据清没清；再核对关键数据，订单表最后一条是什么时候的，用户表有没有明显缺号；然后把日志翻一遍，回滚当天的报错往往比任何猜测都直接。

别忘了外围那一圈。CDN 上挂的旧缓存、对象存储里的静态文件、DNS 记录、负载均衡后面的其他节点，它们可没跟着你一起回滚。页面显示的还是回滚前的图，用户就会以为你根本没修。该刷的刷，该通知的人拉个群说一声，别让人家在群里猜。

最后一步，回滚成功之后立刻再拍一份新快照，名字标清楚，写上日期和状态。这回你知道它是干净的，下次出事有底可用。

快照躺在同一套存储上，原盘坏了、账号被封了、整个可用区出问题，它大概率跟着一起走。备份得放在另一处，最好另一家、另一个城市。快照解决的是手滑和短时间内的错误变更，备份解决的是东西彻底没了。两件事互相不能替代，只做一样就等于只穿一只鞋。

不用背流程，点回滚前问自己三句话就够：这份快照完整吗、是最新的那份吗？回滚会带走这段时间写进来的什么，我另存了吗？机器、盘、账号、权限，现在都对得上吗？三句都能干脆答上来，再点。有一句含糊，就先补那一块，别赌运气。