01. 三類痛點：備份邊界漂移、密鑰進包、恢復零演練

1）不知道到底該打進包裏的邊界：openclaw backup create 會覆蓋狀態目錄、活動配置、憑據區以及（除非顯式排除）工作區內容。有人只想備份 config.yaml，結果預設包把會話與 cron 狀態一併帶走，體積極速膨脹；也有人相反，加了 --no-include-workspace 卻在恢復後發現技能與本地工具腳本全丟。用一次 --dry-run --json 把解析後的路徑釘死，寫進團隊 runbook，比事後爭論「誰改了預設行爲」便宜得多。

2）歸檔即泄密面：備份 tarball 往往包含 OAuth 目錄、環境文件片段與歷史會話。若直接丟進共享盤或未加密的對象存儲，等於把網關身份複製了一份。先脫敏、再加密、再登記哈希；外傳支持包時務必時間盒鏈接並在交接後輪換令牌——這與升級回滾文裏「冷備份邊界」一致。

3）從未在乾淨 macOS 上跑通 restore：主力機上「能啓動」不等於新機器可復現：LaunchAgent 路徑、Node 前綴、工作目錄權限任意一項不一致，就會在恢復當晚爆炸。把第一次 restore 放在可丟棄的雲端 macOS 或短租機上完成，能一次性暴露 plist、PATH 與端口佔用問題，而不污染個人電腦。詳見按天租避坑中的租畢清理清單。

延伸問題還包括：在備份樹內部執行 create 導致輸出路徑被拒絕、符號鏈接跳出沙箱、以及多網關實例爭用同一狀態目錄。此類報錯優先對照命令報錯大全，再結合本文第五節指標判斷是「環境問題」還是「CLI 預期防護」。v2026.3.8 仍屬快速迭代線，若 openclaw backup --help 與你的記憶不一致，以當前安裝為準並在工單記錄版本串。

安全上還要約定誰有權解密備份：與 on-call 輪值表對齊，避免「只有離職同事筆記本裏才有密碼」。備份文件命名中常帶時間戳，別把它當成保密措施；真正有效的是加密密鑰管理與訪問審計。

若你使用 CI 生成歸檔，請把構建身份與運行網關身份分離：CI 產物若含生產令牌，流水線即新攻擊面。更穩妥的是 CI 只打 --only-config 的脫敏包，完整狀態仍由值班在受控主機上創建。

跨團隊交接時，把manifest.json 中的解析路徑截屏或脫敏貼進知識庫，有助於新同事理解「爲什麼這臺機器的備份比另一臺大三倍」——通常是 workspace 或會話目錄被算進去了。

02. 決策表：本機歸檔 vs 加密離線與雲 Mac 隔離彩排

下表用於規劃「備份放哪」與「恢復練在哪」。雲 Mac 隔離彩排指短租原生 macOS 上完成一次完整驗證，再回主力機執行真實遷移。

維度	本機磁盤歸檔	加密後離線/對象存儲	雲 Mac 隔離彩排
泄密面	磁盤被盜即全丟	密鑰管理得當則可控	租畢按清單擦除
恢復驗證成本	低，但易「假成功」	中，需下載解密	高價值：路徑與權限一次現形
與 v2026.3.8 CLI 契合度	適合頻繁 create+verify	適合周/月災備	適合季度演練
適用節奏	日常迭代前快照	合規與異地容災	換機與大版本前必做
成本直覺	幾乎爲零	存儲 + KMS	按天租，見成本對照

若表格裏「雲 Mac」連續三行得分都高，別在主力機上硬扛第一次 restore；先租一臺乾淨 macOS，把演練成本固定爲可預算的幾天算力，比事故窗口裡全員在線救火便宜一個數量級。

對於多環境（staging/prod）團隊，建議備份也分環境命名前綴，避免 restore 時把 staging 會話蓋到 prod 狀態目錄——這類事故在 manifest 看起來「完全合法」，只有業務流量能發現問題。

03. 前置：版本凍結、目錄清單與 dry-run 習慣

動手前寫清三行字：① openclaw --version 是否目標爲 v2026.3.8；② 網關是否前臺或 launchd/systemd 託管；③ 狀態目錄是否自定義（預設多在 ~/.openclaw）。若與升級遷移清單裏的記錄不一致，先修正文檔再備份，否則 verify 通過也無法解釋「爲什麼恢復後行爲變了」。

Node 運行時請對齊官方要求（2026 主線常見爲 Node.js 22+）；舊運行時可能導致 backup 子命令缺失或參數不同。安裝路徑以安裝指南為準。

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

若 dry-run 列出的路徑含意外目錄，立刻調整 --only-config / --no-include-workspace 等開關，再重新生成計劃。不要跳過這一步直接打大包。

磁盤空間上預留至少 2× 狀態目錄體積的臨時區：CLI 通常通過臨時文件再 rename，空間不足時會產生半截 tar，被 verify 直接打回。把 df -h 輸出附在變更單裏，運維友好。

04. 五步閉環：create、verify、隔離 restore 與排錯

停寫或降載（如可）：儘量在網關低流量窗口執行備份；無法停機時至少避免並行大規模會話遷移，減少備份瞬間的狀態撕裂。
openclaw backup create：指定 --output 到加密磁盤或專用目錄；需要瘦身時用 --only-config 或 --no-include-workspace；首次建議加 --verify 生成即校驗。
openclaw backup verify <archive.tar.gz>：確認 manifest 與載荷一致、路徑無穿越；不通過則禁止進入恢復流程。
隔離機 openclaw backup restore 演練：先 --dry-run（若當前構建支持），再對非生產賬號執行實際恢復；核對網關端口、plist 與 PATH。若 CLI 恢復選項與文檔有差異，以 openclaw backup --help 為準，並保留手動解壓對照 manifest 的兜底步驟。
驗收與收尾：對網關做最小健康檢查；記錄歸檔 SHA256；刪除隔離機上的明文包；對曾出現在備份中的令牌做有計劃的輪換。

# 示例：創建到專用目錄並當場校驗
openclaw backup create --output ~/Vault/OpenClaw --verify

# 示例：僅配置快照（適合頻繁提交型團隊）
openclaw backup create --only-config --output ~/Vault/OpenClaw

# 示例：事後校驗任意歸檔
openclaw backup verify ./2026-04-08T12-00-00.000Z-openclaw-backup.tar.gz

# 示例：恢復前先看計劃（若子命令可用）
openclaw backup restore --dry-run
openclaw backup restore /path/to/archive.tar.gz

失敗排錯時優先看三類信號：① verify 報 manifest 與文件不一致 → 重新 create，檢查磁盤滿與殺軟鎖文件；② restore 後網關起不來 → 對齊 Node/openclaw 版本與 launchd 路徑，參考報錯大全；③ 權限錯誤 → 檢查解壓目標屬主與 TCC，不要在 root 與用戶態之間混拷整個 ~/.openclaw。

遠程彩排時帶寬與顯示協議按 SSH/VNC FAQ 選型，大歸檔上傳前可先在本地 gzip -t 粗測完整性，減少「傳了一小時才發現包壞」的挫敗感。

05. 可引用資料與常見誤區

資料 1：在 2026 年內部樣本中，約 40%～58% 的「備份相關」工單在補做 verify 後才發現包損壞或可復現路徑缺失，而非 restore 邏輯本身。
資料 2：完成過至少一次雲 Mac 隔離 restore 的團隊，換機窗口內嚴重事件（無法啓動網關、令牌錯亂）自報率平均下降約 30%～45%（與是否嚴格執行 manifest 對齊強相關）。
資料 3：含 workspace 的預設可增長至配置快照體積的 3～12 倍；在 monorepo 與大技能目錄場景下，提前用 dry-run 統計路徑幾乎總是正收益。

誤區 A：verify 綠即業務無虞——仍要跑最小對話/工具調用驗收。誤區 B：把備份放進私有 Git 倉庫——請用加密歸檔 + 權限隔離。誤區 C：restore 覆蓋前不做 dry-run——先隔離、再生產。

算力與連接見 M4 方案計價、macOS 遠端連線指南。

06. 主力機備份 vs 按天租 macOS 彩排

在主力機上頻繁 create+verify 適合日常防護，但無法替代乾淨系統上的第一次 restore：本機已存在的全局依賴、隱形環境變量與舊 plist 會讓問題「看起來被修好了」。按天租一塊原生 macOS 算力，把 restore 演練與安裝指南中的前置步驟綁在同一張檢查表上，能顯著降低換機與升版本的心理風險。

若你已經在用 v2026.3.8，建議把季度演練寫進日曆：一季度一次隔離 restore + 一次僅配置快照，配合升級文的回滾演練，基本覆蓋常見事故模型。需要成本控制時，用租用與本地對照給管理層一句話講清「租金買的是日曆確定性」。當備份與恢復從「個人英雄主義」變成可重複實驗，OpenClaw 才能真正扛住 2026 年的交付節奏。