快照版本能回滚，但它不等于备份

能回滚，不等于有备份。这两句话挨得太近，很多人脑子里自动给它们划了个等号，直到真出事那天才发现，拉回来的那个时间点跟自己想要的东西差着十万八千里。快照版本本质上就是同一套系统按下的暂停键，而备份是把东西搬到另一个地方去——一个在原地留影，一个在远处留种。这俩都叫数据保护，但保的不是同一种险。

快照版本到底存了些什么

云主机上的快照，多数是给云盘做块级副本：第一次全量，后面按变化的数据块增量叠上去。它躺在厂商的存储里，跟你的盘属于同一套体系。你在控制台点回滚，本质是把那个时间点的数据块写回原盘，顺手把现在的状态覆盖掉，所以快，几分钟的事，顺手。

也正因为这样，它不是一个能随便打开的压缩包。想从里面单捞一个文件出来，得看厂商给不给文件级浏览，多数时候要先把快照挂成一块新盘再读。第一次用的人常常在这里愣一下，以为回滚就是万能还原键，实际上它更像倒带。

它和备份的差别，差在另一条命

备份这事情讲究三条独立：介质独立、位置独立、权限独立。快照往往三条全占同一头——同一个存储池、同一个地域、同一个账号。一次事故里，源盘和快照一起没，这不叫运气差，这叫设计使然。

还有个更日常的场面：账号。控制台被人摸进去，第一件干的事常常是把快照和备份一起清干净，然后再坐下来谈条件。日志里能看见，但那时候已经晚了。有的厂商提供回收站、不可变快照之类的机制，那是加分项，别当成默认配置，具体以服务商页面说明为准。

快照版本最实用的地方，是马上要动手那一刻

改 nginx 配置、升级内核、调数据库参数、装一个来路不明的插件、跑一条可能写错的 SQL——干这些之前打一枪快照，出问题几分钟之内退回去，这种爽快是备份给不了的。备份恢复要挑机器、要停机、要等传输，快照就是原地倒带。

成本也不心疼，增量计费，占用量通常远小于整盘容量，口径看各家说明。所以我的习惯是：手要动之前打快照，别指望它保命，就当它是个撤销键。撤销键很好用，但没人会把 Ctrl+Z 当成存档。

这几种情况，快照回滚救不了你

勒索加密是很典型的一种。加密不是一瞬间完成的，它要跑一段时间。如果快照策略只保留最近几份、每天轮转，那干净的时间点很可能已经被加密后的状态挤掉。等你反应过来，能回滚的全是已经被啃过的版本。

第二种是过了很久才发现。删了一个库、写错了一个字段，当时没人吭声，等到月底对账才炸。快照保留期一般就几天，等不及你发现。这种事被坑过不止一回，最难受的一次是数据本身还在，但依赖它的那张报表已经找不到来源了。

第三种是整个盘没了、账号欠费被回收、可用区级别的故障。这些场景里快照和源盘在同一个篮子里，篮子掉了，里面的东西一起掉。

数据库的快照，最容易出“看起来成功”的假象

运行中的 MySQL 直接对盘打快照，可能抓到一个写了一半的状态。InnoDB 有崩溃恢复，多数时候能拉起来，但“多数时候”这四个字放在生产上就不太够用。

稳一点的做法是两条路：要么让数据库先静下来，停写、flush、锁表，看引擎和版本怎么合适怎么来；要么干脆不用盘快照，改用导出——mysqldump 这类逻辑备份、xtrabackup 这类物理备份，或者直接用厂商的数据库备份功能。混着用最保险：快照管整机，导出管数据。

保留策略和增量链，两个最容易被忽略的口子

默认保留几天，好多人从来没点开看过。策略里那行小字，决定了你出事的时候能退多远，值得花十分钟确认一遍，顺手把通知和失败告警也配上。

增量链也别乱动。中间某一份快照看着“没用了”，删掉可能连带后面的链一起失效，各家依赖关系不完全一样，动手前先看文档。控制台上那个删除按钮比回滚按钮危险得多：回滚错了还能再回滚，删错了就真没了。

两套东西各归各位就行

快照放回运维流程里：变更前打、变更后验、过期自动清，当保险丝用。

备份放到另一个地方：不同账号、不同地域，甚至不同厂商，一份离线的或者开了版本控制、不可变的对象存储，账号权限跟生产账号分开管。老掉牙的 3-2-1 说人话就是三份数据、两种介质、一份在别处，土是土，它救过的人比任何新概念都多。

还有一件事比配置本身更要紧——恢复演练。没跑过恢复的备份，只能算“我以为我有备份”。挑个不忙的时候，拿一份备份往新机器上恢复一次，走完整流程、记下耗时。你会撞见一堆平时想不到的坑：证书没带、计划任务没导、依赖的密钥文件压根不在备份范围里。

手要动服务器之前先打快照，这习惯挺好，继续留着；但别把它当护身符。真该问自己的一句是：如果这台机器明天彻底没了，我手上那份躺在别处的东西，最近一次成功恢复是什么时候？答不上来，那就不是策略要怎么优化的问题，是还没开始。