一份导出文件保存成功，并不意味着团队已经准备好恢复工作。等到真的需要找回资料，才会发现自己要恢复的可能不止几行记录，还有文件、关系和让这些资料继续有用的上下文。
备份最容易给人一种提前完成任务的安心感：文件在，就好像事情已经解决。但恢复时需要什么，取决于中断的究竟是哪一部分。只想找回一张表，与希望另一套环境继续承接原来的工作，需要的材料并不相同。
因此，决定保存什么之前，先想清楚准备怎样重新开始。把导出的内容与实际恢复目标对照，才能判断这份备份已经覆盖了什么，还需要为哪些依赖另外做准备。
先从交付目的选择格式
Busabase 的 export / install把一个节点及其子树变成可阅读、可比较的 Git 目录。Doc 是 Markdown，Base 有字段和视图定义，记录以逐行 JSON 保存。这适合交付模板、共享 Skill，或者把当前内容放进 Git 做差异审阅。安装会创建新的 ID。
backup / restore则面向整个空间，用 .bbdump 归档保存数据和文件，默认包括 commit、ChangeRequest、评论、审核与审计历史。恢复保留原 ID，目的是灾难恢复或整个空间迁移。
| 需要交付什么 | 更合适的方式 | 关键边界 |
|---|---|---|
| 一套供别人开始使用的知识库 | export / install | 当前内容、重新分配 ID |
| 可在 Git 中阅读与比较的材料 | export / install | 不携带历史、权限与附件值 |
| 原空间及其历史、关系和文件 | backup / restore | 空目标空间和原 ID 条件 |
这不是哪个格式“更完整就一定更好”。若只是分享一套方法，整空间归档会带入远超交付需要的资料；若要恢复历史，package 又无法补出当初没有保存的内容。
package 能读懂，但它不是历史档案
导出的 package 保留当前内容，方便审核修改。它没有权限、变更历史、Vault secrets 或 webhook rules 的位置，也不携带附件字段中的附件值。附件字段的定义仍可能存在，因此恢复后看到同名字段，不能证明原附件已经回来。
导出时的警告很重要。应该记录丢弃了哪些附件值，以及接收方还需要通过什么单独交付方式获得文件。不要把一份漂亮的目录树当成所有材料都在的证据。
如果团队的需要是给新空间一套相同结构和起始内容，package 正合适。接收方应验收新内容及关系，而不是期待原来的审核评论或历史 ID 自动出现。
.bbdump 的目标条件要先查
CLI 用 backup生成归档，默认保留完整历史；--no-history会跳过 commits、ChangeRequests、operations、comments、reviews 与 audit events，仅保留当前状态。命令选择应写进备份记录，避免以后误以为归档里一定有历史。
恢复要求目标空间真正为空，只有自动创建的根节点。更容易忽略的是，原 ID 在整个数据库内唯一：同一数据库里源空间仍然存在时，不能把这份归档当作克隆包恢复到另一个空空间。空空间只满足一个条件，不消除数据库级 ID 冲突。
因此，需要演练时应先确认目标实例、数据库与空间，取得相应授权。不要对正常业务空间尝试 restore 来“验证一下”，也不要为绕过冲突删除源数据。跨实例搬迁与同库复制必须分别判断。
文件、历史和凭据分别交接
备份文档说明 .bbdump包括资产及其上传字节，恢复结束还会检查孤立引用、缺失关系端点和未进入存储的文件，并把问题作为警告报告。Vault secrets 与 webhook signing keys 不在归档中，需要通过单独受控的流程重新配置。
不含这些凭据，并不表示归档可以公开分发。正文、记录、附件和历史本身可能包含业务敏感内容，应按原数据的敏感程度控制存储与转移。
可以复用现有运维任务表保存备份日期、源空间、输出位置、是否带历史、目标限制、保管人和最近一次恢复检查结果。表里只保存可访问的存储位置或引用，不保存密钥。对关键工作资料，还应注明附件和关联记录的验收责任人。
恢复演练要核身份连续性，而不只核内容
如果业务关系依赖原record ID，恢复后内容相同但身份变了，仍可能接不上原有引用。package安装创建新ID，适合分发起点；保留原身份与历史的恢复，应按.bbdump的要求准备目标。不要把同库克隆当作默认可行方案，先核原ID是否仍被占用。
验收应抽查一条确实需要保留历史的记录：正文、关系端点、附件和相关决定能否一起找到。凭据与外部连接另列交接，不把文件恢复等同外部服务已重连。只有恢复目标里实际读回这些内容，才能说明这次交付满足约定范围。
用恢复结果，而不是文件存在验收
先从真实业务资料中选出少量有代表性的检查对象：一份正文、一条有关系的记录、一项附件、一个需要历史才能解释的决定。记录源状态和期望；这里只制定检查方法，不编造一套已恢复的业务案例。
在有授权且满足空空间与 ID 条件的目标中执行恢复后，读取对应内容、关系和实际文件，再检查一段历史和审核记录。把完整性检查的警告逐项处理。只有归档名称和记录数量相同，还不足以证明材料可用。
可以让已连接的 Agent 先帮助准备清单：
需要委托Agent时，可以这样描述任务
根据这次交付目的和官方 backup/export 文档，列出应保留的正文、关系、历史、权限与文件，检查目标实例及空间前置条件。输出恢复前检查单和恢复后读回清单，不执行备份、恢复、安装、删除或凭据操作。
当前 CLI 不支持恢复中断续跑；--resume会明确失败，--state-only也不是可用的替代备份模式。按实际支持的方式规划演练，保留失败日志和重新开始的条件。
要共享可编辑的起点，交付 package；要找回原空间，准备满足条件的 .bbdump 恢复。格式选对之后，真正的完成标准仍然是：需要的人能打开需要的资料，关系与历史可查，文件确实存在，后续连接有明确配置负责人。