01. 痛み：スコープ漂流、シークレット混入、リストア未演習

1) バックアップ境界が曖昧：openclaw backup create は状態ディレクトリ、有効な設定、クレデンシャル領域、（オプトアウトしない限り）ワークスペースを束ねます。--only-config と --no-include-workspace の選択を誤ると、復元後にスキルやローカルツールが消えたように見えます。--dry-run --json で解決パスを一度固定してください。

2) アーカイブ＝持ち出しリスク：OAuth ツリーやセッションを含む tarball を共有ストレージに置くのは、ゲートウェイ身分の複製です。暗号化とハッシュ記録を徹底し、アップグレード記事のコールドバック境界と揃えます。

3) クリーン macOS での検証なし：手元で起動できても新ホストでは LaunchAgent パスや Node プレフィックスがズレます。捨てられるクラウド macOS または日払い Macで初回リストアを行ってください。日払いの落とし穴にレンタル終了時の消し込みがあります。

バックアップツリー内での create やシンボリックリンクの拒否などはエラー FAQ と照合します。v2026.3.x は速いので openclaw backup --help を正とし、チケットに版文字列を残します。

マルチテナントや共有ホームでは、バックアップ実行ユーザーとゲートウェイ常駐ユーザーを取り違えると、リストア直後にだけ権限エラーが表面化します。取得前に whoami と ~/.openclaw の所有者をログへ残し、隔離 Mac では別ユーザーを意図的に切り替えて演習すると境界がはっきりします。

CI がアーカイブを生成する場合、ビルド ID と本番ゲートウェイ ID を分離し、パイプラインに生トークンを載せない運用にします。

02. 意思決定表

観点	ローカル	暗号化オフサイト	クラウド Mac 演習
漏えいリスク	ディスク盗難	KMS 次第	チェックリストで消去
検証コスト	低いが過信しやすい	復号が必要	高いが経路が可視化
CLI v2026.3.8 との適合	create+verify を日常化	週次〜月次 DR	四半期リハーサル
運用リズム	大変更の直前	コンプライアンス DR	ホスト交換の直前
コスト感	ほぼゼロ	ストレージ+KMS	日額、試算記事

ステージ別プレフィックスでアーカイブ名を分け、staging が production 状態を上書きしないようにします。

03. 前提

openclaw --version、フォアグラウンドか launchd か、状態ディレクトリのカスタム有無を記録します。Node は 2026 主線では 22+ が一般的です。インストールガイドに従ってください。

openclaw --version
node -v
openclaw backup create --dry-run --json

状態サイズの少なくとも 2 倍の空き容量を確保し、verify 失敗の主要因であるディスク満杯を避けます。

04. 五ステップ

可能なら低トラフィック帯でスナップショット。
openclaw backup create --output …。初回は --verify を推奨。
openclaw backup verify <archive>。失敗アーカイブはリストア禁止。
隔離ホストで openclaw backup restore --dry-run（利用可能なら）の後に実リストア。フラグは openclaw backup --help を正とする。
最小ヘルスチェック、SHA256 記録、一時コピー削除、触れたトークンのローテーション。

openclaw backup create --output ~/Vault/OpenClaw --verify
openclaw backup verify ./archive.tar.gz
openclaw backup restore --dry-run
openclaw backup restore /path/to/archive.tar.gz

大容量転送は SSH/VNC FAQ を参照し、事前に gzip -t で破損を弾きます。

05. 指標と誤解

指標 1：「バックアップ」チケットの約 40～58% は verify で破損や欠落が判明し、リストア本体の不具合ではなかった。
指標 2：クラウド Mac で隔離リストアを 1 回以上実施したチームは、換装時の重大インシデント自報が 約 30～45% 減る傾向（manifest 厳守時）。
指標 3：workspace 込みの tarball は設定のみの 3～12 倍 になり得る。

誤解 A：verify 成功＝業務無傷（最小スモーク必須）。B：非公開 Git が暗号化の代替にならない。C：本番上書き前に dry-run を省略しない。

料金とリモートは料金とリモートガイド。

06. 主力機と日払い macOS

手元での頻繁な create+verify は日常防衛に有効ですが、クリーン OS での初回リストアの代替にはなりません。シェルに埋め込まれた PATH や古い LaunchAgent が、不完全なリストアを隠してしまうことがあります。

主力機だけに頼る場合の限界：（1）見かけの健全さ—対話シェルにだけ見えるトークンが launchd 経路には渡らない。（2）権限と TCC—root と一般ユーザーでコピーすると拡張属性が変わり、verify では UI 同意のズレを検知できない。（3）時間と帯域—多 GB の tarball を貧弱な VPN 越しに非 macOS へ送っても、Apple スタックの実証にはならない。（4）運用コスト—演習専用の予備 Mac を常にパッチ当てするのは高く、OS を止めると次の演習は Gatekeeper 側で落ちる。

短いネイティブ macOS（日払いレンタル）が向くとき： 使い捨ての Apple 環境でリストアと launchd を検証し、計画どおりに消去できる—年に数日しか使わないハードを買う CAPEX を避けつつ、障害時の即興作業リスクを下げられます。長期安定・チーム引き継ぎ・完全なエコシステム互換を目指すなら自社・専用レンタの Macが常設運用に向き、日払いは投資前に runbook とトークン運用を実証するための「橋」として合理的です（勧誘ではなく、導入判断の材料として）。

ロールバック手順と四半期リハーサルをセットにし、インストール前提と突き合わせます。経営・情シス向けには 復旧時間 と セキュリティ上の証明（秘密が漏れていないこと）を分けて説明し、コスト比較でカレンダーリスクを数字に落としてください。

運用化のため、verify の完了までの時間、メンテナンス窓内で終わったリストアの割合、常に巨大なアーカイブだけ出すホスト（ワークスペース肥大の早期信号）をトラッキングすると、バックアップが「儀式」ではなく習慣になります。

2026 OpenClaw v2026.3.8 バックアップと復元：
`openclaw backup` の作成・検証、障害切り分け、クラウド macOS 隔離演習

目次