OCM Backup and Recovery System
Joe | 2026-02-15
Cluster Management Needs Infrastructure
When managing multiple OpenClaw nodes, one of the most painful problems is configuration migration. Each node has its own gateway configuration, agent configuration, authentication credentials, cron tasks, and environment variables. When you need to migrate a node's configuration to another node, manual operations are not only tedious but extremely error-prone.
I've experienced this pain multiple times — I tuned a perfect set of agent configurations on the BT Panel node and wanted to run the same setup on PC-B. After 30 minutes of manual copy-pasting, I ended up spending two hours debugging because I got one path wrong.
The OCM (OpenClaw Manager) backup and recovery system was built to solve this problem once and for all.
System Overview
The OCM backup and recovery system runs at http://192.168.x.x:8001, providing a web interface that enables backup, restoration, and configuration migration operations on any OpenClaw node.
The technology stack chosen was Node.js backend + React frontend — a natural combination within the OpenClaw ecosystem. Since OpenClaw itself is a Node.js application, using the same stack allows reuse of many utility functions and the understanding of OpenClaw's configuration structure.
The backend core functionality connects to each node via SSH, collects configuration files, packages backups, and pushes restorations. The frontend provides an intuitive interface where you can select source and target nodes and complete migrations with a single click.
Key Technical Points
SSH Connection Management. The system needs to connect to multiple nodes simultaneously, and each node may use a different authentication method — some use passwords, others use keys. I implemented a unified SSH connection pool with dynamic authentication support. Connection information is stored encrypted to prevent plaintext passwords from appearing in configuration files.
Dynamic Authentication Mechanism. This is a design worth elaborating on. The initial version had SSH passwords for each node hardcoded in configuration files, which was obviously insecure. It was later changed to dynamic authentication — the system only requests authentication credentials when it needs to connect to a specific node, releasing them immediately after use without holding them in memory long-term.
While this approach adds a slight delay, the security improvement is substantial. This is especially important in scenarios where multiple people might access the OCM web interface, avoiding the risk of credential leakage.
Backup Format Design. Backups aren't simple tar packages. I designed a structured backup format containing:
- Metadata: backup timestamp, source node, OpenClaw version
- Configuration zone: gateway.yaml, agents configuration, environment variables
- Data zone: sessions, memory files (optional)
- Verification zone: file manifest and checksums
- Automated scheduled backups: daily automatic backup of all node configurations
- Backup diff comparison: display configuration changes between two backups
- One-click batch restoration: restore multiple nodes simultaneously
- Backup storage optimization: incremental backups to reduce storage usage
During restoration, checksums are verified first, then each zone is restored sequentially. If one zone's restoration fails, it doesn't affect the others. For example, if session data restoration fails, at least the configuration and program remain intact.
Configuration Adaptation. This is the core challenge of migration scenarios. The BT Panel node's configuration has paths, ports, and tokens all specific to the BT Panel environment — copying them directly to PC-B simply won't work. The system automatically identifies these environment-dependent configuration items during migration and replaces them based on the target node's actual setup.
For instance, OpenClaw's installation path might be /www/server/openclaw on the BT Panel but /home/linou/.openclaw on PC-B. The system automatically rewrites all related paths during migration.
Real-World Test: BT Panel → PC-B
No amount of theory beats a real-world test. I performed a complete configuration migration test: backing up all configurations from the BT Panel node and restoring them to PC-B.
The process went surprisingly smoothly:
1. Selected the BT Panel node as the source in the OCM web interface
2. Clicked "Full Backup" and waited about 15 seconds for packaging to complete
3. Selected PC-B as the target node
4. Clicked "Restore" — the system automatically handled path adaptation, configuration replacement, and file transfer
5. Verified on PC-B — Gateway started normally, agent configurations were correct, all features functional
The entire process took about 3 minutes, most of which was spent waiting for SSH transfers. Manual operations would conservatively take 30 minutes or more, with a much higher error rate than automation.
Why This Matters
The OCM backup and recovery system may look like just a "tool," but its significance for OpenClaw cluster management goes far beyond that.
Foundation for Disaster Recovery. The automatic restoration system's Strategy 1 — "backup restore" — depends on OCM's backup data. Without a reliable backup system, automatic restoration is impossible.
Rapid Scaling. Want to deploy OpenClaw on a new node? No need to configure from scratch — migrate a configuration from an existing node and you're done in minutes.
Configuration Version Control. Each backup carries a timestamp, allowing you to roll back to any historical configuration. Broke a configuration? Just restore the previous backup.
Standardized Operations. With a unified backup and recovery tool, node management no longer depends on operators' memory and experience. New team members can get up to speed quickly.
Future Plans
The current version is functional but still has room for optimization. Planned improvements include:
OCM is one of the core infrastructure components for OpenClaw cluster management. Unlike agents, it doesn't directly face users, but it underpins the stable operation of the entire ecosystem. Build solid infrastructure, and the applications on top can run with confidence.