通道有进有出，备份跟着变：SubscribeChannelBackups 的推送账本

备份的时效性问题

通道备份是有保质品的：每开一条新通道、每关一条旧通道，全量备份的内容就过时一格。本栏目此前讲过静态 SCB 只保存开通道时的信息，也讲过 exportchanbackup 与 restorechanbackup 的手动导出导入。但人工触发导出靠得住的前提是你记得触发。LND 因此在主服务 lnrpc/lightning.proto（v0.19.0-beta）里提供了 SubscribeChannelBackups——一条让备份跟着通道状态走的推送流。

这条流支撑什么备份制度

最省事的形态是「订阅即落盘」：常驻进程保持流打开，每收到一个多通道备份就写入一个新文件，按接收顺序编号；通道集合每次变化后的文件都自带全量，旧文件定期轮换并存放异地。这样「备份离现在多新鲜」就从靠人记的问题变成文件时间戳问题。对频繁开关通道的节点尤其有意义——事件驱动保证每次变化必有一份快照，人工触发则必然漏掉你没想起来的那些天。

两个它解决不了的问题

一是流推送的是备份内容状态，不是备份完成状态：进程收到推送后是否可靠落盘，要靠自己的写入与校验策略兜底，订阅活着不等于备份活着。二是恢复需要通道对手方配合：静态备份不携带对手方的通道状态，数据丢失恢复时要与对方走协商流程，所以完整预案必须包含恢复演练——定期把备份还原到干净节点、比对通道清单与余额，比任何监控指标都可靠。落盘文件命名里带上节点身份标识，多节点的备份同库存放时才有对账依据。

源码注释里的两条更新规则

proto 注释给出的语义可以拆成两条规则。规则一：每当有新通道被加入，流会返回新的通道集合，附带一份包含所有通道备份信息的多通道备份（multi-chan backup）。规则二：每当有通道在链上关闭，流会推送一份新的更新——注释的表述是包含新的单通道备份，以及更新后的、把已关闭通道移除掉的加密多通道备份集合。换句话说，这条流的不变量是最多全、去重后的当前状态：打开中的通道都在账上，关掉的通道不再占位。对恢复流程来说，任何一次推送落到磁盘，都构成一份自洽的全量快照。

与手动导出的分工

exportchanbackup 是点状动作：此刻要出事前的快照，就导一次。SubscribeChannelBackups 是连续动作：订阅方保持一条长连接，把每次推送写入异地存储，相当于把备份频率从人肉记忆变成事件驱动。两者的产物在语义上同源——都是静态通道状态备份，只读，恢复时配合 restorechanbackup 走数据丢失恢复的协商流程。需要注意这条流推的是多通道打包备份与新增通道的单份备份，消费端仍要自己设计落盘、去重与轮换策略。

消费端设计提醒

最后记录一个实现细节：该 RPC 在 0.18 由实验特性转正，0.19 的发布说明明确列出了这条状态变化；proto 里的持续订阅接口与一次性查询接口同属备份域，权限归类一致。写权限配置时对照接口分组，比逐个接口试错高效。

补充一个权限细节：该订阅接口归在信使类权限组，与一次性备份查询同域授权。给备份进程签发 macaroon 时按最小权限只给这一组，比图省事给全权限更安全，也更符合只读导出流的实际职责。

单向流的通病同样适用于这里：订阅断线期间发生的通道变化，重连后是否补推、以什么形态补推，应以实测为准，稳妥做法是重连后主动做一次全量导出对账。多通道备份是加密的，备份密文的解密依赖节点自身的密钥体系——备份文件离开节点数据目录的保管规则，应与助记词同级对待。通道资金安全依赖备份的时效性，过期的 SCB 在强制恢复时可能少报几条通道，恢复后的余额核对不可省略。本文不构成投资建议。