运维换了台机器，把上个月的备份包挪过去，图省事没加密，一整个明文库躺在盘里，那台新机器上还开着一条口子给第三方做看板用。事后票务系统这边想知道谁动过这份包，什么都查不到——备份包不是售票系统里的数据对象，系统管不着它，管得住它的只有钥匙和一本清单。

头一条是加密落在哪一步。备份包一律加密，打包跑完紧接着就加，中间不留明文落地的那几分钟。拷出去再加一道密的那条路上，半路总留一份明文。用的哪一把钥匙，写在备份清单那一行里，不靠人记。

第二条是密钥交给谁。两人分持：一把在管系统的人手上，一把在财务或者管档案的人手上，两把凑齐才解得开。道理是，一把钥匙就能把这一年的客人信息整个看一遍，这种动作不该有单人版本。管钥匙的人离岗、换岗，钥匙要跟着换——售票系统里的账号可以停，机器上的密钥停不掉，只能换。

本机、异机、场外，开法不一样

本机最省事，也最经不起看：包跟线上库在同一台机器上，顺手就能打开，万一误删，两份一起没。明文那份转走当场删，别留本机当备用。

挪到异机，走的时候必须已经加密。那台机器上不开售票系统的业务口子，只留运维口子；看板、合作方那一类外部连接一律不接到这台。这是最容易出事的位置——包上了锁，门开着。

交给场外托管，交接时对方签一张接收，密钥不跟着包走。包找不到了，重打一份新的送过去，不是把钥匙发过去。票务系统这边留那张接收单的复印件，原件归档案。

恢复一次要几个人在场：两个，而且要签字。恢复单上写包号、源库、恢复到哪台机器、在场两人的名字和时刻，单子归进票务项目的档案，不留在经手人手里；提恢复的人和签字的人是同一个，单子不算走完。恢复动作在售票系统之外，机器上那条操作记录是另一份凭据，两边时间对不上就先停手核对，别开包。

谁在什么时候动过备份，要留得下来

备份清单保留 12 个月，每行登这几栏：包名、生成时刻、源库、存放位置、大小与校验值、加没加密、此刻在哪。动过备份的六种动作都要落一条——生成、复制、挪位置、覆盖、删除、恢复。核对的办法笨但有效：拿清单去机器上对照，机器有包而清单没行，就是有人动过没写；清单有行而机器找不到，先按丢了处理，马上通知分持密钥的两个人。

清单只留 12 个月，包却留着更久：查一份三年前的备份时，包在，生成它的那一行已经清了。所以每年底把票务系统之外这本清单归一份汇总进档案，别到时候只拿"机器上还有个包"当凭据。

例外单列一条：调试用的样例数据不放真实订单，走单独目录。开发要看数据形状、合作方要先试接口，要的只是表结构和几条像样的记录，不是真客人的名字和号。样例目录不算备份包，因此不受密钥两人分持那条约束；但目录里一旦混进真实订单，立刻按备份包口径处理：加密、登清单、恢复按流程走。省事的写法是拿线上库导一小段当样例，这一步在票务系统里不该有人做过。