それ、レプリケーションでよろしく。UDPともども。

ポイント1 バックアップ サーバはどこに配置すべきか

まず、エージェントレス バックアップを行うには、バックアップサーバのほか、バックアップの代理サーバである、バックアップ プロキシが必要になります。その際にバックアップ サーバ兼プロキシサーバとして Windows サーバを新たに用意せず、台数節約のため、ドメイン コントローラー（以下 DC と略記）へ Arcserve UDP をインストールする構成を検討する方が多いようです。

この場合、バックアップ サーバの設置場所に関して、注意点が2つあります。

1つめがメモリ容量です。今回はエージェントレスバックアップが要件なので UDPコンソール が必須で、エージェントレス バックアップ用のプロキシ サーバも必要になります。これらの各コンポーネントには 8GB が必要なので、合計 16GB が必要になります。さらに重複排除も併用する場合は、復旧ポイントサーバが必要になるため 8GB のメモリ追加が必要で、さらに バックアップ対象 1TB あたり 1GB のハッシュ用メモリも必要になるため、合計で24GB以上のメモリが必要になります。(但し SSD を搭載するサーバ構成であればハッシュ用メモリは十分の１程度に節約できます) 詳細は「Arcserve Unified Data Protection 10.x サーバ構成とスペック見積もり方法」やブログ記事「【検証】入手困難な内蔵 SSD の代わりに「USB 接続 SSD」を Arcserve UDP のハッシュ領域に使えるか？」を参照してください。

2つめは、障害が起きた時にどこから復旧するかです。今回の要件として Hyper-V クラスタ上の仮想マシンを保護するわけですから、どのクラスタ構成ノードに障害が起きてもリストアできるよう、バックアップ サーバはクラスタ構成ノード以外に配置する必要があります。ということで、今回は DC にメモリを追加してバックアップ サーバを兼務させる構成としました。

ポイント2 DC にバックアップ サーバを兼務させる場合の注意点

規模が大きくなってくると、冗長性確保のため DC を複数サーバで運用するマルチ構成を組むケースもあるかと思います。この場合、普段はセカンダリ側の DC がリソースにも余裕がありバックアップ サーバとしては候補になりやすいのです。

ここで1点注意いただきたいのが、プライマリ DC に障害が発生した際の対処についてです。通常はこのような事態でもシステムを継続するためにセカンダリをプライマリに昇格して AD 管理を継続するのですが、セカンダリ側に Arcserve UDP がインストールされている場合、以下の技術文書に記載されている制約が出てきてしまいます。

「UDP エージェントを導入したノードのドメイン参加について」

簡単に言えば、プライマリ DC へ昇格させる場合、Arcserve UDP コンソールの再インストール（正確には Arcserve UDP が使用している SQL Server の再インストール）が必要になります。再インストールの理由は以下の制約によるものです。

「ドメイン コントローラーにSQL Serverをインストールする」

逆も同じで、DC を別のサーバに復旧するため、DC からメンバー サーバに降格する場合なども、Arcserve UDP コンソールの再インストールが必要になります。どこまでの障害を想定するかにもよりますが、冗長化構成の DC に Arcserve UDP をインストールする場合はご注意ください。

なお、今回はあくまで、仮想マシンのエージェントレス バックアップの動作確認を行うことが目的でしたので、DC にArcserve UDPをインストールして、前述の通りバックアップ サーバと兼任させています。

ポイント3 フェイルオーバー クラスタ マネージャの確認

では、バックアップ動作を確認するために必要なリソースを確認してみます。今回、作成したクラスタは "W2025-HV.arcserve.jp" というFQDN 名で、クラスタ環境上に作成した仮想マシン名は "VM1" としています。このクラスタは WSFC ですので、"VM1" はライブ マイグレーションにより クラスタ構成ノード間を稼働したまま移動することができます。

次は構成ノードです。"W2025-WSFC01" と "W2025-WSFC02" という２台の Hyper-V ホスト ノードでクラスタが構成されていることがわかります。

またバックアップを行う上でストレージの確認も重要なので、共有ディスクの構成を確認します。

クラスタの構成要素として必須なのが "クォーラム ディスク" です。また、"クラスタの共有ボリューム" は仮想マシンが保存されている領域です。Arcserve UDPでは、"クォーラム ディスク" をバックアップすることはできないので、"クォーラム ディスク" を含むクラスタ全体の保護には、Arcserve Backup が必要になります。今回は仮想マシンのみを Arcserve UDP で保護するお話なので Arcserve Backup の詳しいお話は別の機会に。興味ある方はこちらの資料をご覧ください。

「Arcserve Backupを使用したクラスタの復旧」

ポイント4 バックアップ タスクの設定とプランの作成/登録

さて、環境構築と確認も終わり、いよいよエージェントレス バックアップのタスクを作成するのですが、今回はDC にArcserve UDP 10.3 をドメイン管理者のアカウントを使用してインストールしています。この環境で Hyper-V クラスタの仮想マシンをバックアップする際、バックアップ タスクを定義する上で注意点が2つあります。

1つ目の注意点はバックアップ 対象ノード追加時の "インベントリ" の指定方法です。プランの作成時には、まず、エージェントレス バックアップに必要なタスク名、タスクの種類、バックアップ プロキシを入力した後、追加をクリックして、 "Hyper-Vからのノード追加" を選択します。

次に、Hyper-V クラスタのホスト名、接続アカウントを入力し、仮想マシンを検出するのですが、ここで注意点である "インベントリ" の選択が出てきます。このときクラスタ上の仮想マシンの検出には、"ストレージとVM" を必ず選択するようにしてください。"ホストとVM" を選択しても仮想マシンの検出はできますがプランの展開に失敗します。

ノードが検出されたらバックアップ対象を選択します。この図の例ではストレージ全体が選択されているので、仮想マシンの増減があっても自動的にバックアップする動作となります。また選択したストレージは、クラスタのどのノードにいてもパスが同じになっているので、ライブ マイグレーションなどで稼働するノードが変わってもバックアップ設定を変更することなくバックアップすることができます。デスティネーションとスケジュールを設定したらプランを保存します。

2つ目の注意点はプランの登録後です。この状態でもエージェントレス バックアップは動作するのですが、仮想マシンにログインができず警告が出てしまいます。仮想マシン上の "Hyper-V 統合サービス" を利用した処理（例えばアプリのオンライン バックアップなど）も想定するのであれば、仮想マシンへのログイン アカウントも追加で指定しておきます。

ここではノード一覧内に登録されている "Hyper-V グループ" のリストから "Hyper-Vクラスタ名"（画面ではW2025-HV） を選択し、右ウィンドウ内に表示された各仮想マシンを "更新" で開き、管理者アカウントを入力します。

以上で Hyper-V クラスタの仮想マシンのバックアップ準備は完了です

ポイント5 バックアップの実行

バックアップ実行中のログ画面を見てみると、保護対象が クラスタ上の仮想マシンであることが認識され "クラスタ モード" でバックアップされていること、クラスタ構成ノード以外にプロキシを配置しているので、バックアップがリモート モードで取得されていることがわかります。

バックアップ対象の仮想マシンが第2世代の EFI ブート構成の場合は、回復パーティション (FAT32) が含まれているため、警告が表示されます。

この警告はファイル単位の復旧に関するもので、回復パーティションはシステム復旧時にボリューム単位でリストアできます。このため、この警告は無視して構いません。詳細は以下の技術文書を参照してください。

警告 ID：10185 「FAT32 ボリューム のメタデータがバックアップされませんでした。」

では、次にライブ マイグレーションで仮想マシンを2番目のノード（Hyper-V ホスト）に移動し、バックアップを取得してみます。（以下の図では仮想マシン "VM1" の所有者ノードが "W2025-WSFC02" に変わっているのが分かります。）

クラスタ モードですので、仮想マシンが存在するノード（Hyper-V ホスト）が切り替わっても設定変更することなく、そのままバックアップが取得され、2回目のバックアップなので増分バックアップが取得されます。つまり最初はノード1でフル バックアップ、次はノード2で増分バックアップといった運用が可能になります。もちろん、同一仮想マシンのバックアップですから、データの連続性も確保された継続増分のバックアップとなります。

結論として、Hyper-V クラスタ環境の仮想マシンのバックアップには、以下のようなメリットがあることがわかります。

• エージェントレスだから、インストール作業は一切不要
• ストレージ単位で検出すれば、保護対象の VM が増減しても、自動的にバックアップ対象も変更してくれる
• 仮想マシンが稼働する Hyper-V ホストがライブ マイグレーションなどで移動しても、設定変更することなくバックアップが継続でき、さらに継続増分で仮想マシンをバックアップできる
• 「仮想マシンの復旧」機能で、仮想マシンの定義不要でクラスタ ストレージ上に簡単に復旧できる

リストア後は下図のように仮想クラスタ上の別名の仮想マシンとして復旧することができ、ライブ マイグレーションも可能です（ホスト名もネットワーク設定も同一なので、あたりまえですが）。

解説も、少々長くなりましたので、リストア手順の解説については、また別の機会に。。。以上、Hyper-V クラスタの仮想マシンでも簡単に便利にバックアップいただけることがご理解いただけたでしょうか。では、今回はこの辺で。

<関連記事>

Hyper-V仮想マシンのエージェントレス バックアップ、2つの方法。

Arcserve UDP 機能紹介 ～ (7) 仮想マシンのエージェントレス バックアップ ～