設計情報をバックアップして復元する

1. このページで伝える機能

設計情報とカスタマイズをZIPへ保存し、内容を確認して復元できます。保存対象に応じてモジュラー形式と全体形式を使い分けます。

2. Wagby11で実現できること

2.1 設計情報と業務データを分けて保存する

設計情報のバックアップには、付属のrepository-toolを使います。モデル・画面・メニューなどの定義とカスタマイズを保存します。DB内の業務データは別の対象で、業務データのエクスポートを使います。添付ファイルの実体も別途保管します。

Java 21以降を用意し、インストールフォルダのdesignerを作業場所にして実行します。macOS・Linuxではrepository-tool.sh、Windowsではrepository-tool.batを使います。作成したZIPはdesigner/backupsへ保存されます。

./repository-tool.sh backup
./repository-tool.sh backup --all

ルートのjobsは、モジュラー形式でもrootdefsの追加定義として保存します。configにメール認証情報やアクセスキーが含まれる場合は、バックアップZIPも同じ管理対象として保管します。WAGBY_CONFIG_DIRを指定している場合は、その絶対パスの設定フォルダを全体形式のconfigとして保存します。

2.2 内容を確認してから復元する

最初にinfoで対象ZIPの形式と内容を確認します。以下のバックアップ名.zipは実際のファイル名へ置き換えます。infoは復元を実行しません。復元前にREST APIを停止し、利用中のWeb UIや更新ジョブも止めて作業します。

./repository-tool.sh info バックアップ名.zip
./repository-tool.sh restore バックアップ名.zip

復元前には、現在の編集対象ソースを自動バックアップします。モジュラー形式は既存の全体設定を維持して追加・上書きし、重複するモデルは通常エラーになります。上書きが必要なときの--forceは、対象を確認して使います。固定識別子の衝突や不整合まで無視する指定ではありません。

全体形式は編集対象ソースを入れ替え、既存のrestapi/dataを退避して空にします。ZIPにconfigがあれば現在の設定フォルダも置き換えます。--keep-dataは、復元する定義と既存データの互換性を保証できる場合に限って使います。自動バックアップがあることだけで、業務データの別途保存を省略しません。

2.3 固定識別子を保持して再生成する

モデル・項目のmigration_idは保持します。同じアプリの復元でIDを新規発行し直す必要はありません。モジュラー形式の上書きでIDが衝突する場合も、自動で付け直して回避せず、元の定義との対応を確認します。詳しくは固定識別子を参照してください。

復元後はrestapiでgenerate.sh（Windowsはgenerate.bat）を実行して再生成し、必要なビルドを行ってからREST APIとWeb UIを起動します。アカウント・権限・代表的な画面と保存データを確認します。標準システム定義の不足は製品側の補完規則で補いますが、同名モデルのカスタマイズまで自動更新するものではありません。

3. AIへの指示例

ここでは、標準で用意されている機能をAIに使ってもらう指示を示します。

最小限の指示例

標準のrepository-toolを使って、このアプリの設計情報をバックアップしてください。

AIは定義の配置、カスタマイズ、保存範囲を確認して、使う形式とコマンドを補います。業務モデルの移送か全体の復元かによって形式が異なるため、保存目的も伝えます。最小限の指示だけで次の詳細例と同じ対象・方式になるとは限りません。

より詳細な指示例

標準のrepository-toolで、現在の設計情報とカスタマイズをバックアップしてください。designerを作業場所にしてbackup --allを実行し、作成したZIPをinfoで確認してください。configの実際の保存先と、ZIPの保存場所・形式・対象を報告してください。
そのZIPを、作り直してよいと指定した検証用コピー環境へrestoreで復元してください。復元先のREST API・Web UI・更新ジョブを停止し、業務データと添付実体は別に保存してください。全体復元時のdata退避とconfigの置換を前提とし、今回は--keep-dataを使いません。
migration_idを維持し、標準の生成コマンドと必要なビルドを実行して両サーバーを起動してください。管理者ログインと代表的な画面を確認し、バックアップ・復元・確認の結果を報告してください。元の環境は復元先にしません。

4. 編集されるAppSchemaの例

バックアップと復元のためにAppSchemaへ機能を追加する必要はありません。既存の定義を保存し、復元後に再生成します。以下はバックアップに保持される固定識別子の例です。値をそのまま別モデルへ複製する例ではありません。

entity:
  name: 顧客
  name_en: Customer
  migration_id: 3d1237b0-6055-4be6-a908-f65091804501
  attributes:
    - name: 顧客コード
      name_en: customerCode
      type: string
      pk: true
      migration_id: b53f3995-222a-4223-bfe4-ed5a64c9cb2b

5. 参考資料

guide：リポジトリのバックアップとリストア

designer/docs/appschema/html/guide/15-operations/01-repository-backup.html