バックアップと移行

「システム > バックアップと移行」ページ(/admin/backup)は、完全なバックアップのエクスポートとダウンロード、完全なライブラリのインポート復元、軽量のサイト構成のエクスポート/インポート、およびQdrantベクトルライブラリのチェックと再構築の4つのカテゴリを担当します。完全なバックアップはエンジン中立の論理アーカイブであり、同じZipはSQLiteとPostgreSQLのデプロイの間で相互にインポートされ、クロスマシン間の移行、クロスマシン間の移行、災害リハビリはすべてこの道を歩み、触れる必要はありません。pg_dumpあるいはデータベースファイル。

完全バックアップ輸出

アーカイブに何がある

輸出製品は単一のZipであり、内部構造:

aivory-docker-backup-20260711-153000-xxxxxxxxxx.zip
├── manifest.json                 # 格式版本、源引擎方言、各表行数、是否含文件
├── db/
│   ├── users.jsonl               # 每表一个 JSONL,每行一个 JSON 对象
│   ├── conversations.jsonl       # 按外键安全顺序排列,引擎中立
│   ├── messages.jsonl
│   └── ...                       # 全部数据表
├── files/                        # 可选:勾选「包含上传文件与生成产物」时才有
│   ├── uploads/...               # 用户上传的文件
│   └── artifacts/...             # 模型生成的产物(图片、文档等)
└── qdrant/                       # 可选:部署配置了 QDRANT_URL 时自动包含
    └── collections/
        └── aivory_c1536.jsonl     # 逐 collection 的向量点位导出

データラインは、データベースの転送ではなく、論理的なJSONLです:バイナリコラムは、Base64をコードし、大整数を確保し、それがSQLite / PostgreSQLを横断する理由です。aivory_c<维度>名前(たとえば1536 次元モデル 対応)aivory_c1536)。

輸出オプション

選択	仮認	説明
アップロードドキュメントと生成製品を含む	开	uploads と artifacts ディレクトリをパッケージ化すると、アーカイブが明らかに大きくなります。
Qdrant ベータ	自動	配備済みQDRANT_URLすなわち、カウントする必要はありません; Qdrant が設定されていないデプロイには、当然、この段落はありません。

非同期タスクとアーカイブリスト

ページの「バックアップ」へ非同期任務タスクをクリックすると背景に生成され、ページの進行状況(準備中、データベースの読み込み、アーカイブに書き込み)が表示され、ページを離れることができます。

• 同時に実行中のエクスポートタスクは 1 つしかありませんが、エクスポートは次のベクトルメンテナンスタスクと互換性があり、1 つが実行されると、もう 1 つが起動を拒否します。
• 読み込みのみのトランザクションに基づくエクスポートは、ユーザーの通常の使用期間に影響を与えません。
• 完成後、アーカイブは「作成されたアーカイブ」リストに表示され、「ダウンロード」ボタンでローカルに保存されます。BACKUP_DIRカテゴリ(既定)./data/backupsCompose デプロイはデータボリュームにマッピングされます)、リストは生成時間に従って逆に順番にします。

また、スクリプトの定期バックアップに適した同期ストリームエンドポイントがあります:GET /api/admin/backup/export(パラメータ検索)files=1文書を含む、qdrant=0ベータを除外することができる)、応答は直接 zip ストリームです。小さなライブラリはそれをステップアップし、大きなライブラリは、長時間にわたって接続をダウンロードするのを避けるために、ページ上の非同期的なタスクを行うことをお勧めします。

ファイルは自動で削除されません。

生成されたアーカイブはサーバーに残ります。BACKUP_DIRすべてのアーカイブはかなり大きい(ファイルとベータを含む場合が特に)、オフライン保存の後、定期的にディレクトリの古いアーカイブを削除し、データボリュームがバックアップで満たされるのを避けることを覚えてください。

並行区別:通常のユーザーは「設定 > プライバシー」にも「すべてのデータをエクスポート」があり、これは個々のユーザー自身のGDPR式JSONのエクスポートであり、ここでは全ステーション管理者バックアップは2つです。共有とデータ管理。

輸入(全庫置き換え)

操作ステップ

1. 「インポートと復元」セクションで上にエクスポートされた zip アーカイブを選択します。
2. 確認ボトルウィンドウに確認単語を入力します。REPLACE(完全に一致しなければならない)。
3. 「データをインポートして置き換える」をクリックし、完了を待ちます。
4. インポートが成功した後、現在のセッションは即座に無効となり、自動的にログアウトし、バックアップ内のアカウントのパスワード再登録。

言語の代替

導入は箱全体の交換合併ではない:

• データベース取引ですべてのテーブルを空白にし、外部キーのセキュリティ順序を押して JSONL からテーブルごとに再ロードし、アーカイブに存在し、現在のバージョンがない列が省略されます(前方互換性)。中途のどのステップも失敗し、データベースはインポート前の状態を維持しません。。
• ファイル復元:アーカイブに記録されたストレージパスプレフィックスは、本機のアップロード/プロダクトディレクトリに書き換えられ、マシンのパス交換は手動で処理する必要はありません。
• ベクトル回復: Qdrant セクションをアーカイブする際に collection ポイントを回復する; ベクトル回復のアラートはインポートを中断せず、ベクトルメンテナンスで補完できます。
• PostgreSQL ターゲット ライブラリは自動的にセクションをリセットしますが、SQLite ターゲット ライブラリはリセット期間中に外部キーのチェックを一時的にシャットダウンします。エンジン入りボックスで使えます。:SQLite のバックアップは Postgres デプロイにインポートできますし、その逆もできます。
• インポートが完了すると、設定キャッシュは即座に有効になり、バックアップ内のサイト設定は即座に有効になります。

管理者ダウンレベル規則(移行の続きを読む必要があります)

導入完了後、**「このインポートの管理者メールボックスを実行する」を除き、バックアップに加えられたすべてのadminアカウントは自動的に一般ユーザーにダウンロードされます。**それはリクエスト防止の設計です: 構造化されたバックアップを手に入れた人は誰でも管理者アカウントに自分自身を埋め込むことができます。

実際の影響:**新しいインスタンスの初起動時に作成した管理者メールボックスは、旧インスタンスの管理者メールボックスと一致する必要があります。**不一致な場合、古いインスタンスをインポートした後、管理者はすべて普通のユーザーになり、インポートされたアカウント(そのメールボックスはバックアップ中に普通のユーザーしか存在しない可能性があります)も必ずしもログインできません 管理コンソール データベースを手動で修正する必要があります ダウンロードリストの移行操作はこの穴を避けることができます。

サイズ上限とCloudflare

環境変数によるアップロードのハード上限をインポートMAX_BACKUP_BYTES制御、デフォルト 20 GiB (参照)主要な環境変数). サイトが Cloudflare の後ろに位置している場合、Cloudflare はリクエスト対象に 100 MB レベルのパッケージの上限を設けていることに留意し、ビッグアーカイブは、直接接続されたエージェント ソース ステーションのインポートを回避する必要があります。Cloudflare エージェントの設定リバースプロキシ層( Nginx のような)client_max_body_size同様に、バックアップを拡大するために、見てください。リバースプロキシ。

よくあるエラーの導入

現象	原因と処理
400、確認用語が一致しない	REPLACE文字ごとに一致しなければなりません(大文字、空格なし)
413 / 要求が大きすぎる	アーカイブ超MAX_BACKUP_BYTES, または Cloudflare / Anti-Generation リクエストの上限によってブロックされ、上限を拡大するか、チャンネルを直接接続する
Manifesto 試験失敗	アップロードされたファイルは、システムからバックアップされた zip ではなく、ダウンロード / 転送中に切断され、ファイルのサイズを再エクスポートして確認します。
restore failed (no changes committed)	中間のエラーを回復し、トランザクション全体が回転し、データベースはインポート前の状態であり、サービス端ログの特定のテーブルと行後の位置を確認してください。
インポートは成功しましたが ナレッジベース コンテンツが見つかりません	バックアップにはベータセクションが含まれていない(古いインスタンスにはQdrantが付いていません)またはベータ復旧警告が付いています。

輸出/輸入の設定(軽量パス)

完全なバックアップの下には、より軽い方法があります: 移動のみ場所設定ユーザーデータを移動しないで、開発機の構成を生産にコピーしたり、展開を統合したり、災害予備ファイルを保存したりするのに最適です。

方向	行動
設定 ZIP	サイト設定、チャンネル、モデル、スキル、OAuth プロバイダー、画像スタイル、ユーザー グループ、モデル 割り当て、アイコンとスキル資産ドキュメント
配置ファイルの導入	ID によってUPSERT 合併: ID で設定ラインがカバーされ、ローカルな設定が保管され、ユーザー、会話、メッセージ、アップロードファイル、セッション、ログに触れることはありません。

コンフィギュレーションのインポートは破壊的で、セッションのセキュリティ:負ける必要はありませんREPLACEインポート後、再ログインする必要はありません、単一の確認ボックスが実行されます。

設定には明確なキーが含まれています。

ZIPで設定します。明文チャンネル API キー、OAuth Client Secret、SMTP パスワード、オブジェクト ストレージおよび検索 キー (インポート後に直接動作しない場合)。

エンジン間移行:SQLite から PostgreSQL への実習

最も一般的な「シングルマシン SQLite を起動し、成長して Postgres に移行する」の例を参照してください。

1. 古い例: 「バックアップと移行」に進み、「アップロードされたファイルと生成されたプロダクトを含む」を選択して、完全なバックアップをエクスポートしてダウンロードします(Qdrant を設定したベクトルは自動的にパッケージに含まれています)。
2. 新たな例: 按Docker Compose デプロイPostgres モードの完全なサービスをリリースし、サイトへのアクセスが完了/setup初回セットアップ。初期管理者のメールボックスは、以前のインスタンス管理者と一致する必要があります。(パスワードは任意で設定できますが、インポート後はバックアップ内のパスワードで設定します)。
3. この管理者でログインし、「システム > バックアップと移行」にアクセスし、アーカイブ、入力を選択します。REPLACE序列、外のキー、経路の書き換えはすべて自動処理です。
4. インポートを完了して自動的にログアウトし、古いインスタンスのアカウントパスワードで再度ログインします。
5. 検証:ユーザーリストの数、いくつかのセッションとファイルのアップロード、ナレッジベースの検索が確認されていない場合、バックアップにベテータが含まれていない場合(古いインスタンスはQdrantに適用されていません)または異常を取得した場合、「ベクトルメンテナンス」を再構築します。

逆方向(Postgres を SQLite に移行)の手順は完全に同じです。SQLite モデル。

跨機移転リスト

サーバーを変更する際(エンジンは変わらない)は、次の順序で確認します。

1. 古いコンピュータの完全なバックアップ(ファイル、ベータを含む)をエクスポートし、ローカルにダウンロードします。
2. 新機の展開同じバージョンまたは更新版鏡像(古いバージョンの新しいバックアップをインポートすることは保証されていません)。
3. 新機の初起動/setup 古いインスタンス管理者のメールボックス番号を作成する(下位ルールについては、上記の赤い警告を参照)。
4. 100 MB を超えるアーカイブで、新しいコンピュータが Cloudflare を搭載している場合:直接接続チャンネル(ネイティブ)の準備127.0.0.1:8787灰色の雲(見る)Cloudflare エージェントの設定。
5. インポート、再ログイン、検証(ユーザー / 会話 / ファイル / ナレッジベースの検索 / チャンネル キーが動作するかどうか)。
6. DNS は新しいマシンに切断され、古いマシンのデータは検証が完了するまで保持されます。

ベクトルメンテナンス

ベクトルチェック ゾーンは、Qdrant ベクトル ライブラリとデータベースの一致性を管理し、よく使用されるシナリオ: 1 つのインポートベータなしバックアップ、古いブランドのアーカイブから移行、Qdrant データボリュームが失われたり、Qdrant インスタンスが置き換えられたりします。

操作	行動	コスト
ベータをチェック	データベースのドキュメント切断部に、Qdrant に非空のベクトルが存在するかどうかを一つずつチェックし、検証レポートを生成します: あるべき / 正常 / 欠如 / 空のベクトル / ジャンプ、および問題のサンプルをリストします。	無料で、読むだけで正しく、埋め込まれたインターフェイスを呼びません
欠けているベータの再構築	欠落と空向量の切断に、データベースに保存されているテキスト埋め込みモデルを再呼び出し、ベクトルを返すaivory_c<维度>collection; 埋め込みモデルに従って分割実行し、完成後報告再構築/失敗数	消費に組み込まれた API 呼び出し, 大 ナレッジベース 一度の再構築は、実際の埋め込みコストを生み出し、実行前に注目する埋め込みチャンネルの請求

ポイント :

• 再建**オリジナル書類は必要ありません。**テキストは元々データベースにあったので、「ベータなしのバックアップ」はデータを失うことはなく、一度の埋め込みコストを費やして回復する必要があります。
• 両方のタスクは非同期のバックアップタスクであり、ページルーティングの進捗状況であり、同時に1つしか実行されず、バックアップと互換的にエクスポートできます。
• Qdrant ベクトルのバックエンドを配置したデプロイを前提とし、設定されていないときのボタンが直接「ベクトルのバックエンドは設定されていない」と表示されます。

アップグレードと日常バックアップの習慣

バージョンアップグレード スローアップアップデート:

cd /opt/aivory   # 你的 compose 目录
docker compose pull
docker compose up -d

データベースの構造は、新しいバージョンが初めて起動する場合に自動移転SQL を手動で実行する必要はありません(加算、テーブル作成)。

• アップグレード前に完全なバックアップをインストールする自動移行は前向きで、古いバージョンに戻ることは保証されず、アーカイブが手元にあるため、アップグレードの事故はアップグレード前に一度にインポートすることができます。
• 定期的に排出して保管。BACKUP_DIRファイルとデータベースは同じマシンで失われ、ディスクが故障し、ダウンロードしたアーカイブをオブジェクトストレージまたは別のマシンに置くことは本当に危険です。 ZIP 構成は、構成を大きく変更するたびにコピーを残すことをお勧めします。

バックアップ周波数参照

小さなチームは、週に一度の全量(ファイルを含む)+毎回のアップグレードで、最悪の損失を数日以内にコントロールするのに十分です。アーカイブは普通のZipであり、オブジェクトに保存されているライフサイクル戦略を直接回転させることができます。