
別チームへ再利用可能な出発点を渡すことと、元空間を復旧することでは保存対象が違います。復旧では原ID、関係、添付、判断の履歴も必要になり得ます。
見た目が完全なexportでも前者専用かもしれません。復旧後に何を残すかからpackageか.bbdumpかを選び、新規リソースの作成と原識別を保つ復旧を区別します。
目的から形式を選ぶ
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が運ぶのは現在の内容です。権限、変更履歴、Vault secrets、webhook rulesは含まず、添付フィールドの値も運びません。フィールド定義は残るため、同名の添付フィールドがあっても元ファイルが戻った証拠にはなりません。
書き出し時の警告を受け渡し資料に残します。必要な添付値が省略された場合は、別途どうファイルを届けるかを決めます。整ったディレクトリだけで必要な資料が揃ったとは判断しません。
同じ方法と初期内容で新しい運用を始めるならpackageが適切です。導入後は新しい内容と関係を確認し、過去の審査コメントや元IDまで戻ることを期待しないようにします。

復元先の条件を先に調べる
CLIのbackupは既定で履歴を含めます。--no-historyを使うとcommit、ChangeRequest、operations、comments、reviews、audit eventsを除外するため、この選択を保存先と一緒に記録します。
復元先のスペースは自動作成のルート以外がない、本当に空の状態でなければなりません。さらに元IDはデータベース全体で一意です。同じデータベースに元スペースが存在する場合、別の空スペースを用意してもID衝突は解消しません。この形式を稼働中スペースの同一データベース内クローンに使うことはできません。
演習前に、対象インスタンス、データベース、スペースと権限を確認します。通常業務のスペースへ試しに復元したり、衝突を避けるため元データを削除したりしません。別インスタンスへの移行と同一データベース内のコピーは、別の作業として判断します。
ファイルと履歴、接続情報を分けて渡す
バックアップの説明には、資産とアップロード済みバイトが含まれます。復元後の整合性確認は、孤立参照、欠けた関係先、ストレージへ届かなかったファイルを警告します。Vault secretsとwebhook signing keysは含まれず、別の管理された手順で設定し直します。
それらの鍵を含まなくても、業務アーカイブを公開してよいわけではありません。レコード、本文、添付、履歴自体が機密を含むことがあります。元データと同じ水準で保管と転送を管理します。
既存の運用タスク表に、日時、元スペース、保存先、履歴の有無、移行先条件、保管担当、最近の復元確認結果を記録できます。秘密そのものは表に置かず、保存先への参照を残します。重要な添付や関係の確認担当も決めます。
復旧では内容だけでなく識別の連続性を見る
元record IDへの参照があるなら、本文が同じでも新IDではつながりません。packageは新IDの再利用用、原識別と履歴の復旧は.bbdumpの条件を確認します。同一DBで元IDが占有されたまま複製できると考えません。
履歴が必要な実レコードで本文、関係、添付、判断を一緒に探します。認証と外部接続は別に引継ぎ、復旧先から実際に読み戻して約定範囲を確認します。

アーカイブの存在ではなく復元結果を確かめる
実際の資料から、本文、関連付きレコード、添付、履歴が必要な判断を少数選び、元の状態と期待値を残します。これは確認対象を決める手順であり、成功済みの架空事例を作る作業ではありません。
空の状態とID条件を満たす承認済みの対象へ復元した後、本文と関係を読み、実ファイルを開き、履歴と審査記録を確認します。整合性警告を個別に処理します。名前や総件数の一致だけでは、資料を利用できることは確かめられません。
接続済みAgentには、操作前の整理を頼めます。
今回の受け渡し目的と公式のbackup/export説明から、必要な本文、関係、履歴、権限、ファイルを整理し、移行先インスタンスとスペースの条件を確認してください。復元前後の確認表だけを返し、バックアップ、復元、インストール、削除、認証情報の操作は実行しません。
現在のCLIは途中からの復元再開に対応しておらず、--resumeは明示的に失敗します。--state-onlyも利用可能な代替モードではありません。対応済みの動作で演習を計画し、失敗ログとやり直しの条件を残します。
再利用する出発点ならpackage、元のスペースを戻すなら条件を確認した.bbdumpを選びます。必要な内容が開け、関係と履歴を追え、ファイルが存在し、再接続の担当者が決まるところまでを受け入れ条件にします。