一般的な質問:Azure から Azure へのディザスター リカバリー

この記事では、Azure Site Recovery サービスを使用した Azure 仮想マシンの別の Azure リージョンへのディザスター リカバリーについてよく寄せられる質問に回答します。

全般

Site Recovery の価格

Azure 仮想マシンのディザスター リカバリーのコストについて学習します。

Free レベルのしくみを教えてください。

Site Recovery で保護されるすべてのインスタンスは、保護を開始してから 31 日間は無料になります。 この期間が経過すると、各インスタンスは料金の詳細にまとめられた料金で保護されます。 Azure 料金計算ツールを使用してコストを見積もることができます。

最初の 31 日間に、その他の Azure 料金は発生しますか?

はい。 Azure Site Recovery では、最初の 31 日間、インスタンスは無料で保護されますが、Azure Storage、ストレージ トランザクション、データ転送については料金が発生する場合があります。 復旧された VM からも、Azure のコンピューティングの料金が発生する場合があります。

Azure 仮想マシンのディザスター リカバリーを開始するにはどうすればよいですか?

1. Azure 仮想マシンのディザスター リカバリー アーキテクチャを理解する。
2. サポート要件を確認する。
3. Azure 仮想マシンのディザスター リカバリーを設定する。
4. テスト フェールオーバーでディザスター リカバリーのテストを実行する。
5. セカンダリ Azure リージョンへの完全フェールオーバーを実行する。
6. セカンダリ リージョンからプライマリ リージョンにフェールバックする。

ターゲット リージョンの容量を確保するにはどうすればよいですか?

十分なインフラストラクチャ容量が確保されるよう、Site Recovery チームと Azure 容量管理チームが計画を立てます。 フェールオーバーを開始するときに、これらのチームは、Site Recovery によって保護される想マシン インスタンスがターゲット リージョンにデプロイされるようにするための支援も行います。

レプリケーション

ディスク暗号化を使用して仮想マシンをレプリケートできますか?

はい。 Site Recovery では、Azure Disk Encryption (ADE) が有効になっている仮想マシンのディザスター リカバリーがサポートされています。 レプリケーションを有効にすると、Azure では、必要なすべてのディスク暗号化キーとシークレットがユーザー コンテキストでソース リージョンからターゲット リージョンにコピーされます。 自分に必要なアクセス許可がない場合、セキュリティ管理者がスクリプトを利用し、キーとシークレットをコピーできます。

• Site Recovery では、Windows を実行する Azure 仮想マシンの ADE がサポートされています。
• Site Recovery は次をサポートします。
  • ADE バージョン 0.1。Microsoft Entra ID を必要とするスキーマがあります。
  • ADE バージョン 1.1。Microsoft Entra ID は必要ありません。 バージョン 1.1 の場合、Microsoft Azure 仮想マシンにはマネージド ディスクが必要です。
  • 拡張スキーマの詳細について、詳細を確認してください。

暗号化された仮想マシンのレプリケーションの有効化については、こちらを参照してください。

その他の暗号化フィーチャーのサポートについては、 サポート マトリックス を参照してください。

別のリソース グループから Automation アカウントを選択できますか?

レプリケートされた Azure 仮想マシンで実行されている Mobility Service 拡張機能の更新を Site Recovery が管理できるようにすると、Azure Automation アカウントを使用して (Azure サービスによって使用される) グローバル Runbook がデプロイされます。 Site Recovery が作成する Automation アカウントを使用するか、既存の Automation アカウントを使用するように選択することができます。

現在、ポータルでは、コンテナーと同じリソース グループ内の Automation アカウントのみを選択できます。 PowerShell を使って、別のリソース グループから Automation アカウントを選択できます。 自動更新の有効化の詳細について、詳細を確認してください。

コンテナー リソース グループに含まれていない顧客の Automation アカウントを使用している場合、既定の Runbook を削除できますか?

はい、不要な場合は削除できます。

ディザスター リカバリーのために Azure Site Recovery によって保護されているサーバー上のカーネル ファームウェアをアップグレードすると、何らかの影響がありますか?

いいえ。サーバーは Azure Site Recovery によって既に保護されているため、進行中のレプリケーションには何の影響もありません。

仮想マシンを別のサブスクリプションにレプリケートできますか?

はい、同じ Microsoft Entra テナント内で任意のサブスクリプションに Azure 仮想マシンをレプリケートできます。 仮想マシンのディザスター リカバリーを有効にすると、既定では、表示されるターゲット サブスクリプションはソース仮想マシンのサブスクリプションとなります。 ターゲット サブスクリプションを変更でき、その他の設定 (リソース グループ、仮想ネットワークなど) は、選択したサブスクリプションから自動的に設定されます。

可用性ゾーン内の仮想マシンを別のリージョンにレプリケートすることはできますか?

はい、可用性ゾーン内の仮想マシンを別の Azure リージョンにレプリケートすることができます。

非ゾーンの仮想マシンを同じリージョン内のゾーンにレプリケートすることはできますか?

これはサポートされていません。

ゾーンのある仮想マシンを、同じリージョン内の別のゾーンにレプリケートできますか?

このサポートは、いくつかのリージョンに制限されています。 詳細については、こちらを参照してください。

レプリケーションからディスクを除外できますか?

はい、PowerShell を使用して、レプリケーションを設定するときにディスクを除外できます。 ディスクの除外の詳細については、こちらをご覧ください。

レプリケートされた仮想マシンに追加された新しいディスクをレプリケートできますか?

マネージド ディスクがあるレプリケートされた仮想マシンでは、新しいディスクを追加し、それらに対するレプリケーションを有効にすることができます。 新しいディスクを追加すると、レプリケートされた仮想マシンに、仮想マシン上の 1 つ以上のディスクで保護が使用できることを示す警告メッセージが表示されます。

• 追加されたディスクのレプリケーションを有効にすると、初回のレプリケーション後に警告は表示されなくなります。
• ディスクのレプリケーションを有効にしない場合、この警告を無視できます。
• ディスクが追加された仮想マシンをフェールオーバーする場合、レプリケーション ポイントには回復に使用できるディスクが表示されます。 たとえば、ディスクが 1 つある仮想マシンに 2 つ目のディスクを追加する場合、追加する前に作成されたレプリケーション ポイントでは、"1/2 台のディスク" と表示されます。

Site Recovery では、レプリケートされた仮想マシンからディスクを "ホット リムーブ" できません。 仮想マシンのディスクを削除する場合は、仮想マシンのレプリケーションを無効にしてから再度有効にする必要があります。

どのくらいの頻度で Azure にレプリケートできますか?

Azure 仮想マシンを別の Azure リージョンにレプリケートするときは、レプリケーションは継続的に行われます。 プロセスの詳細を確認する。

リージョン内で非ゾーンの仮想マシンをレプリケートできますか。

Site Recovery を使用し、リージョン内で非ゾーンの仮想マシンをレプリケートすることはできません。 ただし、ゾーンのあるマシンを、同じリージョン内の別のゾーンにレプリケートできます。

仮想マシン インスタンスを任意の Azure リージョンにレプリケートできますか?

任意の 2 つのリージョン間で仮想マシンをレプリケートして、復旧できます。

Site Recovery にはインターネット接続が必要ですか?

いいえ、ただし、仮想マシンには Site Recovery の URL と IP 範囲へのアクセスが必要です。 詳細情報。

リソース グループ間で階層化されたアプリケーションをレプリケートできますか?

はい、アプリをレプリケートし、別のリソース グループにディザスター リカバリー構成を保持することは可能です。

たとえば、異なるリソース グループにアプリが 3 つの層 (アプリケーション/データベース/Web) を持つ場合、すべての層を保護するためにレプリケーションを 3 回有効にする必要があります。 Site Recovery によって、3 つの層が 3 つの異なるリソース グループにレプリケートされます。

リソース グループとの間でストレージ アカウントを移動できますか?

いいえ、これはサポートされていません。 ストレージ アカウントを別のリソース グループに誤って移動し、元のリソース グループを削除した場合は、古いリソース グループと同じ名前で新しいリソース グループを作成し、そのストレージ アカウントをこのリソース グループに移動できます。

Replication policy

レプリケーション ポリシーとは何ですか?

レプリケーション ポリシーでは、復旧ポイントの保持履歴と、アプリ整合性スナップショットの頻度が定義されています。 Site Recovery では、次のように既定のレプリケーション ポリシーが作成されます。

• 復旧ポイントを 1 日間保持します。
• アプリ整合性スナップショットは無効化され、既定では作成されません。

レプリケーション設定については、こちらを参照してください。

クラッシュ整合性復旧ポイントとは何ですか?

クラッシュ整合性復旧ポイントには、スナップショットの作成中にサーバーから電源コードが引き抜かれたときのディスク上のデータが含まれます。 これには、スナップショットの作成時にメモリ内にあったものは一切含まれません。

現在、ほとんどのアプリでは、クラッシュ整合性スナップショットから十分に復旧できます。 クラッシュ整合性復旧ポイントは、データベースのないオペレーティング システムや、ファイル サーバー、DHCP サーバー、プリント サーバーなどのアプリにとっては十分です。

Site Recovery では、5 分ごとにクラッシュ整合性復旧ポイントが自動的に作成されます。

アプリケーション整合性復旧ポイントとは何ですか?

アプリ整合性復旧ポイントは、アプリ整合性スナップショットから作成されます。 ここでは、クラッシュ整合性スナップショットと同じデータがキャプチャされ、メモリ内のデータと処理中のすべてのトランザクションが追加でキャプチャされます。

追加コンテンツのため、アプリ整合性スナップショットは最も複雑となり、時間がかかります。 アプリ整合性の復旧ポイントは、データベース オペレーティング システムや、SQL Server などのアプリで推奨されます。 Windows の場合、アプリ整合性スナップショットでは、ボリューム シャドウ コピー サービス (VSS) が使用されます。

アプリ整合性復旧ポイントはパフォーマンスに影響しますか?

アプリ整合性復旧ポイントではメモリとプロセス内のすべてのデータがキャプチャされるため、キャプチャが頻繁になる場合は、ワークロードが既にビジー状態のときにパフォーマンスに影響を与える可能性があります。 データベース以外のワークロードについては、あまり頻繁にはキャプチャしないことをお勧めします。 データベース ワークロードの場合でも、1 時間で十分です。

アプリ整合性復旧ポイントを生成するための最小間隔はどれくらいですか?

Site Recovery では、アプリ整合性復旧ポイントを最小間隔の 1 時間で作成できます。

Linux 仮想マシンでアプリ整合性レプリケーションを有効にすることはできますか?

はい。 Linux 用モビリティ エージェントは、アプリ整合性のためのカスタム スクリプトをサポートしています。 エージェントでは、pre オプションと post オプションを使用したカスタム スクリプトが使用されます。 詳細情報

復旧ポイントはどのように生成されて保存されますか?

Site Recovery で復旧ポイントを生成する方法を理解するため、例を使ってみましょう。

• レプリケーション ポリシーでは、復旧ポイントが 1 日間保持され、アプリ整合性のスナップショットが 1 時間ごとに取得されます。
• Site Recovery では、5 分ごとにクラッシュ整合性復旧ポイントが作成されます。 この頻度は変更できません。
• Site Recovery では、2 時間後に復旧ポイントが取り除かれて、1 時間に 1 つの復旧ポイントが保存されます。

そのため、最新の 2 時間では、図に示すように、24 のクラッシュ整合性ポイントと 2 つのアプリ整合性ポイントから選択できます。

過去のどの時点まで遡って復旧できますか?

使用できる最も古い復旧ポイントは、マネージド ディスクでは 15 日、アンマネージド ディスクでは 3 日です。

復旧ポイントはどのように取り除かれますか?

クラッシュ整合性復旧ポイントは、5 分ごとに生成されます。 アプリ整合性スナップショットは、ユーザーが入力した頻度に基づいて生成されます。 2 時間を過ぎると、ユーザーが入力したリテンション期間に基づいて復旧ポイントが取り除かれます。 以下がこのシナリオです。

入力されたリテンション期間	排除のメカニズム
0 日	復旧ポイントは保存されません。 最新のポイントにのみフェールオーバーできます
1 日	最新の 2 時間を過ぎると 1 時間に 1 つの復旧ポイントが保存されます
2 から 7 日	最新の 2 時間を過ぎると 2 時間に 1 つの復旧ポイントが保存されます
8 から 15 日	7 日間は、最新の 2 時間を過ぎると 2 時間に 1 つの復旧ポイントが保存されます。 その後は、4 時間に 1 つの復旧ポイントが保存されます。 また、アプリ整合性スナップショットは、上記の表に記載された期間に基づいて取り除かれます。これは、入力されたアプリ整合性スナップショットの頻度がそれより低い場合でも行われます。

Site Recovery で 1 日を過ぎても復旧ポイントを生成できない場合はどうなりますか?

レプリケーション ポリシーが 1 日であり、Site Recovery で 1 日を過ぎても復旧ポイントを生成できない場合、古い復旧ポイントが残ります。 Site Recovery は、新しいポイントが生成された場合、最も古いポイントのみを置き換えます。 新しい復旧ポイントができるまで、リテンション期間に到達した後も古いポイントはすべて残ります。

レプリケーションを有効にした後で、レプリケーション ポリシーを変更できますか?

はい。 コンテナー >>>> で、ポリシーを選択して編集します。 変更は既存のポリシーにも適用されます。

すべての復旧ポイントは完全な仮想マシンのコピーですか?

生成される最初の復旧ポイントには、完全なコピーがあります。 それ以降の復旧ポイントでは、差分変更が保持されます。

復旧ポイントのリテンション期間の増加によってストレージ コストが増加しますか?

はい。 たとえば、リテンション期間を 1 日から 3 日に増やした場合、Site Recovery により追加の 2 日分の復旧ポイントが保存されます。 追加された時間によって、ストレージの変更が発生します。 以前は、1 日間、1 時間ごとに復旧ポイントを保存していました。 現在では、3 日間、2 時間ごとに復旧ポイントを保存しています。 復旧ポイントの排除に関する説明を参照してください。 そのため、追加で 12 の復旧ポイントが保存されます。 単なる例として、1 つの復旧ポイントに 10 GB の差分変更が含まれ、GB あたりのコストが 0.16 ドル/月の場合、1 か月あたり 1.60 ドル * 12 の追加料金が発生します。

マルチ VM 整合性

マルチ VM 整合性とは何ですか?

マルチ VM 整合性によって、レプリケートされた仮想マシン間で復旧ポイントに整合性が確保されます。

• マルチ VM 整合性を有効にすると、Site Recovery によってオプションが有効なすべてのマシンのレプリケーション グループが作成されます。
• レプリケーション グループのマシンをフェールオーバーすると、それらのマシン間でクラッシュ整合性復旧ポイントとアプリ整合性復旧ポイントが共有されます。

マルチ VM 整合性を有効にする方法については、こちらを参照してください。

レプリケーション グループ内の 1 つの仮想マシンをフェールオーバーできますか?

いいえ。 マルチ VM 整合性を有効にすると、アプリがレプリケーション グループ内のすべての仮想マシンに依存関係を持つと推測され、単一の仮想マシンのフェールオーバーは許可されません。

1 つのグループでまとめてレプリケートできる仮想マシンの数はいくつですか?

レプリケーション グループ内の 16 個の仮想マシンをまとめてレプリケートできます。

どのようなときにマルチ VM 整合性を有効にする必要がありますか?

マルチ VM 整合性では CPU が集中的に消費されるので、これを有効にすると、ワークロードのパフォーマンスに影響する場合があります。 仮想マシンが同じワークロードを実行していて、複数のマシン間に整合性を持たせる必要がある場合にのみ有効にしてください。 たとえば、2 個の SQL Server インスタンスと 2 個の Web サーバーがアプリケーション内にある場合、SQL Server インスタンスに対してのみマルチ VM 整合性を有効にします。

レプリケートされている仮想マシンをレプリケーション グループに追加できますか?

仮想マシンのレプリケーションを有効にすると、新しいレプリケーション グループまたは既存のグループに追加できます。 既にレプリケートされている仮想マシンをグループに追加することはできません。

マルチ VM 整合性の回復計画を作成するには、どのような条件を満たす必要がありますか?

マルチ VM 整合性の仮想マシンの回復計画は、次の条件が満たされている場合にのみ作成できます。

• 仮想マシンは同一のサブスクリプションとリージョン内に存在している必要があります。
• 仮想マシンは、ホスト名を使用してネットワーク経由で通信する必要があります。

[フェールオーバー]

ターゲット リージョンの容量を確保するにはどうすればよいですか?

最善の作業量ベースで十分なインフラストラクチャ容量が確保されるよう、Site Recovery チームと Azure キャパシティマネジメントチームが計画を立てます。 フェールオーバーを開始するとき、Site Recovery によって保護される仮想マシン インスタンスがターゲット リージョンにデプロイできるよう、チームも支援します。

フェールオーバーは自動で行われますか。

フェールオーバーは自動では行われません。 ポータルで 1 回クリックするだけでフェールオーバーを開始できます。または PowerShell を使用してフェールオーバーをトリガーすることもできます。

フェールオーバー後にパブリック IP アドレスを保持できますか?

運用アプリのパブリック IP アドレスは、フェールオーバー後に保持できません。

フェールオーバー プロセスの一環としてワークロードを起動するとき、Azure パブリック IP アドレス リソースをワークロードに割り当てる必要があります。 リソースはターゲット リージョンで使用可能である必要があります。 Azure パブリック IP アドレス リソースは手動で割り当てるか、復旧計画で自動化できます。 フェールオーバー後にパブリック IP アドレスを設定する方法については、こちらを参照してください。

フェールオーバー後にプライベート IP アドレスを保持できますか?

はい。 既定では、Azure 仮想マシンのディザスター リカバリーを有効にすると、Site Recovery によって、ソース リソースの設定に基づいてターゲット リソースが作成されます。 Azure 仮想マシンが静的 IP アドレスで構成されている場合、Site Recovery では、使用中でなければ同じ IP アドレスをターゲット仮想マシンにプロビジョニングしようとします。 フェールオーバー後の IP アドレスの保持については、こちらを参照してください。

フェールオーバー後に仮想マシンに新しい IP アドレスが割り当てられるのはなぜですか?

Site Recovery では、フェールオーバー時に IP アドレスの指定が試みられます。 別の仮想マシンがそのアドレスを使用している場合、Site Recovery では次の使用可能な IP アドレスがターゲットとして設定されます。

仮想ネットワークのネットワーク マッピングと IP アドレス指定の設定については、こちらを参照してください。

"最新" の復旧ポイントとは何ですか?

最新 (最も低い RPO) 復旧ポイント オプションでは、目標復旧ポイント (RPO) が最も低い状態になります。 これは、Site Recovery サービスに送信されたすべてのデータを最初に処理して、各仮想マシンの復旧ポイントを作成してから、それにフェールオーバーします。 最初に、ターゲットの場所にある Site Recovery サービスに送信されたすべてのデータを処理して適用し、処理したデータを使用して復旧ポイントを作成しようとします。 ただし、フェールオーバーがトリガーされた時点で、処理を待機している Site Recovery サービスにアップロードされたデータがない場合、Azure Site Recovery はいかなる処理も実行しないため、新しい復旧ポイントは作成されません。 このシナリオでは、代わりに、以前に処理された復旧ポイントのみを使用してフェールオーバーします。

"最新" の復旧ポイントは、フェールオーバー RTO に影響しますか?

はい。 Site Recovery では、フェールオーバー前に保留中のすべてのデータが処理されるので、このオプションは他のオプションよりも目標復旧時間 (RTO) が高くなります。

"最後に処理があった時点" の復旧オプションとは何ですか?

"最後に処理があった時点" オプションでは、次のことが行われます。

1. Site Recovery によって最後に処理された復旧ポイントに、すべての仮想マシンをフェールオーバーします。 このオプションを使用すると、未処理のデータの処理に時間がかからないため、RTO を低くできます。

プライマリ リージョンで予期しない障害が発生した場合はどうすればよいですか?

フェールオーバーを開始できます。 Site Recovery では、フェールオーバーを実行するためにプライマリ リージョンからの接続を必要としません。

仮想マシンのフェールオーバーの RTO はどのくらいですか?

Site Recovery の RTO SLA は 1 時間です。 ほとんどの場合、Site Recovery によって数分以内に仮想マシンがフェールオーバーされます。 RTO を計算するにはフェールオーバー ジョブを確認します。ここでは、仮想マシンを起動するまでにかかった時間が示されます。

復旧計画

復旧計画とは何ですか?

Site Recovery での復旧計画は、仮想マシンのフェールオーバーと復旧を調整します。 これは、復旧を常に正確で、繰り返し可能、さらに自動化されるようにするのに役立ちます。 その後、次の処理を実行します。

• 一緒にフェールオーバーする仮想マシンのグループを定義します
• アプリケーションが正確に動作するように、仮想マシン間の依存関係を定義します。
• 仮想マシン フェールオーバー以外のタスクに対するカスタム手動アクションのオプションを使用して、復旧を自動化します。

シーケンス処理のしくみを教えてください。

復旧計画では、シーケンス処理のために仮想マシンのグループを 7 つまで作成できます。 グループは一度に 1 つずつフェールオーバーされるので、同じグループに含まれる仮想マシンは一緒にフェールオーバーされます。 詳細情報。

復旧計画の RTO を検索するにはどうしたらよいですか?

復旧計画の RTO を確認するには、復旧計画のテスト フェールオーバーを実行します。 Site Recovery ジョブで、テスト フェールオーバーの期間を確認します。 このスクリーンショットの例では、SAPTestRecoveryPlan テスト フェールオーバー ジョブに 8 分 59 秒かかりました。

復旧計画に Automation Runbook を追加できますか?

はい。 詳細については、こちらを参照してください。

再保護とフェールバック

フェールオーバー後、セカンダリ リージョンの仮想マシンは自動的に保護されますか?

いいえ。 あるリージョンから別のリージョンに Azure 仮想マシンをフェールオーバーすると、その仮想マシンはターゲット ディザスター リカバリー リージョン内で保護されていない状態で起動されます。 セカンダリ リージョン内の仮想マシンを再保護するには、プライマリ リージョンに戻ってレプリケーションを有効にします。

再保護すると、セカンダリ リージョンからプライマリにすべてのデータがレプリケートされますか?

一概には言えません。 ソース リージョンの仮想マシンが存在している場合、ソース ディスクとターゲット ディスクの間の変更のみが同期されます。 Site Recovery では、ディスクを変更点と比較した後、データが転送されます。 通常、このプロセスには数時間かかります。 詳細については、こちらを参照してください。

フェールバックにはどのくらいの時間がかかりますか?

再保護後のフェールオーバーには、プライマリ リージョンからセカンダリ リージョンにフェールオーバーするときと大体同じ時間がかかります。

容量

ターゲット リージョンの容量を確保するにはどうすればよいですか?

最善の作業量ベースで十分なインフラストラクチャ容量が確保されるよう、Site Recovery チームと Azure キャパシティマネジメントチームが計画を立てます。 フェールオーバーを開始するとき、Site Recovery によって保護される仮想マシン インスタンスがターゲット リージョンにデプロイできるよう、チームも支援します。

Site RecoveryはCapacity Reservationと連動しますか？

はい、ディザスター リカバリーリージョンやゾーンで仮想マシン SKU の容量予約を作成し、ターゲット仮想マシンの [コンピューティング] プロパティで構成することができます。 これを行うと、site recovery はフェールオーバーのために確保された容量を使用します。 詳細情報。

なぜ、デスティネーション先でCapacity Reservationを使って容量を確保する必要があるのですか？

Site Recovery は、復旧リージョンで容量が利用できるように最善の努力をしますが、同じように保証するわけではありません。 Site Recovery の最善の作業量は、1 時間の RTO の SLA によって支えられています。 ただし、さらなる保証と保証されたコンピューティング能力が必要な場合は、Capacity Reservationsを購入することをお勧めします

Site Recovery は予約インスタンスと連携しますか?

はい、ディザスター リカバリー リージョンで予約済みの Azure 仮想マシンを購入することができます。Site Recovery のフェールオーバー操作でその仮想マシンが使用されます。 追加の構成は必要ありません。

Security

Site Recovery サービスにレプリケーション データが送信されますか。

いいえ。Site Recovery は、レプリケートされたデータをインターセプトすることも、仮想マシンでの実行内容に関するどのような情報を持つこともありません。 レプリケーションとフェールオーバーを調整するために必要なメタデータのみが、Site Recovery サービスに送信されます。

Site Recovery は ISO 27001:2013、27018、HIPAA、DPA 認定です。 このサービスは現在、SOC2 と FedRAMP JAB の評価を判定されている最中です。

Site Recovery はレプリケーションを暗号化しますか。

はい、転送中の暗号化と Azure に保存中の暗号化の両方がサポートされています。

ディスク ネットワーク アクセス

Azure Site Recovery によって作成されたディスクには、どのようなネットワーク アクセスがありますか?

Azure Site Recovery によってレプリカとターゲット ディスクが作成されます。 レプリカ ディスクは、データがレプリケートされるディスクであり、ターゲット ディスクはフェールオーバー (またはテスト フェールオーバー) の仮想マシンに接続されているディスクです。 Azure Site Recovery では、パブリック アクセスが有効になっているこれらのディスクが作成されます。 ただし、次の手順に従って、これらのディスクのパブリック アクセスを手動で無効にすることができます。

1. Recovery Services コンテナーの [レプリケートされた項目] セクションに移動します。

2. ディスク ネットワーク アクセス ポリシーを変更する仮想マシンを選択します。

3. [コンピューティング] タブで、ターゲット サブスクリプション名とターゲット リソース グループ名を見つけます。レプリカ ディスクは、ターゲット サブスクリプションとターゲット リソース グループにあります。 フェールオーバーとテスト フェールオーバーの仮想マシンは、ターゲット サブスクリプション内のターゲット リソース グループにも作成されます。

   

4. [レプリケートされた項目] の [ディスク] タブに移動して、各ソース ディスクに対応するレプリカ ディスク名とターゲット ディスク名を特定します。 レプリカ ディスクは、前の手順で取得したターゲット リソース グループで確認できます。 同様に、フェールオーバーを完了すると、ターゲット リソース グループ内の復旧仮想マシンにターゲット ディスクがアタッチされます。

   

5. レプリカ ディスクごとに、次の操作を行います。

   1. ディスクの [設定] の下にある [ディスクのエクスポート] タブに移動します。 既定では、ディスクには Azure Site Recovery によって取得された SAS アクセスが必要です。

   2. ネットワーク アクセスを変更する前に、[エクスポートのキャンセル] オプションを使用してエクスポートを取り消します。

      

      Azure Site Recovery では、レプリケーションのためにレプリカ ディスクに SAS が必要です。 エクスポートをキャンセルすると、Azure Site Recovery レプリケーションに一時的に影響する可能性がありますが、Site Recovery では数分後に SAS が自動的に取得されます。

   3. ディスクの [設定] オプションの下にある [ネットワーク] タブに移動します。 既定では、[すべてのネットワークからのパブリック アクセスを有効にする] 設定が有効になっているディスクが作成されます。

   4. エクスポートの取り消しが成功した後、要件に従ってネットワーク アクセスを [パブリック アクセスを無効にしてプライベート アクセスを有効にする] または [パブリック アクセスとプライベート アクセスを無効にする] に変更します。

      ディスク ネットワーク アクセスを [パブリック アクセスを無効にしてプライベート アクセスを有効にする] に変更する場合は、使用するディスク アクセス リソースがターゲット サブスクリプション内のターゲット リージョンに既に存在している必要があります。 ディスク アクセス リソースを作成する手順については、こちらをご覧ください。

      

   Note

   ディスクのネットワーク アクセスは、エクスポートを取り消した場合にのみ変更できます。 エクスポートを取り消さない場合、ディスクのネットワーク アクセスの変更は無効になります。

フェールオーバーまたはテスト フェールオーバーが完了すると、ターゲットの場所に作成された復旧仮想マシンにも、パブリック アクセスが有効になっているディスクが作成されます。 これらのディスクには、Azure Site Recovery によって取得された SAS はありません。 これらのディスクのネットワーク アクセスを変更するには、ディスクの [ネットワーク] タブに移動し、手順 5 に従って必要に応じてディスク ネットワーク アクセスを変更します。

再保護とフェールバック中にも、Azure Site Recovery はパブリック アクセスが有効なディスクを作成します。 これらのディスクのネットワーク アクセスは、要件に基づいて上記の手順で説明した手順で変更できます。

次のステップ

• Azure 間サポートの要件を確認します。
• Azure 間レプリケーションを設定します。
• この記事の内容について質問がある場合は、Azure Recovery Services に関する Microsoft Q&A 質問ページに投稿してください。