channel.backup 是谁在替你写
只要用 LND 开着通道，节点就在后台维护一份静态通道备份：默认文件名叫 channel.backup，落在数据目录的网络子目录里，位置可以用 backupfilepath 改。通道新开、关闭或状态推进时，节点会自动更新这个文件。实现细节上，LND 不直接原地改写，而是先写一个名为 temp-dont-use.backup 的临时文件，再原子地把主文件换掉——文件名里的警告不是玩笑，那个临时文件不该被任何工具当成备份本体。这份文件是灾难恢复的底线：丢了 channel.db 时，靠它可以找回通道资金，但恢复时通常要配合扫链找回资金路径，且对端失联的情形下往往只能走强制关闭，费用与时间都要有预算。
v0.19 改了什么：旧副本从被覆盖改为进归档
0.19.0-beta 之前，channel.backup 被更新或通道删除时，旧版本内容就此消失。v0.19 引入归档行为：按 chanbackup/backupfile.go 的源码，旧备份不再直接删除或被覆盖，而是被移入备份文件同级的 chan-backup-archives 子目录留档。源码里对应两条常量：归档目录名 chan-backup-archives 与临时文件名 temp-dont-use.backup；真正干活的管理器在初始化时接收两个参数——主备份文件路径，以及一个是否关闭归档的布尔开关，后者由节点配置传入。
一个功能，两个名字：部署脚本别抄错
这里有个容易踩的坑：v0.19.0 发布说明把新配置写成 disable-backup-archive，说默认 false、即默认归档；而 v0.19.0-beta 源码 config.go 里实际注册的旗标名是 no-backup-archive，描述为置位后通道备份将被删除或替换而不是归档到独立位置。文档名与代码名不一致时，以你所用二进制 lnd --help 实际列出的旗标为准；写进部署脚本前先在测试目录验证一次，不要靠猜把开关名钉死。想保留全部历史副本，什么都不用做；嫌归档目录碍事、确认自己有外部备份纪律的人，才会用到这个关归档的开关。
归档目录里堆的是什么，值不值钱
chan-backup-archives 里存的是通道不同时期的备份快照。它们不是等价资产：较新的副本对应较新的通道状态；拿一份过期快照去恢复，能找回的资金集合可能不完整，甚至因为丢失了更优状态而多付强制关闭的代价。所以归档的正确用法是留档加按时间排序的最后一份，而不是随便挑。同时别忘了它的隐私面：备份文件聚合了通道的出资交易等信息，落到不加密的云同步目录，等于把这些元数据一并交了出去。
例行操作清单
第一，确认归档在跑：开几条测试通道再关掉，看归档目录是否出现旧副本。第二，把 channel.backup 与它的归档目录一起纳入你自己的加密备份流程——节点替你留档不等于异地容灾，U 盘与本地目录同归于尽的例子屡见不鲜。第三，恢复演练优先验证当前主文件，用校验命令确认结构完整后再谈恢复；历史快照只在主文件损坏且刚覆盖不久的情形下按时间倒序尝试。第四，通道数量多、开关频繁的油站节点，归档会随时间增长，注意磁盘占用。
归档不替你完成演练
最后划一条边界：归档目录只是被动留档，它不改变”一切恢复都要走还原通道”这个前提，也不会自动让谁的备份变得更新。旧快照能还原的是它生成那一刻的通道状态，此后的付款与关闭要靠协议里的惩罚交易与撤销密钥处理，历史不会给谁通融出时光倒流的便利。旧副本的真实价值在两处：一是节点状态彻底损毁这种最坏情形的保险层，二是通道台账的审计线索。把归档目录一并纳入既有加密备份的同步范围，成本很低；只记住这个目录只增不减，容量上留出长期余量。
风险提示：通道备份与恢复直接关系资金安全，恢复策略不当可能造成资金损失或长期占用；本文描述以 LND v0.19.0-beta 源码与发布说明为准，操作前请核对你所用版本的一手文档，本文不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。