Zextras Backupまたはimapsyncを使用してZimbraメールボックスを新しいサーバーに移行する方法

ZimbraからZimbraへの完全な移行には、メール以外のメールボックスデータが必要な場合、サポートされているZextras Backup移行ワークフローを使用してください。両方のサーバーがIMAP経由でアカウントを公開しており、対象がメッセージ、フォルダ、フラグである場合は、imapsyncを使用してください。Zextrasによると、以前のZextras Migration Toolは利用できなくなりました。Zimbra移行ガイダンスでは、管理者にZextras Backupの使用を推奨しています。imapsyncは、IMAPメールボックスをコピーするための別のコマンドラインオプションであり、カレンダー、連絡先、共有、アカウント設定のZimbra対応移行に取って代わるものではありません。

その違いによって、新しいサーバーでどれだけのプロビジョニングとテストを行う必要があるかが決まります。MXレコードを変更したり、ユーザーが宛先サーバーで作業を開始したりする前に、送信元と宛先のバージョン、ライセンス、認証、ストレージ、および保持する必要のある正確なデータを確認してください。

ドキュメントは2026年10月6日に確認済みです。公式のimapsyncサイトにはリリース2.314が記載されています。Zextrasの移行に関する記事には、従来の移行ツールは利用できないと記載されており、Zextrasバックアップの手順が説明されています。Zextrasのページとサンプルはバージョンに依存するため、本番環境で実行する前に、インストールされているZextrasとZimbraのリリースに合わせて検証してください。

並べて表示された比較カードには、Zextras Backup のメール、連絡先、カレンダー、設定、および imapsync の IMAP メール、フォルダ、フラグが一覧表示されています。
移行範囲にZimbraコラボレーションデータが含まれる場合は、Zextras Backupを選択してください。IMAPメールボックスのコピーには、imapsyncを選択してください。

1. 必要なデータに一致するルートを選択してください。

ルート最適なフィット感何を計画すべきか
Zextrasのバックアップメールとサポートされているメールボックスおよびドメインデータが必要なZimbraからZimbraへの移行互換性のあるZimbra/Zextrasリリース、製品ライセンス、バックアップストレージ、およびCLI操作に精通したZimbra管理者
imapsyncZimbraを含むIMAPサーバー間でメールボックスをコピーする(メールボックスを1つずつ、または制御されたスクリプトで)。両サーバーにおけるIMAP接続性と認証情報、宛先フォルダのマッピング、およびメール以外のデータの個別移行

Zextrasが公開しているZimbra移行ガイドには、バックアップワークフローで移行できる項目として、メールとフォルダ、連絡先、カレンダー、タスク、共有フォルダ、設定、署名、ID、および一部のドメインまたはサービス種別データが記載されています。また、このワークフローでは、サーバー構成、LDAP構成、MTAまたはプロキシ構成、カスタムブランディングは移行されないとも記載されています。移行範囲は製品のバージョンと設定によって異なるため、上記のリストはあくまでも範囲チェックリストとして扱い、最新のドキュメントで必要な項目をそれぞれ確認してください。

ImapsyncはIMAPを介して動作します。メールボックスのフォルダとメッセージをコピーし、宛先がサポートするメッセージフラグを同期できます。ZimbraサーバーのLDAPディレクトリ、アカウント設定、カレンダー、アドレス帳、共有リソース、サーバー構成は転送されません。これらが重要な場合は、サポートされている別のエクスポート/インポート方法を検討するか、Zextrasを選択してください。

古い Zextras 移行ツールを基に新しい計画を立てないでください。Zextras移行ガイドには、このツールは既に利用できなくなっていると記載されています。また、アーカイブされた Zimbra ページから古い IMAP に関するアドバイスをコピーする場合は、最新の Zimbra imapsync FAQと照らし合わせて確認せずに使用しないでください。この FAQ では、古い Zimbra imapsync ガイドは既に古くなっていると明記されています。

2. データのコピー前に両方のサーバーを準備する

移行先のプロビジョニングを行う前に、ドメイン、アカウント、エイリアス、クォータ、メールボックスサイズ、ユーザーパスワードまたはリセットプラン、共有フォルダ、カレンダー、連絡先、配布リスト、保持要件、およびユーザーが依存するサーバー機能など、すべての項目をリストアップしてください。各フェーズで新しいメールを受信するホストを特定してください。このリストを移行後のチェックリストとして保管してください。

  • プラットフォームのサポート状況を確認してください。移行先がインストールされ、動作しており、移行パスでサポートされている Zimbra/Zextras の組み合わせで動作していることを確認してください。Zextras Backup の場合、ベンダーの Zimbra ワークフローでは、Zextras Backup の移行先と、Zextras Backup または Zimbra Suite Plus を実行している移行元が必要です。この機能を使用する前に、ベンダーにライセンスを確認してください。
  • 容量を確認してください。移行先のライブメールストア、ステージングされたソースバックアップまたはエクスポート、および移行先バックアップに必要な容量を見積もってください。Zextras移行ガイドでは、移行先にはこれら3つすべてに必要な容量が必要になる場合があると警告しています。ユーザーの表示可能なメールボックスの合計数だけで容量を決定しないでください。
  • バックアップと復元テストを実施してください。ソースの復元可能なバックアップを別途作成してください。Zextras の移行の場合は、インストール済みのバージョンのチェックとバックアップ手順に従ってください。imapsync の場合は、まず宛先にテスト用メールボックスを用意してください。imapsync のチュートリアルでは、宛先が変更される間、ソースが読み取られることが強調されています。
  • 接続性と認証をテストしてください。管理者またはテストユーザーが、意図したセキュア接続を使用して両方のIMAPエンドポイントにアクセスできることを確認してください。古いガイドに記載されているからといって、平文認証を有効にしないでください。ZimbraのリリースでサポートされているTLS/SSLおよび認証設定を使用してください。
  • DNSとメールフローを計画しましょう。MXレコードを変更する場合は、DNSプロバイダが許可していれば事前にTTLを短く設定し、移行中は古いサーバーを維持して、遅延配信やキャッシュ配信を監視して調整できるようにします。
暗いチェックリストパネルには、移行前の3つのチェック項目として、移行先アカウントのプロビジョニング、ソースバックアップの検証、IMAPアクセステストが表示されます。
移行を実行する前に、移行対象のアカウント、復元可能なソースバックアップ、およびimapsyncを使用する場所における正常に動作するIMAPアクセスを確認してください。

3. Zimbra対応の移行にはZextras Backupを使用する

この手順は、Zimbraシステム間を移行する管理者で、IMAPメール以上の機能を必要とする場合を想定しています。これは単一の汎用コマンドではなく、ソースおよび宛先の製品バージョン、バックアップパスの構成、権限、ストレージ、移行順序などが重要になります。Zextrasのガイドでは、zimbra特に明記されていない限り、CLIコマンドはユーザーとして実行する必要があるとされています。

ソースバックアップを作成して転送する

インストールされているリリースに対応した最新のZextras Backupガイドに従ってください。Zextras Zimbraのチュートリアルは、ソースの整合性チェックと詳細なSmartScanから始まります。コマンド例を以下に示します。実行する前に、コマンドの構文と必要なメンテナンス手順をバージョンに合わせて確認してください。

zxsuite backup doSmartScan start deep true

ソースデータのエクスポートが完了したら、必要なバックアップデータを宛先のステージングディレクトリに転送します。Zextrasでは、転送rsync方法として1つの選択肢が提示されており、ソースがアクティブな状態を維持したまま転送を繰り返すことで、後続の転送で変更されたデータのみが移動されるようにすることを推奨しています。宛先のステージングパスはZimbraユーザーが読み取り可能である必要があり、宛先のアクティブなZextras Backupパスと混同しないようにしてください。転送チャネルを保護し、各転送のログを記録してください。

Zimbraユーザーのターミナルプロンプトに、Zextras Backupのdeep SmartScanコマンドが表示されますが、コマンドの出力は表示されません。
ソース側の例では、詳細なSmartScanを開始します。画面にはコマンドのみが表示され、完了したスキャンは表示されません。

目的地でのプロビジョニングと復元

Zextrasでは、ドメイン、サービスクラス、アカウントを作成し、メールボックスの内容をスキップするプロビジョニング専用のインポートについて説明しています。これはセットアップ段階であり、完全なメール復元ではありません。

zxsuite backup doExternalRestore /path/for/data/ provisioning_only TRUE

プロビジョニング後、移行先でのテストで選択した同時実行設定を使用して、完全な外部リストアを実行します。Zextrasはconcurrent_accountsパラメータとして同時実行設定を提供し、すべてのサーバーに同じ数値が適合すると想定するのではなく、パフォーマンスをテストすることを推奨しています。移行期間中に加えられた変更を収集するために、必要に応じてソースバックアップの転送と適切な増分リストアを繰り返します。ユーザーとメールフローが検証されるまで、ソースは利用可能な状態に保ってください。

ベンダーは段階的および一段階実行型の手順を説明しており、それらの順序は切り替え計画によって異なります。異なるバージョンのコマンドを混在させるのではなく、インストールされているリリースの手順を使用してください。リストア処理中は、インポートされたバックアップデータやマップファイルを編集または削除しないでください。

Zimbraユーザーのターミナルプロンプトに、provisioning_only TRUEパラメータを指定したZextras外部復元コマンドが表示されます。
プロビジョニング専用コマンドは宛先アカウントを準備しますが、メールボックスの内容については別途完全復元段階が必要です。

4. スコープがIMAPメールの場合は、imapsyncを使用します。

Imapsyncは、送信元と送信先の両方のメールボックスがIMAP経由でアクセス可能で、Zimbra専用の移行製品をインストールせずにメッセージとフォルダをコピーしたい場合に便利です。Linux、Windows、macOSに対応しています。以下の例では、実際のサーバー名や認証情報ではなく、プレースホルダーを使用しています。パスワードは、保護されたスクリプトまたは承認されたその他の機密情報取り扱い方法に保存し、チケット、共有シェル履歴、記事などに公開しないでください。

まず、送信元メールボックス1つとテスト用宛先メールボックス1つを用意します。ドライランを使用して、宛先に書き込まずにログインをテストし、フォルダーマッピングを検査します。Imapsyncの公式チュートリアルでは、フォルダーのみの初期チェックに以下のオプションが示されています。

imapsync \
  --host1 SOURCE_IMAP --user1 USER --password1 SOURCE_SECRET \
  --host2 DEST_IMAP   --user2 USER --password2 DEST_SECRET \
  --automap --justfolders --dry

組織の安全な認証情報ワークフローを使用して、プレースホルダーを置き換えてください。送信元と送信先が意図したホストであること、両方のログインが成功すること、送信済み、下書き、ゴミ箱などのフォルダーが正しい宛先名にマッピングされていることを確認してください。マッピングが間違っている場合は、メッセージをコピーする前に修正してください。

ターミナルテンプレートには、送信元ホストと送信先ホスト、フォルダの自動マッピング、justfolders、およびドライランフラグを使用したimapsyncのドライランの例が表示されます。
ドライランテンプレートは、メールボックスの内容をコピーすることなく、エンドポイントへのアクセスとフォルダーのマッピングを確認します。

テストが正しければ、削除して--justfolders実際--dryのメールボックスのコピーを実行します。--automap提案されたマッピングがフォルダー名に合っている場合のみ、残してください。

imapsync \
  --host1 SOURCE_IMAP --user1 USER --password1 SOURCE_SECRET \
  --host2 DEST_IMAP   --user2 USER --password2 DEST_SECRET \
  --automap

ユーザー数が多い場合は、各メールボックスに対して、制御されたスクリプトを使用してテスト済みのコマンドを実行してください。プラットフォーム固有の構文とオプションについては、公式のimapsync チュートリアルとベストプラクティスを参照してください。意図的に削除を行い、使い捨ての宛先で結果をテストした場合を除き、破壊的なフラグ(例:--delete1や )の使用は避けてください--delete2。移行コピーによって、ソースメールや宛先専用データが予期せず消去されることはありません。

ターミナルテンプレートには、送信元アカウントと宛先アカウント、およびフォルダの自動マッピングを使用してIMAPメールをコピーするためのimapsyncコマンドの構成が表示されます。
フルコピーコマンドでは、図からパスワードが省略されています。認証情報は安全に指定し、ドライランが正しく行われたことを確認してから実行してください。

5. 最終的な差分同期を実行し、メールフローを切り替える

どちらのルートでも、最初の同期処理には時間がかかる場合があり、その間もユーザーは作業を続けることができます。最終同期は切り替え直前にスケジュールしてください。imapsyncを使用する場合は、テスト済みの同じコマンドを再実行してください。このツールは増分実行用に設計されており、通常は既に同期済みのメッセージはスキップされます。最終同期処理中は、可能な限りソースメールボックスを変更しないでください。ユーザーが既に両方のサーバーを使用している場合は、それらの相違点を個別に解決してください。imapsyncは双方向マージツールではありません。

Zextras Backup の場合は、バージョン固有の段階的インポート手順に従い、前回以降の変更を反映させるために必要なバックアップ転送/復元手順を繰り返してください。プロビジョニングのみでメール、カレンダー、連絡先がインポートされると想定しないでください。この手順では、メールボックスの内容はスキップされ、アカウント構造が作成されます。

宛先がメール受信の準備が整ったら、DNSとプロキシの設定に従ってMXレコードおよび関連するWebメールレコードを変更します。DNSキャッシュの有効期限が切れ、遅延したメールが到着するまで、古いサーバーを稼働させ続け、両方のシステムを監視します。メンテナンス期間を文書化し、各段階でユーザーが古いサーバーと新しいサーバーのどちらにログインすべきかを周知徹底します。

ターミナルテンプレートでは、操作に「最終デルタ同期」というラベルが付けられ、同じ imapsync ソースおよび宛先コマンドパターンが表示されます。
最終差分処理として、テスト済みのIMAP同期を再度実行し、最初のコピー時に受信したメールを含めます。

6. 古いサーバーを廃止する前に、新しいサーバーを検証する

代表的な小規模、大規模、最新、および古いメールボックスのセットをテストします。フォルダ一覧とメッセージ数を比較し、添付ファイル付きのメッセージを開き、既読/未読およびフラグ付きステータスを確認し、送信済みメールが目的のフォルダに表示されることを確認します。宛先へのメール送信と宛先からのメール送信の両方を行い、パブリックMXレコードのルックアップとサーバーログで、想定されるホストへの配信が確認できることを確認します。

Zextras の移行では、カレンダー、連絡先、タスク、共有、ID、署名、ユーザー設定、および対象範囲に含まれるドメインまたはサービス種別の設定を個別にテストしてください。Zextras では、共有の一貫性チェックについてドキュメント化されていますzxsuite backup doCheckShares。必要な場合、かつインストールされているリリースでサポートされている場合にのみ、対応する修復手順を使用してください。ユーザーアクセスとパスワードの動作を再確認してください。

関係者が結果を承認し、保持期間が終了するまで、ソースサーバーと復旧可能なバックアップを保持してください。宛先サーバーがログインを受け付けるという理由だけで、古いホストをキャンセルしないでください。メールルーティング、ユーザーアクセス、メール以外のデータ、ロールバック記録がすべて確認された後でのみ、プロジェクトを終了してください。

未チェックの検証チェックリストには、Zextrasルートの宛先を指すMXレコード、ユーザーログイン、フォルダとメッセージ、カレンダーと連絡先が記載されています。
チェックリストを使用して、配信状況とメールボックスの内容を確認してください。Zextrasルートが対象範囲にある場合は、カレンダーと連絡先をテストしてください。

情報源

コメントを残す

クライアントブラウザでのJitsi MeetにおけるCPU使用率の高さを修正する

クライアントブラウザでのJitsi MeetにおけるCPU使用率の高さを修正する

Jitsi MeetブラウザのCPUスパイクを診断し、ビデオタイル、カメラエフェクト、ブラウザグラフィック、ホスト設定をチェックすることで、クライアントの負荷を軽減します。

PrometheusとGrafanaを使用してJitsi Videobridgeのメトリクスを監視する方法

PrometheusとGrafanaを使用してJitsi Videobridgeのメトリクスを監視する方法

Jitsi Videobridgeに内蔵されたPrometheusエンドポイントを使用して、Jitsi Videobridgeの状態、会議の負荷、トラフィックを追跡し、Grafanaでデータを探索およびグラフ化できます。

Jitsi Meet Docker のカスタムドメイン名の設定方法

Jitsi Meet Docker のカスタムドメイン名の設定方法

Jitsi Meet Docker 用のカスタムドメインを、DNS、PUBLIC_URL、HTTPS、Let's Encrypt、ファイアウォールポート、NAT 設定、エンドツーエンド検証とともに構成します。

SSL更新後にZimbra管理コンソールで発生する404 Not Foundエラーを修正する

SSL更新後にZimbra管理コンソールで発生する404 Not Foundエラーを修正する

SSL更新後に発生するZimbra管理コンソールの404エラーを修正するには、正しいURLとポート、プロキシルーティング、サービスステータス、デプロイ済みの証明書、およびログを確認してください。

Nextcloudの「PHP OPcacheが正しく設定されていません」という警告を修正する

Nextcloudの「PHP OPcacheが正しく設定されていません」という警告を修正する

アクティブなPHP SAPI、サイズ制限、コメント、および再検証設定を確認することで、NextcloudのPHP OPcache構成警告を診断および修正する方法を学びましょう。

MySQLバージョンアップグレード後のKopanoデータベース移行エラーを修正する

MySQLバージョンアップグレード後のKopanoデータベース移行エラーを修正する

MySQLまたはMariaDBのアップグレード後にKopanoデータベースの移行が失敗した場合は、バックアップ、サーバーバージョン、SQLモード、文字セット、スキーマ状態、およびログを確認してトラブルシューティングを行います。

NextcloudでLDAPとActive Directory認証を設定する方法

NextcloudでLDAPとActive Directory認証を設定する方法

セキュアなトランスポート、ユーザーおよびグループフィルタ、ログイン属性、そしてテスト済みの展開機能を使用して、NextcloudをLDAPまたはActive Directoryに接続します。

GoogleサービスなしでElement Android通知を修正する方法:UnifiedPushガイド

GoogleサービスなしでElement Android通知を修正する方法:UnifiedPushガイド

UnifiedPush、Androidの権限設定、バッテリー設定、および信頼性の高い検証テストを設定することで、Googleサービスを削除した端末におけるElement Android通知の問題を修正します。

Nextcloudの「データベースに一部のインデックスが欠落しています」という警告を修正する

Nextcloudの「データベースに一部のインデックスが欠落しています」という警告を修正する

Nextcloudのデータベースインデックス不足警告を、公式のoccコマンドでクリアします。まずバックアップを作成し、変更内容をプレビューしてから修復を実行し、結果を確認してください。

Element WebでKeycloakを使用してシングルサインオン(SSO)を設定する方法

Element WebでKeycloakを使用してシングルサインオン(SSO)を設定する方法

Element Web 用の Keycloak SSO を設定するには、OIDC を Synapse に接続し、正確なコールバック URL を設定し、ユーザー クレームをマッピングし、ログアウトをテストします。