バックアップとアップグレード

バックアップすべき内容、新しいホストへの復元方法、アップグレード方法、Mattermostサーバーまたは単一のコミュニティをAntimatterへ移行する方法。

バックアップすべき内容

AI 暗号化キーがない場合、復元されたサーバーはモデル接続の API キーを読み取れず、各キーを再入力する必要があります。データベースのバックアップとは別にキーのコピーを保管し、1 つのバックアップが両方を含む状態にならないようにしてください。詳細は 暗号化キー を参照してください。

データベースとファイルは一体です：同時にバックアップし、サーバー外にコピーを保持してください。ボリューム名はcomposeプロジェクト名 antimatter で始まります（docker volume ls で一覧表示可能）。

バックアップ

compose.yaml のディレクトリから実行します。事前にAntimatterを停止すると、完全に整合性のあるコピーが得られます。実行中に取得したバックアップでも通常は問題ありませんが、バックアップ中にアップロードされたファイルが欠落する可能性があります。

stamp=$(date +%Y%m%d-%H%M%S)
mkdir -p backups
docker compose stop antimatter
# Database
docker compose exec -T postgres pg_dump -U antimatter -d antimatter -Fc \
    > "backups/antimatter-db-$stamp.dump"
# File storage, GIF service and the data directory (the AI key file)
for v in files gifs data; do
    docker run --rm -v "antimatter_$v:/data:ro" -v "$PWD/backups:/backup" \
        alpine tar -czf "/backup/antimatter-$v-$stamp.tar.gz" -C /data .
done
docker compose start antimatter
# Secrets
cp .env "backups/env-$stamp"

AM_AI_ENCRYPTION_KEY を設定していない場合、サーバーのキーファイルは data ボリューム内にあり、上記のループでファイルとともに保存されます。より良い方法として、暗号化キー に記載されているように、その内容を .env に設定し、データベースのバックアップとは別にコピーを保管してください。

cronから実行して毎日バックアップし、backups/ ディレクトリを別のマシンにコピーしてください。.env のコピーはサーバーと同じレベルで安全に保管してください。パスワードが含まれているためです。

アップロードされたファイルをオブジェクト単位でコピーする場合（別のS3ストレージなど）は、bucket サービスのAWSコマンドラインツールを使用します：

docker compose run --rm -v "$PWD/backups/files:/backup" bucket \
    "aws --endpoint-url http://files:9000 s3 sync s3://antimatter /backup"

リリースアーカイブを使用する場合、pg_dump -Fc でデータベースをバックアップし、data/ と config/ ディレクトリは通常使用するツールでバックアップします（data/ には AI キーファイルが含まれます）。パッケージを使用する場合、同じ方法でデータベースをバックアップし、/etc/antimatter、/var/lib/antimatter、/etc/gifs-server、/var/lib/gifs-server もバックアップします。

新しいホストへの復元

compose.yaml、保存した .env、バックアップを新しいディレクトリに配置し、次に：

stamp=20261016-030000          # the backup to restore
docker compose create           # creates the volumes, starts nothing
docker compose up -d postgres
docker compose exec -T postgres pg_restore -U antimatter -d antimatter --no-owner \
    < "backups/antimatter-db-$stamp.dump"
for v in files gifs data; do
    docker run --rm -v "antimatter_$v:/data" -v "$PWD/backups:/backup" \
        alpine tar -xzf "/backup/antimatter-$v-$stamp.tar.gz" -C /data
done
docker compose up -d

同じ .env を使用してください。ストレージとデータベースは、それまで使用していたパスワードを維持する必要があり、モデル接続には同じ AI 暗号化キーが必要です。新しいホストが別のアドレスを持つ場合は、SITE_URL（および DOMAIN）を更新してください。

定期的に別のマシンに復元して、バックアップのテストを行ってください。

アップグレード

1. バックアップを取得します。
2. 固定している場合、推奨どおり .env のイメージタグ（ANTIMATTER_IMAGE）を変更します。
3. プルして再起動します：

   docker compose pull
   docker compose up -d
   docker compose logs -f antimatter

起動時に、サーバーはデータベースのスキーマをアップグレードし(ログで進捗を確認できます。大規模なサーバーでは数分かかる場合があります)、イメージにバンドルされているアプリの新しいバージョンをインストールします。リリースアーカイブを使用する場合は、サーバーを停止し、config/、data/、logs/、plugins/、client/plugins/を除くすべてのファイルを新しいアーカイブの内容で置き換え、再度サーバーを起動します。.debまたは.rpmパッケージを使用する場合は、パッケージのアップグレードの手順に従って新しいパッケージをインストールします。

バージョン

Antimatterのサーバーは、ベースとしているMattermostラインのバージョン(現在は12.0.0)を報告します。GitHub上のリリースには、アーカイブやパッケージごとに独自のバージョン番号が付けられており、ベータ期間中は0.9.0シリーズです。antimatter versionコマンドを実行すると、ビルド番号として表示されます。イメージはmainブランチから再構築され、antimatter-nextは毎晩(タグnightly-<YYYYMMDD>)、両方のイメージは各変更時に(タグsha-<commit>)構築されます。これらのタグのいずれかを固定し、意図的にアップグレードを行い、どのバックアップがどのバージョンに対応しているか把握できるように、以前のタグを記録しておきます。

PostgreSQLのメジャーバージョン

Composeファイルではpostgres:17-alpineを使用しています。AntimatterにはPostgreSQL 15以降が必要です。PostgreSQLの新しいメジャーバージョンは、以前のバージョンのデータディレクトリを読み取れません。移行するには、データベースをダンプし、新しいバージョンを新しいボリュームで起動して、そのダンプを復元します。

0.9.0へのアップグレード

バージョン0.9.0(または2026年10月17日以降に構築されたイメージ)の初回起動時、データに対していくつかの一時的な変更が行われます。各変更は一度だけ実行され、データベースに記録されます。これらの変更は、旧バージョンのデフォルト値のままだった項目を新しいデフォルト値に更新し、管理者が明示的に設定した項目は変更しません。ログで進捗を確認してください。

Agentsアプリのサービス

アップグレードでは、Agentsアプリの各AIサービスがサーバー全体のモデル接続としてコピーされ、すべてのコミュニティで共有され、ゲスト以外の全員が使用できるようになります(ゲストにも使用を許可するにはゲストにもをオンにします)。キーは転送時に暗号化されるため、サーバーにはAI暗号化キーが必要です。ファイルがS3にあるクラスタでは、まずAM_AI_ENCRYPTION_KEYを設定してください。設定しないと、コピーは次の起動まで待機します。その後、システムコンソール › AI › モデル接続を確認します:

• 各接続は元のサービスのIDを保持するため、Agentsサービスに設定されたアプリのエージェントや自動翻訳は、引き続きそれを見つけることができます。
• OpenAI、OpenAI互換、Anthropic、Mistral、Cohere、Geminiのサービスは、それぞれOpenAI互換(またはAnthropic)エンドポイントへの接続になります。Azureのサービスは、リソースのOpenAI互換エンドポイントへの接続になります:テストしてください。
• AWS Bedrock、Google Vertex AI、Cohere Northのサービス、および不明なタイプは、理由を添えて要対応とマークされます。これらのクラウド認証情報はコピーされません:プロバイダーのOpenAI互換エンドポイントやLiteLLMなどのゲートウェイを指定して、保存してください。
• 埋め込みサービスは、同じアドレスとキーを持つ接続のEmbeddingsモデルになります。または、独自の接続が作成されます。文字起こしサービスにはwhisper-1モデルが割り当てられます。
• 書き直しと要約がまだ接続を持たない場合、アプリのデフォルトエージェントのサービスとモデルが割り当てられます。

Agentsアプリ自体の設定とデータは変更されません:そのエージェントは引き続きそのサービスを使用します。

デフォルト設定のその他の変更

• Calls: テストモードはオフ、ビデオを有効にするはデフォルトでオンになります。設定で保存された選択は保持されます。通話はまた、コミュニティの種類に従います(詳細は通話と音声を参照)。
• メッセージを上部に固定できるのは、チャンネルの管理者、コミュニティの管理者、モデレーター(メッセージの管理を有する場合)です。ダイレクトメッセージまたはグループメッセージのメンバーは引き続き固定できます。
• アーカイブされたチャンネルには新しいメンバーが参加でき、履歴を読み取れます。ただし、誰も投稿、リアクション、変更を行うことはできません。

Mattermostからの移行

AntimatterはMattermostのデータベーススキーマを使用し、独自のテーブルを追加するため、MattermostサーバーのPostgreSQLデータベースとファイルを引き継ぐことができます。まずコピーで試してください:

1. Mattermostのデータベース、ファイルストレージ(data/またはS3バケット)、config.jsonをバックアップし、Mattermostを停止します。
2. データベースをAntimatterのPostgreSQLに復元するか、Antimatterをそのコピー(AM_SQLSETTINGS_DATASOURCE)に向けます。
3. ファイルをAntimatterのストレージにコピーし、パスを保持します。S3ツールを使用する場合はantimatterバケットへ、リリースアーカイブを使用する場合はdata/へ。
4. 設定を再利用します:config.jsonをコピーするか、amctl --local config migrateでデータベースに移行します(詳細は設定を参照)。MM_環境変数は引き続き動作しますが、都合がよければAM_に名前を変更してください。
5. Antimatterを起動し、データベースのアップグレード中にログを確認してください。その後、システムコンソール › プラグイン › プラグイン管理を確認します。Antimatterは、インストールされているバージョンより新しい場合、Calls、Playbooks、Kanban（Boards）、Agents、および統合機能の独自のビルドをインストールします。Mattermostがこれらのいずれかの新しいバージョンを持っていた場合、そのアプリを削除してAntimatterを再起動し、独自のビルドがインストールされるようにしてください。
6. 独自のプッシュプロキシを設定して、プッシュ通知を再度有効にします。Antimatterは、Mattermostのアプリにのみ配信されるMattermostのプッシュサービス（テスト環境およびホスト環境）には通知を送信しません。プッシュ通知サーバーを変更するまで、サーバーはプッシュ通知を送信しません（プッシュ通知を参照）。

Antimatterは、Mattermost, Inc.が運営するサービスには接続しません（外部サービスへの接続を参照）。設定にそれらが記載されている場合でも同様です：

• Mattermostのプッシュ通知サーバーは設定に保持されますが、使用されません。
• アプリマーケットプレース（マーケットプレースURL）および製品のお知らせ用のMattermostのアドレスが空になります。
• Mattermostのデフォルトだったアプリダウンロード用リンク(Antimatter Apps Download Page Link、Androidアプリダウンロード用リンク、iOSアプリダウンロード用リンク)は、GitHub上のAntimatterアプリのダウンロードページに置き換えられます。自分で設定したリンクは保持されます;
• Callsアプリは、MattermostのものではなくCloudflareの公開STUNサーバーを使用します。保存された設定は変更されません（Callsを参照）。
• セキュリティ更新の確認とクラッシュレポートが削除され、それらのシステムコンソール設定（セキュリティアラートの有効化、診断およびエラーレポートの有効化）とお知らせページも削除されます。

ローカルモードのソケットは現在/var/tmp/antimatter_local.socketです。amctlは旧/var/tmp/mattermost_local.socketも試みます。Mattermostの最近のバージョンはPostgreSQLのみをサポートしており、Antimatterも同様です：MySQLデータベースはまずPostgreSQLに移行してください。Antimatterがデータベースをアップグレードした後、Mattermostに戻す場合は、Mattermostのバックアップを復元する必要があります。

データのエクスポートとインポート

一括エクスポート形式は、サーバー間でデータを移動します。サーバー全体、一部のコミュニティ、または一部のチャンネルを、必要に応じて添付ファイル、プロフィール画像、カスタム絵文字とともに移動できます。

# on the source server
amctl export create --team-name design --include-profile-pictures
amctl export list
amctl export download <export file> design.zip
# on the destination server
amctl import upload design.zip
amctl import list available
amctl import process <uploaded file> --imported-users active

amctl export job list と amctl import job list を使用してジョブを監視します。コミュニティまたはチャンネルのエクスポートの場合、--imported-users は必須です。ユーザーがこのサーバーに移行する場合は active、すでにアカウントがあるサーバーにインポートする場合は inactive を指定します。これにより、不確実な一致から作成されたアカウントは、管理者が確認するまで無効なままになります。--destination-team-name を使用すると、既存のコミュニティにインポートできます。エクスポートとインポートは、デフォルトでサーバーのストレージ（ExportSettings.Directory、ImportSettings.Directory）に30日間保持されます。

サーバー上で antimatter export bulk および antimatter import bulk --apply を使用すると、API を介さずにファイルから同じ操作を実行できます。