快照数据不等于备份；恢复顺序才是关键

快照数据不等于备份。这话在运维群里说出来，点头的人一大片，可真到要拉数据那天，还是有人第一反应去翻快照列表。快照存的是「那一刻磁盘长什么样」，备份要回答的是「我能不能在另一台机器上把它重新长出来」。差一个字，出事的时候差的可能是一个通宵，外加一批找不回来的订单。

快照数据的先天短板，不在技术而在位置

快照基本都躺在同一套存储上，跟源数据共用控制器、共用电源、共用同一套权限。误删实例、阵列故障、账号被人拿到手点了「删除全部快照」，这三件事它一件都挡不住。它更像游戏里的存档点，读档是快，可存档文件和游戏本体搁在同一块硬盘里，硬盘一坏，两样一起没。

所以快照的正经用途是回滚：升级内核前打一个，改 nginx 配置前打一个，改坏了十分钟退回去。这个场景它无可替代，谁也替不了。可要把它当备份使，就等于把鸡蛋放进一个篮子还顺手盖了个盖。真正算得上备份的，得同时满足三条：在别的地方、有独立凭证、能独立恢复。少一条，那只能叫副本。

恢复顺序为什么比恢复速度重要

出事的时候人手忙脚乱，最容易犯的错是抓到一个能用的副本就开始往回灌。数据库先回来了，站点跑起来了，页面能打开，看着挺美——然后发现站点文件是几天前的，数据库是一小时前的，两边对不上：评论区挂着不存在的用户 ID，订单表里一排空壳记录。这种「恢复成功但业务错乱」的状态最难查，比彻底没起来还折腾人。

顺序一乱，还会引出更隐蔽的毛病。证书、密钥、定时任务、上传目录、日志目录的权限位，这些东西既不在数据库里，也不在代码仓库里，它们散在文件系统里。恢复时顺序颠倒、属主搞错，网站能起来但传不了图，或者 cron 半夜跑出去几万封邮件，第二天早上才发现。

一套能落地的恢复顺序

我自己用的顺序是这样，不一定最漂亮，但踩过的坑少一些。先把「恢复到哪个时刻」钉死，写在纸上，所有操作围着这个时间点转，别边做边改主意。接着恢复基础环境：系统版本、运行时、依赖包，这一步别图省事直接上最新版，跟出事那台对齐。然后是静态资源和上传目录，文件大、变化少、丢了不影响业务逻辑，先铺好。

再往后才是数据库。导入前把目标库清干净，别让新旧数据混在一起，字符集和排序规则照着原库来。数据库回来之后跑一次一致性检查，看主键、外键、自增值有没有跑偏。最后收尾的是证书、定时任务、队列消费者、缓存这些外围件，缓存一定要清空而不是恢复旧缓存，旧缓存里往往存着已经删掉的数据。

中间每一步做完都留个快照点，这一次的快照是用来兜底的，不是用来当备份的。全站跑通、抽查几条主链路没问题，再放流量进来。顺序看着啰嗦，真跑起来也就多花十几分钟，比事后对着错乱数据查一星期划算。

只做快照的站，最容易卡在哪一步

见得最多的翻车点是「快照能回滚，可机器没了」。宿主机整机故障、账号被盗把实例删了、账单出问题实例被回收，这些情况下快照跟着一起没。另一个是快照链：连着打了好几个增量快照，中间某个数据块坏了，后面整条链都读不完整，平时看不出，真去恢复才发现只能退回很早的那个点。

还有一种更常见：只备了数据库，没备代码和配置。库导进去了，站点起不来——伪静态规则、PHP 版本、扩展、连接串、计划任务，全得凭记忆重搭。恢复时间一拉长，业务那边的耐心就先没了。

备份要放在快照够不着的地方

做法其实不复杂。快照照打，另外用对象存储或者异地机房存一份完整备份；凭证跟主机账号分开管，主机密码和存储密钥塞进同一个密码本，等于没分开。备份文件加密，压缩包设个密码，别裸着往外传。频率按「能接受丢多少」倒推：能接受丢一天就一天一全备，接受不了就加增量或者开日志备份。份数别只留一份，至少三份、跨两个位置，这是老规矩。

顺便说一句，备份任务的告警得真的发到人手上，别只写进日志文件。备份失败静默跑了半年这种事，我见过不止一次，等到要用的那天才发现最近三个月全是空包。

演练一次，比多买十份备份管用

没恢复过的备份约等于没有备份，这话不是拿来喊的。找个测试实例，把备份拉下来完整恢复一遍，记下花了多久、卡在哪、有哪些东西压根没备到。第一次演练大概率会失败，这很正常，在测试环境失败比在生产环境失败便宜太多。演练完把顺序写成文档，谁负责哪一步、回滚点在哪，都写上，事故当天照着念，不用靠回忆。

下次再看到快照列表里一排绿点，先别急着安心，问自己三个问题：这份数据在第二块地方有吗，存取凭证是分开的吗，上一次完整恢复是什么时候。三个都答得上来，那才叫备份；答不上来，它只是个存档点——读档是快，可存档和游戏还在同一块硬盘上。