灾备

在全新环境里从备份重建，以及各个组件该按什么顺序拉起来。

备份与恢复讲的是把库恢复回它原来待的地方。这页讲更难的那种： 环境没了，你在另一批机器上重建。 流程绝大部分是一样的，不一样的地方在于地址变了，而夜莺内部有好几处东西是钉在老地址上的。

你必须带出来的东西

输入	没有它会怎样
元数据库的备份	没什么可恢复的。用户、业务组、规则、仪表盘、通知配置全在里面
`etc/` 目录	所有配置都得从头再调一遍
你当时跑的那个版本的二进制	换成更新的版本，它一启动就会把 schema 往前迁一次——这是在恢复之上又叠了一次变更
同一个版本的 `integrations/`	内置的仪表盘和规则模板，以及你自己加的那些

真正要命的是前两样。etc/ 在版本库里、备份在异地，你就能重建；只要有一样只存在于那批已经没了的机器上，你就重建不了。

元数据库。 把备份恢复进一个全新的空库。别的什么都不能先起：连不上数据库的进程会直接退出。
Redis，空的。 不要恢复它——登录态、心跳时间戳、主机元信息都会自己过期。代价是什么，备份与恢复里说了。
一个 n9e 实例。 恢复 etc/，把 [DB] DSN 和 [Redis] Address 改成新地址，单独把它起起来。
先验证，再加东西。 curl --noproxy '*' http://n9e:17000/ping 返回 pong； grep -i "failed to migrate table" logs/*.log 没有输出；能登录，规则、仪表盘、通知配置都在。
修地址——见下一节。要在采集器回来之前做完，让数据落到仪表盘去查的那个地方。
其余 n9e 实例。 到系统配置 → 告警引擎确认它们都出现了。
采集器，然后是边缘机房。 故意放在最后：见下面这条。

先建屏蔽，再起采集器。 指标一恢复，故障期间所有「条件不成立所以没告警」的规则瞬间同时成立，一起烧出来。第 7 步之前先建一条时间范围覆盖恢复窗口的屏蔽规则，让它自己过期。屏蔽规则是告警通知 → 规则管理页上的一个 tab。

这是「重建」和「恢复」的分界线。下面每一项都是老环境跑着的时候记下来的，从备份里回来之后指向的是一批已经不存在的机器：

什么	存在哪	怎么处理
数据源地址	`datasource` 表	到集成中心 → 数据源里逐个改。没有任何东西会自动改写它们
数据源关联的告警引擎集群	数据源上的 `cluster_name`	它必须和实例上的 `[Alert.Heartbeat] EngineName` 一致，否则没有引擎会接管这个数据源，它上面的规则永远不跑。要么沿用原来的 `EngineName`，要么把每个数据源都改一遍
通知里跳转链接用的站点地址	`configs` 表里的 `site_info`	到系统配置 → 站点设置里改。进程只在这个值为空时才填默认值，恢复出来的值会原样保留，于是每条通知都还链向老机器
自动注册的 `embedded-tsdb` 数据源	每次启动重写成本实例自己的地址	不用管，除非你把 `[EmbeddedTSDB] DatasourceUrl` 钉在了一个已经不存在的 VIP 上
告警引擎页面上的旧实例	`alerting_engines` 表	不用管。超过 600 秒没心跳的行会被删掉，十分钟左右这些幽灵就没了
采集器的写入地址	每个采集器自己的配置	改掉，或者把域名切过来。这就是「在需要之前就先给夜莺挂个域名」的理由

通知媒介和它们调用的地址一般都在外部，搬家不受影响——但只要有哪个是指回夜莺自己的，它就在上面这张表里。

两个数，而且都来自你能控制的东西，不是你希望的东西：

所以演练就是这件事的全部。备份与恢复要求每季度做一次恢复演练， 把其中一次做成重建——恢复到一台主机名和地址都不一样的机器上，照着上面那张表走一遍。表里每一条都是只有在地址变了的时候才会暴露的，在原地址上做恢复演练永远发现不了它们。

计时，把这个数字记下来，并且把这份手册放在它所描述的那个环境之外。