机器架上一排备份包，最大的那个没人敢开。年底要交材料，问一句"售票系统的备份能恢复吗"，管系统的人答"应该能"。演练要顶掉的就是这三个字。恢复演练每年不少于 1 次，算过的那一天不是包解开了，是真找回了那天的数据，而且三处数字都对得上。

选哪一天来演，决定这场有没有用

挑一个有核销、有退款、还有窗口补录的营业日。淡季随便挑一天最容易骗人：那天本来没几笔，包只打了主库也照不出缺什么。票务系统里的数据本来就是分开落的——订单在主库，核销在检票那侧，日结另成一张表，缺哪一块都得靠笔数才看得见。

第二步是抄基准，必须在演之前抄。当天早上在售票系统的报表界面上抄三项数：订单笔数、核销笔数、日结合计；抄的人和事后核对的人不能是同一个。三项都从售票系统同一个界面取，别一边按订单页点、一边按报表读，口径差就在这一处冒出来。这步省掉的后果很直接——拿恢复出来的库跟它自己对，怎么对都是一致，演十次都是过。

第三步取包。按备份清单上的包号取，密钥两人分持，凑齐才解得开。解之前先对大小和校验值，包名跟清单那一行不一致就停下来，别硬往下跑。

第四步起环境。只回放到测试环境，不许回生产：那台机器不接对外的口子，目录不跟线上共用，恢复期间不许有第二个进程往票务系统的线上库写东西。这一步做没做实，看演完当天线上报表有没有异常就知道。

第五步核对，看三项。同一营业日在售票系统里点订单表的笔数、点核销表的笔数、点日结表的合计，跟早上抄的基准比，差异为零才算通过。差起来通常是两副样子：核销少一截，多半是包只打了主库，检票那一侧的库没进包；日结合计差几笔，多半是营业日切点不一致，跨零点那一笔被算到两天去了。这两种都不算过，写"基本一致"更不行。

第六步记档。演练记录上一行：日期、包号、恢复人、在场人、三项各多少笔、差异、结论、暴露问题编号。从找包到能查单用了多久也当场记实测，几分钟写几分钟，不事后补一句"很快"。

有人会问演练会不会碰坏在线那半边。演练占的是测试机的盘和一段备份窗口，不该停线上的备份任务来腾地方，也不该借线上机器跑。恢复出来的又是真数据，演完的临时库和包该收的收，票务系统给测试环境开的那几个账号演完停掉，别在外面留一个能连的口子。

例外单列一条：演练中暴露的问题当日不改线上，走变更流程。演到第五步发现核销库没进包，人最容易上头，当场就想改备份脚本那两行。当天改的东西没人复核，改错了就把票务系统线上真正的备份弄坏，演练反倒成了事故。做法是把问题登成一条编号，线上一个字不动，回去按变更流程提，改完在下一场演练里再验一次。