Backup Exec は販売終了となります。現在の所有者である Arctera は、2026 年 3 月 31 日をもって新規ライセンスの受付を停止し、2029 年 4 月 30 日をもって完全なサポート終了となります。現在 Backup Exec をご利用の場合は、サポート終了によってコンプライアンス体制や運用ツールに重大な影響が出る前に、代替製品の評価、選定、移行を行うための猶予期間（約 30 か月後）が設けられています。
このガイドでは、Backup Exec から Zmanda Pro への移行を、5 つの具体的なステップからなる構造化されたプロジェクトとして説明します。このガイドは、ベンダー評価を既に完了し、 Zmanda Proを採用することを決定している（または真剣に検討している）ことを前提としています。開始する前に注意点があります。これは移行であり、データ移行ではありません。どのバックアップ製品も Backup Exec の独自のカタログ形式を読み取ることができないため、古いバックアップを変換したりインポートしたりする必要はありません。
保持期間中は Backup Exec を読み取り専用モードにしておき、Zmanda Pro で新規に起動し、両方を並行して実行した後、システムを廃止します。主なコストは、その期間中に 2 つのシステムを運用することであり、大規模なデータ変換プロジェクトではありません。継続的な並行バックアップが必要ない場合は、そのコストもそれほど高くありません。60 日から 90 日の並行運用を計画し、社内の担当者 (実行手順書を管理する人) を任命し、このガイドの最後にある注意点に対応するための時間を確保してください。環境が小規模な場合はタイムラインを圧縮し、コンプライアンス保持要件や複雑なストレージ統合がある場合はタイムラインを拡張するものとして扱ってください。
移行の範囲を定めるために、Zmanda Proの無料トライアルを開始してください。
始める前に：移住が実際には移行である理由
どの代替製品を選択するかにかかわらず、Backup Execの移行には3つの現実が影響します。
- カタログの自動インポート機能はありません。 現在、バックアップベンダーでBackup ExecのMTF形式のカタログを読み取り、既存のバックアップ履歴を新しい製品にインポートするツールを提供しているところはありません。これはZmanda Proに限ったことではなく、このカテゴリ全体に当てはまります。現実的なBackup Exec移行モデルは、新しい製品を立ち上げる間はBackup Execを読み取り専用モードで実行し続け、新しい製品で新しいベースラインを取得し、新しいシステムが復元要件を満たすのに十分な履歴を蓄積したらBackup Execを廃止するというものです。
- 並列処理は必須であり、オプションではありません。 切り替え週末は移行計画ではありません。60日から90日間、両方のシステムを並行して稼働させ、新しい製品から毎週リストア検証を行う計画を立ててください。この期間中に、特定の環境における落とし穴（想定とは異なる方法でバックアップされるワークロード、想定どおりにルーティングされないネットワークパス、調整が必要な認証情報など）が明らかになります。
- 履歴データの保持に関するコンプライアンスは、データ移行とは別に重要な事項です。 バックアップデータを7年、10年、またはそれ以上の期間保持する法的または契約上の義務がある場合、Backup Execインフラストラクチャは、Backup Execの移行自体よりもかなり長い期間、アクセス可能な状態（読み取り専用モードで、隔離されたハードウェア上）を維持する必要がある場合があります。システムを廃止する前に、コンプライアンスおよび法務チームに保持要件についてご相談ください。
ステップ1：現在のBackup Execの展開状況を調査する
この手順の出力は、唯一の信頼できる情報源となるドキュメントです。この手順は飛ばさないでください。Backup Execへの移行プロセス全体を通して、このドキュメントを頻繁に参照することになります。
保護対象システムごとに、以下の文書を作成してください。
- ワークロードの種類（Windows Server、Linux Server、VMware VM、Hyper-V VM、SQLデータベース、Exchangeメールボックス、M365ユーザー、ファイル共有など）
- 保存期間要件（バックアップの保存期間。複数の保存ポリシーがある場合は、階層ごとに分類）。
- バックアップスケジュール（フルバックアップ、差分バックアップ、増分バックアップ）
- 保存先（ローカルディスク、NAS、テープライブラリ、クラウド、容量を含む）
- SLA/RTO要件を復元する
- アプリケーションに関連する設定（VSSライター、ログの切り捨て、エージェントレスかVM内エージェントか）
- バックアップ実行時間（他の操作と競合する場合に備えて、バックアップが実際に実行されるタイミング）
システムごとのインベントリに加えて、展開レベルの詳細も文書化してください。
- 監視ツール（SCOM、Nagios、PRTGなど）やチケット管理ツール（ServiceNow、Jiraなど）との連携
- テープライブラリ（モデル、スロット数、現在のメディア在庫、ローテーションスケジュール、オフサイトローテーションの有無）
- スクリプトによる自動化（PowerShellジョブ、スケジュールされたタスク、カスタム保持スクリプト）
- Arcteraまたは販売代理店との既存のサービス契約および更新日
- コンプライアンス文書要件（監査ログ、保管証明書など）
所要時間：一般的な中規模市場環境の場合、1～2週間。費やす時間は十分に価値がある。
ステップ2：必須アイテムとあれば良いアイテムを定義する
ステップ1で作成したインベントリを使用して、代替システムで絶対に譲れない要件と、必須ではないが望ましい要件を区別してください。このステップが存在する理由は、要件の肥大化が移行プロジェクトの失敗の主な原因となっているからです。必須要件を事前に確定しておかないと、組織内のどのチームもいずれは追加を提案し、プロジェクトは停滞してしまいます。
必須となる一般的なカテゴリには、ワークロードのカバー範囲（インベントリ内のすべてのシステムがサポートされていること）、復旧SLA（代替システムは既存のRTOを満たすこと）、コンプライアンス証明（ベンダーは監査人が必要とする文書を保有していること）、展開モデル（オンプレミスのみ、SaaS、またはハイブリッド）、価格予測可能性（公開された価格計算ツールが必要であり、見積もりゲートは不要である必要がある）などがあります。
テープが環境にとって不可欠な要件である場合、Zmanda Proはテープバックアップをネイティブにサポートしていないことにご注意ください。選択肢としては、Backup Execへの移行の一環としてテープからディスクへの移行を計画する（テープのオフライン分離の代替としてZmanda Proのエアギャップオフライン展開を使用する）か、Zmanda Proとは別に専用のソリューションでテープを保持するかのいずれかです。
予算権限を持つ担当者（通常はCFOまたはIT担当副社長）と監査権限を持つ担当者（通常はコンプライアンス部門、内部監査部門、またはセキュリティチーム）から、必須項目とあれば望ましい項目について承認を得てください。承認は書面で行い、プロジェクト文書に貼り付けてください。
ステップ3：Zmanda ProをBackup Execと並行してデプロイする
この段階での目標は、既存のBackup Exec環境に取って代わるのではなく、既存のBackup Exec環境と並行してZmanda Proを正常に動作させることです。「両方のシステムが稼働し、両方ともバックアップを実行する」状態を目指し、切り替え前に新しい製品を検証できるようにします。
展開手順：
3a. 導入モデルを決定します。Zmanda Proは、SaaS（Azure上で弊社がホスト）、オンプレミスオンライン（Linux環境：Debian 12、Ubuntu、またはRHELファミリーでホスト）、またはオンプレミスオフライン／エアギャップ（機密環境や厳格なコンプライアンス環境向けに完全に隔離）として利用可能です。ほとんどの中堅企業のお客様にとって、SaaSは試用版を迅速に導入できる最良の方法です。オンプレミスは、データ所在地の要件がある場合や、バックアップサーバーを完全に制御したい場合に適しています。
3b. Zmanda Proサーバーをデプロイします。SaaSの場合は、トライアル登録後数分以内にテナントがプロビジョニングされます。オンプレミスの場合は、OSの準備、パッケージのインストール、初期設定を含め、サーバーのデプロイに半日を予定してください。ドキュメントには、両方の手順が記載されています。
3c. 保護対象システムに Zmanda Pro クライアントをインストールします。クライアントのインストールは小規模（100 MB 未満）で、標準のパッケージマネージャ（Windows 用 MSI、Linux 用 .deb/.rpm、macOS 用 .pkg）を使用します。初回インストールにはシステムごとに 5 ～ 10 分程度かかります。これに加えて、通常の変更管理にかかる時間も考慮してください。保護対象システムが 100 台以上ある環境では、一括導入のために ZPAT（Zmanda Pro Automation Tool）を使用してください。
3d. ストレージの保存先を設定します。Zmanda Pro はストレージの種類を選ばず、ローカルディスク、SFTP、NAS (SMB/CIFS/NFS)、Zmanda Cloud Storage、AWS S3、Azure Blob、Google Cloud Storage、Wasabi、Backblaze B2、Storj、DigitalOcean Spaces、および S3 互換ストレージをサポートしています。ほとんどのお客様は、プライマリ (通常は速度重視のローカルディスクまたは NAS) とオフサイト (通常は 3-2-1 バックアップルールのクラウド) の 2 つの保存先を並行して設定します。
S3またはWasabiでオブジェクトロックコンプライアンスモードを有効にする場合は、このステップで不変ストレージを設定します。
3e. 既存の Backup Exec スケジュールを反映するバックアップ ポリシーを作成します。手順 1 で取得したインベントリを使用して、各 Backup Exec ジョブを Zmanda Pro ポリシーに変換します。ほとんどのワークロード (ファイル バックアップ、システム ステート、データベース、M365) では、これは簡単です。Backup Exec の特定の機能 (高度な VSS ライター構成、カスタム保持スクリプト) を使用するワークロードの場合は、Zmanda Pro で同等の動作を実現するのに時間がかかることを想定してください。
3f. 最初のフルバックアップを実行します。保護対象システムごとに最初のフルバックアップを実行します。Zmanda Proの永久増分アーキテクチャにより、この最初のフルバックアップが、今後取得する唯一のフルバックアップとなります。以降のバックアップでは、変更されたチャンクのみがキャプチャされます。最初のフルバックアップは、以降の実行よりも時間がかかります（多くの場合、かなり時間がかかります）。そのため、メンテナンス期間中にスケジュールしてください。
ステップ3にかかる時間：一般的な中規模企業環境では、ワークロード数とストレージの複雑さによって2～4週間かかります。この時間の大部分は、最初のフルバックアップに費やされます。
Backup Execの移行導入計画について、弊社のチームに調査を依頼したいですか？
Backup Exec環境をZmanda Pro導入プランに適合させるための30分間の無料相談をご利用いただけます。
ステップ4：Backup Exec移行中に60～90日間の並行期間を実行する
移行失敗のほとんどの原因はまさにここにあり、このガイドでも最も多くの時間を割いて説明しています。並行期間を省略したり、最初の数回のバックアップが問題なく完了したからといって短縮したりしないでください。
並行実行期間中は、Backup ExecとZmanda Proの両方が稼働します。両システムともスケジュールされたバックアップを実行します。Zmanda Proの動作を積極的に検証し、Backup Execはフォールバックとして引き続き稼働させます。
週ごとのペース：
- 月曜： 両システムにおける前週のバックアップ完了レポートを確認してください。Zmanda Proで発生した障害を調査してください。
- 水曜日： Zmanda Pro から少なくとも 1 回の復元テストを実行してください。復元するシステムをローテーションしてください (第 1 週: ファイル サーバー、第 2 週: SQL データベース、第 3 週: VM、第 4 週: M365 メールボックス)。本番環境への影響を避けるため、別の場所に復元してください。
- 金曜日： 不一致があれば調整してください。Backup ExecがバックアップしたデータをZmanda Proがバックアップしなかった場合（またはその逆の場合）、その理由を文書化し、そのギャップが許容範囲内か、設定で修正可能か、あるいは問題となるかを判断してください。
同時期に共通して発見された事柄：
- ステップ1のインベントリに含め忘れたワークロード（多くの場合、サービスアカウント専用のデータベース、または誰も所有していない単一目的の仮想マシン）
- Backup ExecではプリインストールされたVSSライターのおかげでサイレントに動作していたアプリケーション認識型バックアップだが、Zmanda Proでは明示的な設定が必要となる。
- Zmanda ProのサーバーとBackup Execのサーバーでルーティング方法が異なるネットワークパス（ファイアウォールルール、NAT、VPNセグメント）
- ストレージ性能の違い（既存のテープストレージやNASよりも高速または低速なクラウドストレージ先によって、バックアップ時間に影響が出る場合）
- 調整が必要な認証情報（異なるサービスアカウント、異なるLDAPグループ、異なるM365 OAuthスコープ）
各検出結果は、構成変更または文書化された例外のいずれかにつながるはずです。リストは常に更新してください。並行期間の終了までに、未解決の検出がゼロになり、異なるワークロードタイプで少なくとも8回の復元テストが成功している必要があります。
ステップ5：Backup Execからの移行のための切り替えと廃止
parallel-runがZmanda Proと既存のBackup Exec環境との互換性を検証したら、正式な切り替えの準備が整います。これは祝うべき時ではなく、規律を守るべき時です。
切り替え手順：
5a. 新しい Backup Exec ジョブのスケジュール設定を停止します。既存のスケジュール済みジョブは削除されず、一時停止されます。Backup Exec サーバーは、履歴復元保持要件の期間中 (通常は最低 30 ～ 90 日。コンプライアンス要件によってはそれ以上)、読み取り専用モードで稼働し続けます。
5b. Backup Execカタログの状態を文書化します。ジョブ履歴とカタログメタデータをエクスポートしてください。これは、切り替え前のバックアップを復元する必要がある場合に参照するものです。この文書は、BEサーバー本体と一緒に保管してください。
5c. 保持が義務付けられている過去のバックアップデータはアーカイブしてください。保持要件については、コンプライアンスチームおよび法務チームにご相談ください。規制対象業界の場合、これは元のBackup Execサーバーを起動可能な状態にしたまま、オフラインで数年間保持することを意味する場合があります。ほとんどの組織では、90日から180日間の読み取り専用アクセスで十分です。
5d. Backup Execインフラストラクチャを定められたスケジュールに従って廃止します。スケジュールには、BEサーバーの電源がオフになる日、基盤となるハードウェアが再利用または廃棄される日、BEに接続されているストレージが再利用または消去される日、Arcteraまたは販売代理店との間でBEライセンスが正式に終了される日を含める必要があります。各日付には担当者を指定する必要があります。
5e. ランブック、監視、および災害復旧に関するドキュメントを更新します。組織内で「Xのバックアップ方法」を文書化している箇所はすべて、Zmanda Proを参照するようにします。監視ダッシュボードは、Backup ExecではなくZmanda Proのジョブ失敗をアラートするように更新する必要があります。災害復旧計画では、Zmanda Proのリストア手順を参照するようにします。
ステップ5に必要な時間：2～4週間の作業に加え、Backup Execが読み取り専用スタンバイ状態となる履歴保持期間。
Backup Execの移行時に注意すべき一般的な落とし穴
Backup Execの移行時に、どの代替ベンダーを選択するかに関わらず、よく発生する問題：
「忘れられたワークロード」問題。ほぼすべての移行作業で、Backup Execによってバックアップされていたにもかかわらず、誰のインベントリにも登録されていなかったワークロードが少なくとも1つ見つかります。多くの場合、それはサービスアカウント専用のデータベース、数年前のプロジェクト中に作成された単発の仮想マシン、またはIT部門に知らせずにバックアップを有効にしたファイル共有です。これらのワークロードを発見するために、並列実行時間を十分に確保しておきましょう。
テープのみのデータ。他の場所に存在しないデータ（多くの場合、古い履歴アーカイブ）を含むテープバックアップがある場合は、別途決定する必要があります。テープライブラリを廃止する前にデータをディスクに抽出するか、保持義務を満たすのに十分な期間テープライブラリを稼働させ続けるかです。Zmanda Proは既存のBackup Execテープを読み取ることができません。これは、個別に計画する必要のある一方通行のブリッジです。
BE でサイレントに動作していたアプリケーション認識バックアップ。Backup Exec には、長年にわたり蓄積された VSS ライター統合機能とアプリケーション固有のヘルパーがあります。これらの一部は以前の管理者によって構成され、長年サイレントに動作していました。明示的な構成なしに、同じワークロードが Zmanda Pro で同じようにバックアップされると想定しないでください。ステップ 4 のリストア テストを使用して、ファイル レベルだけでなく、アプリケーション レベルのリカバリ可能性を確認してください。
ライセンスサイクルのタイミング。Backup Execのサービス契約更新時期が近づいている場合は、両製品の料金を必要以上に長く支払うことにならないよう、移行のタイミングを調整してください。ただし、更新料を節約するためだけに移行期間を短縮しないでください。移行が失敗した場合のコストは、部分的に重複する更新のコストを上回ります。
監査およびコンプライアンス文書のギャップ。監査担当者はBackup Execのレポートに慣れていますが、今後はZmanda Proのレポートを確認する必要があります。ステップ4で監査チームに概要を説明し、次回の監査サイクルで移行が予期せぬ事態にならないようにしてください。Zmanda Proは監査ログを標準形式でエクスポートし、セキュリティチームが必要とする場合はSIEMとの統合もサポートします。
Backup Execへの移行を開始する準備はできましたか？
Zmanda Proの無料トライアルを開始しましょう。既存のシステムと並行して、実際のバックアップを実行できます。
成功の様子
Backup Execへの移行が完了するまでに、以下の状態になっているはずです。環境内のすべてのワークロードタイプでリストアテストが検証された、文書化されたZmanda Proの導入。更新されたランブックと監視機能。文書化された履歴リストア手順を備えた、廃止された（または読み取り専用スタンバイの）Backup Execインフラストラクチャ。コンプライアンス要件を満たす、明確に定義されたストレージ宛先戦略。CFOに提示しても再交渉する必要のない、5年間のコスト数値。
次のような状態であってはなりません。未使用のまま稼働しているBEサーバー、誰も対処法を知らないテープ上の孤立したバックアップデータ、実際のリストア緊急事態中に発見されるバックアップ範囲のギャップ、または2029年にこの作業を繰り返すことを要求するベンダーとの関係。
Backup Execへの移行に関して、専門家の視点からサポートを受けたいですか？弊社のバックアップ専門家にご相談ください。
