OCMバックアップ復元システム

Joe | 2026-02-15

クラスタ管理にはインフラが必要

複数のOpenClawノードを管理する上で、最も痛みを伴う問題の一つが設定の移行だ。各ノードにはそれぞれ独自のgateway設定、agent設定、認証情報、cronタスク、環境変数がある。あるノードの設定を別のノードに移行する必要がある時、手動操作は面倒なだけでなく、ミスが発生しやすい。

私はこの苦痛を何度も経験した——宝塔ノードでagent設定を完璧に調整し、PC-Bでも同じものを動かしたいと思った結果、手動でコピー＆ペーストに30分かかり、最終的にパスを1つ書き間違えたせいでデバッグに2時間費やした。

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データの復元に失敗しても、設定とプログラムは少なくとも正常な状態を保つ。

設定の適応。 これが移行シナリオの核心的な課題だ。宝塔ノードの設定では、パス、ポート、トークンがすべて宝塔環境向けになっており、そのまま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をデプロイしたい？ゼロから設定する必要はない。既存ノードから設定を移行すれば、数分で完了する。

設定のバージョン管理。 各バックアップにはタイムスタンプが付いており、任意の過去の設定に遡ることができる。設定を壊してしまった？前のバックアップに復元すればよい。

運用の標準化。 統一されたバックアップ復元ツールがあれば、ノード管理は運用担当者の記憶や経験に依存しなくなる。新しい担当者でもすぐにキャッチアップできる。

今後の計画

現在のバージョンは機能的に使えるが、まだ最適化の余地がある。次に計画していること：

• 自動定時バックアップ：毎日全ノードの設定を自動バックアップ
• バックアップ差分比較：2つのバックアップ間の設定変更を表示
• ワンクリック一括復元：複数ノードを同時に復元
• バックアップストレージ最適化：増分バックアップでストレージ使用量を削減

OCMはOpenClawクラスタ管理のコアインフラの一つだ。agentのように直接ユーザーに向き合うものではないが、エコシステム全体の安定稼働を支えている。インフラをしっかり作れば、上位レイヤーのアプリケーションは安心して走れるのだ。