Azure Site Recovery（ASR）入門｜オンプレサーバーとAzure VMのDR設計・フェールオーバーテスト実践ガイド

オンプレのDR（Disaster Recovery）環境を持っているが、クラウド移行後に「Azureでのフェールオーバーはどう設計すればいいのか」と悩んでいるインフラエンジニアは多い。コールドスタンバイを組んでいるつもりでも、実際の障害時に本当に動くかどうか検証できていないケースも珍しくない。

この記事では、Azure Site Recovery（ASR）を使ったDR設計の基本を、オンプレ経験者にもわかりやすく解説する。対応シナリオ・主要コンポーネントから、Recovery Services Vaultの作成、テストフェールオーバーの実施手順、Azure Backupとの使い分けまで一気にまとめた。

なぜAzure Site Recoveryが必要なのか

オンプレ環境でのDR対策は、多くの場合「コールドスタンバイ」か「定期バックアップからのリストア」だった。どちらも課題が多い。

・コールドスタンバイ: 二次サイトのサーバーを平時は止めておく方式。コストは比較的抑えられるが、起動・切り替えに時間がかかり、RTO（目標復旧時間）が長くなりやすい
・ホットスタンバイ: 常時稼働の冗長サーバーを二次サイトに置く方式。RTOは短いが、ハードウェアコストが倍になる
・DRテストの難しさ: 本番環境を使わずにフェールオーバーを検証するのが困難。「たぶん動く」で運用しているケースが後を絶たない

Azure Site Recoveryはこれらの課題を次のように解決する。

・Azureが二次サイト代わりになるため、オンプレに別途DRサイトを持つ必要がない
・リアルタイムレプリケーションで、RPO（目標復旧時点）を数分以内に抑えられる
・テストフェールオーバーは本番を止めずにいつでも実行でき、DR訓練を定期的に実施できる

ASRがサポートするシナリオ

ASRは以下の4つのシナリオに対応している。

インフラエンジニアがよく使うのは「VMware → Azure」と「Azure VM → Azure（リージョン間）」の2パターンだ。以降の手順説明はAzure VMのリージョン間レプリケーションをベースに進めるが、VMwareシナリオも基本的な考え方は同じだ。

物理Linuxサーバーをレプリケーション元にする場合、ソース側へのMobility Serviceのインストール手順がWindowsと異なる。Linuxの基本操作については姉妹サイトLinuxMaster.JPも参考にしてほしい。

ASRの主要コンポーネント

ASRの構成を理解するには、以下のコンポーネントを把握しておく必要がある。

・Recovery Services Vault: ASRとAzure Backupを管理する中核リソース。レプリケーションポリシーやフェールオーバー設定はすべてここで管理する
・レプリケーションポリシー: クラッシュ整合性スナップショットの取得間隔（既定5分）とアプリ整合性スナップショットの保持期間を定義する
・Mobility Service（モビリティエージェント）: オンプレのVMや物理サーバーにインストールするエージェント。変更データをAzureへ継続的に転送する（Azure VM間では自動インストール）
・構成サーバー（VMware/物理シナリオのみ）: オンプレに置くWindowsサーバー。Mobility Serviceからのデータを受け取り、Azureへ送信する中継役だ。標準構成でプロセスサーバー機能も兼ねる
・レプリカ（ターゲットリソース）: フェールオーバー先のAzureリソース群。Recovery Services Vaultを作成したリージョンとは別リージョンに配置する

ASRの設定手順

1. Recovery Services Vaultの作成

Recovery Services Vaultはレプリケーション先のリージョンに作成する。たとえば東京リージョン（japaneast）のVMを大阪リージョン（japanwest）にレプリケーションするなら、Vaultは大阪リージョンに作成する。

# Azure CLI でRecovery Services Vaultを作成する例
VAULT_NAME="myRecoveryVault"
RG_NAME="myDR-RG"
LOCATION="japanwest"   # レプリケーション先リージョン

# リソースグループ作成
az group create --name $RG_NAME --location $LOCATION

# Recovery Services Vault作成
az backup vault create \
  --resource-group $RG_NAME \
  --name $VAULT_NAME \
  --location $LOCATION

Azureポータルからは「Recovery Services コンテナー」と表示される。検索バーで「recovery services」と入力すると見つかる。

2. レプリケーションの有効化（Azure VM間の場合）

Vaultを開き、「Site Recovery」→「Azure 仮想マシン」→「レプリケーションを有効にする」の順に進む。設定の主要な項目は以下のとおりだ。

・ソースリージョン: レプリケーション元のリージョン（例: 東京リージョン / japaneast）
・サブスクリプション・ソースリソースグループ: レプリケーション対象VMが属するグループ
・仮想マシン: レプリケーション対象のVMを選択
・ターゲットリージョン: フェールオーバー先リージョン（例: 大阪リージョン / japanwest）
・レプリケーションポリシー: クラッシュ整合性の取得間隔とアプリ整合性スナップショットの保持期間を設定

レプリケーションを有効にすると、まず初期レプリケーション（初回の全データ同期）が始まる。VMのディスクサイズによっては数時間かかることがある。初期同期が完了した後は、差分のみが継続的にレプリケーションされる。

ターゲット側のサブネット構成については、事前にAzure Virtual Network（VNet）のサブネット設計を見ておくと、ネットワーク設定時に迷わない。

3. テストフェールオーバーの実行

テストフェールオーバーは本番VMを止めることなく、フェールオーバー後の動作確認ができる重要な機能だ。ターゲット側に分離された仮想ネットワークを用意し、そこにフェールオーバー後のVMを起動して動作を検証する。

・Vaultの「レプリケートされたアイテム」から対象VMを選択
・「テストフェールオーバー」をクリック
・復旧ポイント（最新 / クラッシュ整合 / アプリ整合）を選択
・テスト用の分離された仮想ネットワークを指定
・フェールオーバー完了後、アプリケーションの動作を確認
・テスト終了後は「テストのクリーンアップ」を実行してテストVMを削除

本番環境への影響はゼロのまま、実際にAzureでVMが起動するかどうかを定期的に確認できるのがASRの最大の強みだ。DR計画の策定では最低でも半年に1回のテストフェールオーバーを実施することを強くすすめる。

ASRの料金体系（2026年9月時点）

ASRの料金はインスタンスごとの月額料金と、レプリケーションデータのストレージ料金の組み合わせだ。

重要なポイントは、フェールオーバー後にVMが実際に起動するまでの間は、ターゲット側のVMコンピューティングコストは発生しない点だ。レプリカ用マネージドディスクの料金は発生するが、VMの稼働コストはフェールオーバーして初めて課金される。

10台のVMをASRで保護する場合の概算（参考値）：
・インスタンス料金: $16 × 10台 = $160/月
・レプリカディスク（Standard SSD 128GBと仮定）: 約$10 × 10台 = $100/月
・データ転送（差分が月10GB/VMと仮定）: $0.02 × 100GB = $2/月

合計で月額$260程度が目安になる。実際の構成・ディスクサイズ・転送量により大きく変わるため、Azure Pricing Calculatorで事前見積もりを行うこと。

Azure BackupとASRの違い・使い分け

オンプレ経験者がよく混乱するのが、Azure BackupとASRの使い分けだ。同じRecovery Services Vaultからどちらもアクセスできるためなおさら紛らわしい。

実務では両方を組み合わせて使うのが正解だ。ASRはリージョン障害など大規模な障害に備えるDR用途、Azure Backupはデータ誤削除・ランサムウェア被害からの復元用途という位置づけで使い分ける。

運用設計のポイント

RPO・RTO目標の設定

ASRのレプリケーションポリシーでは以下の2種類の整合性ポイントを設定できる。

・クラッシュ整合性スナップショット: OSのメモリ状態は保存されず、ディスクのみの整合性。デフォルトで5分間隔。VMを突然シャットダウンしたときと同じ状態で復旧する。RPOは最大5分
・アプリ整合性スナップショット: VSS（Volume Shadow Copy Service）またはLinuxのカスタムスクリプトで取得。アプリのメモリ・トランザクションを含む整合性が保証される。既定で60分間隔（最短60分）

DBサーバーやトランザクション処理のあるアプリはアプリ整合性スナップショットを有効にしておくことが重要だ。クラッシュ整合性だけだと、フェールオーバー後にDBの整合性チェック・ロールバックが必要になる場合がある。

回復プランの活用

ASRの「回復プラン」（Recovery Plan）は、複数のVMを順序付けてフェールオーバーするオーケストレーション機能だ。Webサーバー→DBサーバー→アプリサーバーの順に起動するよう定義したり、Azure Automationのrunbookを組み込んでDNS切り替えを自動化したりできる。

複数VMで構成するシステムほど回復プランの恩恵は大きい。フェールオーバー手順書がコードとして管理できるため、オペレーションミスも防止できる。

フェールバックの設計

フェールバックとは、Azure側にフェールオーバーした後にオンプレへ戻す作業だ（Azure VM間のレプリケーションでは「リバースレプリケーション」とも呼ばれる）。フェールバックはフェールオーバーより複雑で、事前にオンプレ側へマスターターゲットサーバーを準備しておく必要がある（VMware/物理シナリオ）。

フェールバックまでを想定したDR訓練を年1回は実施することで、実際の障害時に慌てずに対応できる体制を整えておきたい。

よくあるトラブルと対処法

・「初期レプリケーションがなかなか完了しない」: ソースVMのネットワーク帯域が不足している可能性がある。専用の閉域接続がない場合は夜間など低トラフィック時間帯に初期レプリケーションが終わるよう計画する。Azure ExpressRouteの導入も検討の価値がある

・「テストフェールオーバー後にVMが起動しない」: ターゲット側の仮想ネットワーク設定（NSGルール、プライベートIPアドレス範囲）とソースVMの設定が一致していない可能性がある。テスト用の分離VNetを事前に作成し、ネットワーク設定を確認しておくこと

・「レプリケーション状態が警告になっている」: クラッシュ整合性またはアプリ整合性スナップショットの取得が失敗し続けていることが多い。VSS Writerの状態をソース側で確認し、VSS関連サービスが正常に動いているか確認する

・「フェールオーバー後のVMのIPアドレスが変わってしまう」: ASRのネットワーク設定でターゲット側の仮想ネットワーク・サブネットとIPアドレスをあらかじめ固定設定しておくことで対応できる。フェールオーバー後のDNS切り替えを自動化するためにも、IPアドレスは事前に固定しておくことをすすめる

まとめ

Azure Site Recoveryのポイントを整理する。

オンプレでDRサイトを別途持つコストと比べると、ASRを使ったAzure DRは大幅なコスト削減になることが多い。さらにテストフェールオーバーを定期実施できることで、DR計画の信頼性が格段に上がる。クラウド移行を進めるなら、早い段階でASRの設計をDR計画に組み込んでおくことをすすめる。