Zimbra 9からZimbra 10（Daffodil）へのアップグレード方法（ステップバイステップ）

Zimbra 9 は、本番環境のメール プラットフォームとしてサポートされなくなりました。2026 年 10 月現在、Zimbra 9.0 はサポート終了となり、Zimbra 10.0 もサポート期間を過ぎています。現在アクティブな Daffodil ブランチは Zimbra 10.1 です。そのため、現在の Zimbra 9 アップグレード計画では、通常、10.0 で停止するのではなく、サポート対象の Zimbra 10.1 リリースをターゲットにする必要があります。この記事執筆時点では、Zimbra 10.1.21 は 2026 年 9 月 24 日にリリースされています。パッチ要件や既知の問題が変更される可能性があるため、本番環境での作業をスケジュールする前に、公式の Zimbra 10.1.21 リリース ノートを確認してください。

標準的なインストール環境であればアップグレード自体は簡単ですが、最適な方法はオペレーティングシステム、トポロジー、NGモジュール、カスタム認証、ライセンス、ダウンタイム許容度によって異なります。このガイドでは、コマンドだけでなくこれらの選択肢にも重点を置いているため、すべてのデプロイメントに同じ手順を強制するのではなく、環境に合った方法を選択できます。

本番環境に影響を与える前に、アップグレード戦略を選択してください。

Zimbraの現在のドキュメントには、NGモジュールを含む環境におけるインプレースアップグレードとローリングアップグレードのパスが記載されていますが、NGモジュールを使用しているユーザーは専用の移行リソースを参照するように指示されています。インストーラーがNGモジュールを検出した場合、安易にそのチェックをスキップしないでください。インストーラーは、続行するとNGパッケージと関連データが削除される可能性があると警告します。まずは、公式のDaffodilアップグレード手順と該当するNG移行ガイドを確認してください。

ステップ1：現在のZimbraのバージョンとサービスの状態を記録する

まず、基準値を設定します。ユーザーとしてログインしzimbra、インストールされているリリースと現在のサービス状態を記録してください。

su - zimbra
zmcontrol -v
zmcontrol status

サービスが既に障害を起こしている場合は、メジャーアップグレードの前にその問題を解決してください。アップグレード時に、LDAP、メールボックス、MTA、プロキシの問題がメンテナンス期間前に発生していたことが判明するのは好ましくありません。また、カスタム Zimlet、外部認証、統合、証明書、リレー ルール、スクリプト、およびローカルの変更をすべてインベントリしてください/opt/zimbra。

ステップ2：データベースの整合性チェックを実行し、バックアップを確認します。

Zimbraは特に、アップグレード前のチェックとして有用であるとされています。zmdbintegrityreportなぜなら、既存のMariaDBの破損は、メジャーバージョン変更時に診断がより困難になる可能性があるからです。zimbraストアノードでユーザーとして実行してください。

su - zimbra
zmdbintegrityreport

Zimbraによると、このレポートの作成にはデータベースのサイズとストレージのパフォーマンスに応じて数分から1時間かかる場合があります。大規模なメールストアでは、実行直前にスケジュールしないでください。

次に、エディションと環境に適したバックアップ方法を使用して、復元可能な完全なバックアップを作成します。バックアップは、保存場所が分かっていて、正常に完了し、実用的な復元計画がある場合にのみ役立ちます。Zimbraでは、データベーススキーマの変更が発生する可能性があるため、大規模なアップグレード作業の前に完全なバックアップを作成し、アップグレード後にもう一度完全なバックアップを作成することを推奨しています。

SAMLとSPNEGOのカスタマイズも個別にバックアップしてください。Zimbraは、これらのカスタマイズがアップグレード中に上書きされる可能性があると警告しています。カスタムファイルsalocal.cf.in、カスタムSpamAssassinルール、またはその他のローカルで管理されているファイルに依存している場合は、最新のリリースノートで置き換えられる可能性のあるファイルを確認し、開始前にコピーを保存してください。

ステップ3：複数サーバー展開の場合、役割の順序に従う

シングルサーバー環境の場合は、事前チェック後、インストーラーに直接進むことができます。マルチサーバー環境の場合は、インストール順序を厳守する必要があります。Zimbraのドキュメントに記載されている手順は、まずLDAPマスターサーバー、次にLDAPレプリカサーバー、MTAサーバー、プロキシサーバー、ライセンスデーモンサービス、OnlyOfficeサーバー、そして最後にメールストアサーバーの順です。

他の役割に進む前に、LDAPマスターをアップグレードして実行状態にしておく必要があります。ローリングアップグレード中、Zimbraは、Zimbra 10とそれ以前のバージョンのメールストアが共存する場合、メールストアzimbraReverseProxyUpstreamLoginServersにはZimbra 10のメールボックスサーバーのみを含める必要があると警告しています。そうでない場合、Zimbra 10のメールストアを使用しているユーザーは、モダンWebアプリへのログインで問題が発生する可能性があります。

ステップ4：オペレーティングシステム、空き容量、ライセンスを確認する

Zimbra 9 サーバーのオペレーティングシステムが 2026 年になってもまだ適切なターゲットであると想定しないでください。現在の Zimbra のドキュメントでは、RHEL/Rocky/Oracle Linux 9 や Ubuntu 22.04 など、より新しいサポート対象プラットフォームが示されています。Ubuntu 24.04 のサポートは Zimbra 10.1.17 で一般提供が開始されました。Zimbra 10.1.21 のリリースノートには、Ubuntu 18.04 のサポートが次期リリースから廃止されることも記載されています。Zimbra 9 ホストが古いプラットフォームで稼働している場合は、Zimbra の大幅な変更とオペレーティングシステムの移行を同時に行うよりも、新規インストールと移行を行う方が賢明かもしれません。

インストーラーを実行する前に、空き容量を確認してください。Zimbraのインストーラーは空き容量をチェックし、システムに十分な空き容量がない場合は停止します。

Zimbra 10.1ではライセンスも変更されました。旧license.xml形式のライセンスは10.1ではサポートされていません。インストールまたはアップグレードの前に、新しい18～26文字の英数字ライセンスキーが必要です。メンテナンス期間が始まる前に、Zimbraから正しいキーを入手してください。Zimbraの公式ダウンロードページには、開始前に新しいv10.1ライセンスを用意しておくよう、お客様への注意喚起が明記されています。

ステップ5：正しいZimbra 10.1ビルドをダウンロードする

サポートされているオペレーティングシステムと CPU アーキテクチャに一致するパッケージを Zimbra の公式ダウンロードエリアからダウンロードしてください。他のディストリビューション用に作成されたパッケージを再利用しないでください。アーカイブは、などの作業ディレクトリに保存してください/var/tmp。

Zimbraがダウンロードしたパッケージのチェックサムを公開している場合は、アーカイブを展開する前にそれを検証してください。ローカルでのチェックサムの計算は次のようになります。

sha256sum zcs.tgz

図に示されているチェックサムはリリースチェックサムではありません。実際のパッケージに付属のチェックサムのみを使用してください。

ステップ6：アーカイブを解凍し、アップグレードインストーラーを起動します。

Zimbraのドキュメントに記載されているインプレースプロセスでは、アップグレード前にサービスを手動で停止する必要はありません。インストーラーが必要に応じてサービスを停止および開始します。rootダウンロードしたアーカイブを解凍し、展開されたディレクトリに移動して、次のコマンドを実行しますinstall.sh。

cd /var/tmp
tar xzvf zcs.tgz
cd <expanded-directory>
./install.sh

screenZimbraは、特にリモートSSHセッションでは、接続が切断されても長時間のアップグレードが中断されないように、などのターミナルマルチプレクサ内でアップグレードを実行することを推奨します。

screen ./install.sh

ステップ7：インストーラーのプロンプトに意図的に答える

インストーラーは既存のZimbraインストールを検出し、アップグレードパスを表示します。Zimbraの現在の手順では、プロンプトが表示されたらZimbraパッケージリポジトリの使用を承認し、アップグレードを実行することを確認するように指示されています。シングルノードの10.1アップグレードでは、このzimbra-license-daemonパッケージが必須です。これを拒否すると、アップグレードが続行されません。

最終プロンプトに回答する前に、パッケージリストを確認してください。バックアップ、ライセンス、パッケージソース、ストレージ、およびメンテナンス通信がすべて正しく設定されていることを確認してからThe system will be modified. Continue? [N]、Enterキーを押してくださいY。インストーラーは、古いサービスを停止し、パッケージを置き換え、構成を復元し、アップグレード作業を実行し、サービスを再起動します。大規模な環境では、小規模なテストシステムよりもかなり時間がかかる場合があります。

オフライン/手動ライセンスを使用する場合は、Zimbraの最新アップグレードガイドに記載されている特定の認証手順に従ってください。オンラインライセンスの手順をオフライン環境にコピーしないでください。同様に、メールボックスノードの認証チェックに関する手順は異なるため、以前のリリースからコピーした古いコマンドではなく、バージョン固有のドキュメントを参照してください。

ステップ8：サービス、バージョン、メールフロー、およびクライアントアクセスを確認する

インストーラーが完了したら、ユーザーに戻りzimbra、サービスの状態とインストール済みのリリースを確認してください。

su - zimbra
zmcontrol status
zmcontrol -v

次に、ユーザーが実際に依存する動作をテストします。具体的には、受信および送信SMTP、内部配信、有効になっている場合はIMAP/POP、モダンおよびクラシックWebアプリのログイン、委任されたメールボックス、カレンダー操作、モバイル同期、ライセンスされている場合はOutlook接続、外部認証、Zimlet、バックアップ、監視、およびZimbra SOAPまたはEWSインターフェースを使用するすべてのアプリケーションです。

リリース固有のアップグレード後のアクションはスキップしないでください。Zimbra 10.1.19 以降のリリース ノートでは、10.0.x、9.0.x、または 8.8.15 からアップグレードするお客様向けに更新された SNMP 緩和策について説明しています。2026 の運用環境へのアップグレードの場合は、最新のパッチ ノートを読み、メジャー アップグレード後に必要な緩和策を適用してください。Zimbra 10.1.21 には、Classic Web Client、WebDAV 認証、パスワード回復、OpenJDK、NGINX、および統合に影響を与えるセキュリティ修正も含まれており、これも古い 10.0 ビルドで止まらない方が良い理由の一つです。

現状維持ではなく、進路を変更すべきタイミングはいつですか？

既存設備の改修は、変更する可動部品が少ないため魅力的ですが、必ずしもリスクが低い選択肢とは限りません。以下のいずれかの条件に該当する場合は、計画を再検討してください。

• 現在使用されているオペレーティングシステムは非推奨であるか、Zimbraのサポート終了が間近です。
• データベースの整合性チェックで、説明のつかないエラーが報告されました。
• NGモジュールを導入しているにもかかわらず、サポートされている移行手順を検証していません。
• SAML、SPNEGO、Zimlets、ウイルス対策/スパム対策のカスタマイズ、またはサードパーティ統合は業務上重要であり、10.1 に対してテストされていません。
• 同時に、ストレージアーキテクチャ、ホスト名、ネットワーク設計、またはハードウェアも変更することになります。
• メンテナンス期間前に必要な10.1ライセンスを取得することはできません。

そのような場合、制御された移行を伴う並行したZimbra 10.1環境は、より多くの準備を必要とするかもしれませんが、より明確なロールバック境界を提供し、基盤となるプラットフォームを最新化するためのより良い機会となります。

実用的なアップグレードチェックリスト

• Zimbra 9の正確なバージョンと現在のサービス状態を確認してください。
• 最新の10.1リリースノートと公式アップグレードガイドをご確認ください。
• zmdbintegrityreportストアノード上で実行し、エラーを解決します。
• 完全バックアップを作成して検証し、カスタム認証およびフィルタリング設定を保存します。
• ターゲットとなる10.1リリースが、宛先OSでサポートされていることを確認してください。
• 新しい10.1ライセンスキーを入手してください。古いキーに頼らないでくださいlicense.xml。
• ディスク容量を確認し、適切なプラットフォームパッケージをダウンロードしてください。
• 複数サーバー構成の場合は、ドキュメントに記載されている役割の順序に従ってください。
• インストーラーを、screenまたは同等の永続的なターミナルセッションで実行してください。
• サービス、バージョン、メールフロー、Webクライアント、認証、統合、および監視を検証します。
• バージョン固有のアップグレード後対策を適用し、新しい完全バックアップを作成します。

結論

標準構成でサポート対象のオペレーティングシステム上で正常に動作しているZimbra 9サーバーの場合、最新のZimbra 10.1 Daffodilブランチへのインプレースアップグレードが通常最も直接的な方法です。古いOS、複雑なNGモジュール展開、または大規模なインフラストラクチャ変更が必要なサーバーの場合は、より多くの作業が必要になりますが、新規インストールと移行の方が運用上の境界が明確になる可能性があります。

重要な品質チェックは、単に処理install.shが最後まで完了するかどうかだけではありません。アップグレードが成功したということは、サーバーがサポートされている10.1パッチが適用され、必要なすべてのサービスが正常に動作し、メールフローとユーザーアクセスが期待どおりに機能し、カスタム統合が再テストされ、ライセンスが有効で、バージョン固有の対策が完了し、アップグレード後の最新のバックアップが作成されていることを意味します。計画中は、公式のZimbra Daffodilアップグレードガイド、最新の10.1.21リリースノート、および公式のマルチサーバードキュメントを開いておくようにしてください。これらの資料は、古いコマンドスニペットよりも優先されるべきです。