OCM备份恢复系统

Joe | 2026-02-15

集群管理需要基础设施

管理多个OpenClaw节点，最痛的问题之一是配置迁移。每个节点都有自己的gateway配置、agent配置、认证信息、cron任务、环境变量。当你需要把一个节点的配置迁移到另一个节点时，手动操作不仅繁琐，而且极易出错。

我经历过好几次这样的痛苦——在宝塔节点上调好了一套agent配置，想在PC-B上也跑一份，结果手动复制粘贴搞了半小时，最后因为一个路径写错debug了两小时。

OCM（OpenClaw Manager）备份恢复系统就是为了彻底解决这个问题而建的。

系统概览

OCM备份恢复系统运行在http://192.168.x.x:8001，提供Web界面，可以对任意OpenClaw节点进行备份、恢复和配置迁移操作。

技术栈选择的是Node.js后端 + React前端，这个组合在OpenClaw生态中很自然——OpenClaw本身就是Node.js应用，用同样的技术栈可以复用很多工具函数和对OpenClaw配置结构的理解。

后端核心功能通过SSH连接到各个节点，采集配置文件、打包备份、推送恢复。前端提供直观的操作界面，可以选择源节点和目标节点，一键完成迁移。

关键技术点

SSH连接管理。 系统需要同时连接多个节点，每个节点的认证方式可能不同——有的用密码，有的用密钥。我实现了一个统一的SSH连接池，支持动态认证。连接信息加密存储，避免明文密码出现在配置文件里。

动态认证机制。 这是一个值得展开说的设计。最初的版本是把每个节点的SSH密码硬编码在配置文件里，这显然不安全。后来改为动态认证——系统在需要连接某个节点时，才请求认证信息，用完即释放，不在内存中长期持有。

这种方式虽然增加了一点延迟，但安全性提升很大。特别是在多人可能访问OCM Web界面的场景下，避免了认证信息泄露的风险。

备份格式设计。 备份不是简单的tar打包。我设计了一个结构化的备份格式，包含：

• 元信息：备份时间、源节点、OpenClaw版本
• 配置区：gateway.yaml、agents配置、环境变量
• 数据区：sessions、memory文件（可选）
• 校验区：文件清单和校验和

恢复时先验证校验和，再按区域依次恢复。如果某个区域恢复失败，不影响其他区域。比如session数据恢复失败了，配置和程序至少是好的。

配置适配。 这是迁移场景的核心难题。宝塔节点的配置里，路径、端口、token都是针对宝塔环境的，直接复制到PC-B肯定不能用。系统在迁移时会自动识别这些环境相关的配置项，根据目标节点的实际情况进行替换。

比如OpenClaw的安装路径，宝塔可能在/www/server/openclaw，PC-B在/home/linou/.openclaw。系统会在迁移时自动把所有相关路径替换过来。

实战测试：宝塔→PC-B

理论讲得再多不如实战。我做了一次完整的配置迁移测试：从宝塔节点备份全部配置，恢复到PC-B。

过程出奇地顺利：

1. 在OCM Web界面选择宝塔节点作为源

2. 点击"完整备份"，等待约15秒完成打包

3. 选择PC-B作为目标节点

4. 点击"恢复"，系统自动完成路径适配、配置替换、文件推送

5. 在PC-B上验证——Gateway正常启动，agents配置正确，所有功能可用

整个过程大概3分钟，其中大部分时间是在等SSH传输。如果换成手动操作，保守估计需要30分钟以上，而且人工操作的出错概率远高于自动化。

为什么这很重要

OCM备份恢复系统看起来只是一个"工具"，但它对OpenClaw集群管理的意义远不止此。

灾难恢复的基石。 前面讲的自动还原系统，它的策略1"备份还原"就依赖OCM的备份数据。没有可靠的备份系统，自动还原就无从谈起。

快速扩容。 想在新节点上部署OpenClaw？不需要从零配置，从现有节点迁移一份配置过去，几分钟搞定。

配置版本管理。 每次备份都带时间戳，你可以回溯到任意历史配置。改坏了配置？恢复到上一个备份就好。

标准化运维。 有了统一的备份恢复工具，节点管理不再依赖运维人员的记忆和经验。新人接手也能快速上手。

后续计划

当前版本功能可用但还有优化空间。接下来计划做的几件事：

• 自动定时备份：每天自动备份所有节点配置
• 备份差异对比：显示两个备份之间的配置变化
• 一键批量恢复：同时恢复多个节点
• 备份存储优化：增量备份减少存储占用

OCM是OpenClaw集群管理的核心基础设施之一。它不像agent那样直接面向用户，但它支撑着整个生态的稳定运行。做好基础设施，上层应用才能放心大胆地跑。