快照删除与更新；最容易搞错的是先后顺序

快照删除与更新这件事，最容易出事的地方不在“删”这个动作上，而是在你按下删除之前那一次更新的状态没落稳。顺序是：先确认新快照可用，再回头清理旧快照；反过来做，等于把回滚的路先拆了，再去试验新版本——胆子小的人不会这么干，但真到凌晨赶进度的时候，人是会这么干的。

先更新快照，还是先删旧快照

我自己的规矩是：更新在前，删除在后，中间留一段观察期。别嫌麻烦，观察期不用很长，跑一遍业务主流程、翻一下错误日志，够用了。很多人图省事，看到新快照创建成功的提示就直接把旧的清了，可“创建成功”只说明磁盘数据被打包了，不代表这个包能启动、能连上数据库、能正常对外服务。

还有个更隐蔽的坑：有些控制台的快照是增量式的，第一次全量，后面的只记变化块。这时候你把一个中间层的快照删掉，后面依赖它的快照可能就废了，虽然界面上还标着“可用”。以服务商或官方页面说明为准，别拿自己的理解去赌。

时间戳这事看着小，其实最容易翻车。同一台机器一天里打好几个快照，名字如果都是自动生成的，事后你根本分不清哪个是“改配置之前”、哪个是“改完之后”。我的做法是手动在备注里写一句人话，比如“升级前面板正常”，比什么编号都好使。

另一个细节是挂载状态。机器还在跑、磁盘正在写的时候打快照，一致性是有折扣的，数据库这类应用尤其明显。要么先停写，要么用应用层的冷备配合一下，别指望快照能替你解决一致性问题。这个不是我猜的，各家文档里一般都会写，只是没人爱看。

第三点是删除的“不可逆”。回收站、保留策略、快照链这些东西，各家产品的处理方式不一样，有的删了还能找回来几天，有的按下去就没了。你要是手上只有一份可用快照，那就先复制一份出来再动手，多占点空间换一份安心，我觉得划算。

有一次给一个跑得不快的业务机做升级前的准备，我打了新快照，一看列表里旧的一堆，手一抖按了清理，把最新那个也勾进去了。那会儿还没有回收站机制，只能是硬着头皮往下走。升级过程倒是顺利，但中间心里一直悬着——没有回滚点的操作，人的判断是会变形的，本来该停下来看一眼的地方，你会选择继续往前冲。

从那以后我改了个习惯：删除只在自己的核对清单上打勾，不在控制台里顺手点。清单就三行字——新快照能启动、业务验证过、旧快照还留一份。三行都齐了才去点那个删除键。听起来有点笨，但笨办法保命。

删完之后别急着关页面。先看一眼剩余快照的数量和创建时间对不对，再看计费项有没有跟着变化（快照一般按容量占费，删了不更新账单口径的话，你可能会为不存在的数据掏钱，具体口径以官方计费说明为准）。然后隔一天再看一次，确认没有哪个备份任务因为链断了而失败。

顺手把“更新”这个动作也检查一遍：新快照是不是真的在你预期的时间点生成的，有没有被自动策略覆盖掉。有些环境里定时任务是会滚动清理的，你以为自己留了后手，其实后手已经被策略吃了。这种事靠记忆是靠不住的，翻一下任务日志最实在。

小站、单机、数据量不大的，简单点：每次改动配置或升级程序之前打一个，保留最近两三个就够，删的时候先冻结一天再删，别当场清。你这台机器上没有别人等着抢资源，慢一点没成本。

多机、有数据库主从、有对象存储的，就得分层想了。系统盘、数据盘、数据库、对象存储，各自的快照节奏和保留期不一样，删除的顺序也得跟着来——通常是先清最边缘的、最不依赖别人的那一层。反过来先清底层，上面那层就悬空了。这套逻辑没法通用，你得照着自己环境的依赖图画一遍，画完就明白了。

还有一种情况值得单独提一句：迁移前后的快照。机器搬完、验证通过、跑了一周稳定，再删迁移前的那份，这是我认为比较稳妥的节奏。搬完当天就删的，多半是没被坑过。

把这件事当成一个固定动作，别靠临场判断。顺序写死：更新 → 验证 → 观察 → 删除 → 核对账单与任务。中间任何一步不顺，就停在那儿，第二天再说。快照删除与更新本来就不是抢时间的事，它省下的是你出事那天的时间和心情。

如果你现在就想动手，先做一件事：把现有快照列表截个图，手动标一下哪个是“确定能回滚”的。这一步做完，后面删还是更新，你自己心里就有谱了。