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——先隔离、再生产。

算力与连接见套餐页、远程连接指南。

06. 主力机备份 vs 按天租 macOS 彩排

在主力机上频繁 create+verify 适合日常防护，但无法替代干净系统上的第一次 restore：本机已存在的全局依赖、隐形环境变量与旧 plist 会让问题「看起来被修好了」。按天租一块原生 macOS 算力，把 restore 演练与安装指南中的前置步骤绑在同一张检查表上，能显著降低换机与升版本的心理风险。

若你已经在用 v2026.3.8，建议把季度演练写进日历：一季度一次隔离 restore + 一次仅配置快照，配合升级文的回滚演练，基本覆盖常见事故模型。需要成本控制时，用租用与本地对照给管理层一句话讲清「租金买的是日历确定性」。当备份与恢复从「个人英雄主义」变成可重复实验，OpenClaw 才能真正扛住 2026 年的交付节奏。