快照应付服务器够用吗；这3种场景会翻车

快照点一下就有，回滚也点一下就好，于是它被顺手当成了备份。这两件事在平静的日子里看不出任何区别，真出事那天差得挺远。快照应付服务器这件事，我的判断是：它撑得住“我把配置改坏了”“我把文件删错了”这类手滑，撑不住“这台机器连同它所在的账号一起没了”。

回滚点和备份，中间差的是一整个篮子

快照挂在云盘上，云盘挂在实例上，实例挂在你这个账号下面。链条上任何一环断掉，快照都可能跟着一起走。账号被盗、欠费太久被回收、删云盘的时候顺手勾了“同时删除快照”，这些都不算稀奇事，控制台上那个勾选框还特别小。备份的定义是原件出事它还在，而且它最好别待在同一个地方。快照大多数时候跟原件在同一个篮子里，只是放得靠里一点，看起来像是安全了。

第一种翻车：数据库还在写的时候按下去

文件系统层面的快照，拿到的是崩溃一致性状态。说人话，它像突然拔电源那一瞬间的硬盘。MySQL 的 redo、InnoDB 的缓冲、Redis 的 AOF，都可能停在半截。你回滚回去，服务是起来了，表还得修，日志还得对着补，业务那边还等着。想要应用一致性，就得先让数据库安静下来，锁表、flush，或者用平台提供的静默快照能力。各家支持到什么程度差别不小，具体以服务商或官方页面说明为准。这一条最容易被跳过，也最容易在真正要恢复的那天翻车。

第二种翻车：整台机器或整个区域出事

快照存在云平台的某个地域里，多数情况默认就在你实例所在的那个地域。机房级别的故障、地域级的网络问题，快照本身可能读不出来，或者读出来慢得让人想砸键盘。再加上账号这条线，密钥泄露被人登进来，第一件事往往不是删你的网站，是把快照和备份一起清掉，因为留着就有痕迹。跨地域复制这功能各家都有，名字不一样，开关在控制台里也不显眼，值得花十分钟去翻一翻，找不到就问工单。

第三种翻车：快照越攒越多，恢复越来越慢

有人一周打一次，一年下来几十个点。平时看着踏实，真要回滚的时候，先得判断回哪个点是对的，然后等云盘从快照链上把数据拉回来，盘越大越慢，几百 G 的盘等上一段不短的时间很正常。另外快照按增量存，删中间某个点会牵扯到后面的链，不少平台干脆不让你随便删，久了就变成一堆想清又不敢清的东西。那种按年留的归档需求，对象存储的归档类型更合适，成本口径各家不同，还是以官方页面为准。

快照应付服务器，什么时候确实够用

单机小站、测试环境、上生产前给自己留个后手，快照完全够用。恢复快，操作简单，改崩了十分钟回到刚才。它解决的是变更风险，不是灾难风险。心里有这条线，用起来就不会错位，也不会在出事之后骂工具不好用——工具从来没说自己能干什么。

我一般这么搭三条线

快照管日常变更前的手滑；平台备份或者自己导出一份（mysqldump、文件打包丢对象存储）管“手上得有一份独立的数据”；跨地域或者下云一份管“这个地域整体不行了”。频率不用追求高，按你能接受丢多少数据来定，再按你能接受停多久来定恢复方式。这两个数想明白了，方案自己就出来了，别人推荐什么套餐都不重要。

恢复这件事必须练，不练等于没有

挑个没人用的时间段，拿最新的快照起一台临时实例，把站点跑起来，登录后台看数据对不对，附件能不能打开，支付回调还通不通。半小时的功夫能发现一堆问题：快照里没有密钥文件、数据库密码写死在配置里、对象存储的桶权限没带上、定时任务还在指着旧 IP。这些东西平时都发现不了，只有真起一台机器才会冒出来。

三个自问，判断你现在的做法够不够

账号被人拿走了，快照还在不在？地域整个不可用，手上还有没有一份能读的数据？回滚到某个点，数据库要不要再修一遍？三个问题有一个答不上来，就该补东西了，不用等出事。

这周找个空档，把控制台里的快照策略、跨地域复制、异地导出三处挨个看一遍，顺手找个测试实例做一次恢复演练，记下从开始到站点真的能访问花了多长时间。这两件事做完，快照应付服务器这个疑问基本就有答案了，比听谁推荐什么方案都管用。