服务器快照不是备份；恢复前先查这2处

快照按钮点下去那一下，很多人心里就踏实了——这恰恰是麻烦的开头。服务器快照不是备份；恢复前先查这2处，不查清楚，你手里那张“保险单”可能只是把同一份风险复印了一遍。快照记录的是某个时间点磁盘块长什么样，它不管你数据库事务有没有写完，也不管这份副本和原盘是不是住在同一片存储里。

先把快照和备份的区别掰开

快照是块存储的时间点映像，多数实现走的是增量和写时复制，省空间也快，代价是它跟原盘共享同一套底层设施和同一个账号权限。备份要的是另外几件事：独立介质、能校验、能离线保存、能按版本往回翻，最好还能在一台不相干的机器上完整跑起来。控制台里那排整齐的快照看着像备份，账号一样、区域一样，删实例时手一滑勾上“同时删除快照”，一起归零。各家删实例到底连不连快照、快照能不能跨区复制，以服务商控制台的说明为准，别凭印象。

服务器快照不是备份；恢复前先查这2处之第一处：它躺在哪

第一处就是存储位置和归属。同一块云盘的快照，通常在同一个地域、同一套存储体系里，云盘读不出来的时候，快照也未必救得回来。进控制台做三件事：看快照的地域和可用区，看有没有开跨区域复制，看它是不是挂在实例生命周期上。有条件的话跨账号或跨区留一份冷拷贝，成本不高，灾难来的时候差别很大。

还有个容易忽略的点：权限。快照跟着账号走，账号出事、密钥泄露、欠费停服，快照跟着一起动不了。备份的意义之一就是“权限上分家”，把一份写到另一个账号或另一家服务商那边，这话听着不高级，但真出事时管用。

第二处：时间点对不对，回滚会吞掉什么

第二处查的是时间点和一致性。快照打下去的那一秒，数据库可能有事务还在内存里没落盘，缓存里堆着一批没写回的文件，用户刚上传一半的图片也悬着。回滚到那个点，等于把盘倒回去，快照之后写进去的订单、日志、上传文件全没了。所以先问自己一句：业务能接受丢多少数据，按小时算还是按分钟算。这个答案决定你是只靠快照，还是必须再叠一层逻辑备份。

别直接回滚，先挂一份只读副本

手上有快照，正确姿势不是马上回滚。多数平台支持用快照创建一块新云盘，挂到临时实例上只读挂载，缺哪个文件拷哪个。找回 /etc 下改坏的配置、被覆盖的 nginx 配置文件、误删的证书目录，这种方式最省心。回滚是最后手段，因为它不可逆，还会连带冲掉快照点之后的所有写入。做个只读副本也就几分钟，比事后道歉便宜太多。

数据库这层，快照替不了逻辑备份

数据库尤其明显。快照能保证磁盘层面的完整，但保证不了事务层面的一致性，数据库文件分散在多个盘上时更容易踩坑。稳一点的做法是逻辑导出加 binlog，或者用数据库自带的物理备份工具，按固定周期跑，跑完校验一次能不能导入。快照留着做快速回退，逻辑备份留着兜底，两条腿走路才不慌。

保留策略，别让快照自己过期

自动快照策略一般按天轮转、保留若干天，超过就清掉。平时没感觉，等真出事想恢复上个月那个时间点，翻回去发现早过期了。查一下策略里的保留天数和触发时间，重要的时间点——大版本上线前、批量改数据前——手动打一个，单独加备注，别混在自动策略里被轮转掉。顺手也看一眼快照实际占了多少空间，别等账单出来才想起来。

恢复演练，不用搞太大阵仗

没演练过的备份，等于没有。不用搞全套容灾，每季度挑一份快照挂起来、把服务拉一次、看数据库能不能起、首页能不能开，半小时的事。演练还能顺手发现一些平时看不见的问题：密码写在哪个配置文件里、依赖的服务是不是同一台机器、启动脚本里的路径有没有写死。这些问题在真出事那天，会一个一个跳出来咬人。

恢复之前按这个顺序过一遍：快照在哪个地域、哪个账号，删实例会不会连坐；有没有跨区或异地的一份；目标时间点的业务一致性够不够；先挂只读副本确认内容，再决定回不回滚；逻辑备份是不是也在跑而且验证过。这几条都过了，再点那个恢复按钮，心里才算真踏实。