こんにちは、Azure Backup サポートです。
今回は、 Azure バックアップ ソリューションで利用する Recovery Services コンテナーとバックアップ コンテナーのバックアップ対象の違いについてご説明します。
Recovery Services コンテナーとバックアップ コンテナーはバックアップ対象 (バックアップ ソリューション) の違いにより使い分ける必要がございます。
また、回復性 (Resiliency) は サブスクリプション内の Recovery Services コンテナーやバックアップ コンテナー (およびそれぞれのコンテナーでバックアップしているバックアップ アイテム) を統合管理するための管理画面です。

目次

1. バックアップ ソリューションとコンテナー、およびデータ保存先の比較表
2. コンテナーにバックアップ データが保存されないもの
2-1. Azure ファイル共有バックアップ (スナップショット レベル)
2-2. Azure Blob バックアップ (運用バックアップ)
2-3. Azure ディスク バックアップ

1. バックアップ ソリューションとコンテナー、およびデータ保存先の比較表

各 Azure バックアップのソリューションがどのコンテナーを利用するか、またデータの保存先については下記の通りです。
また、各ソリューションには各公開ドキュメントへのリンクを付けています。

(注 1) 2025 年 3 月現在、Azure Premium ファイル共有のコンテナー層へのバックアップ機能は Public Preview となっております
一方、Azure Standard ファイル共有のコンテナー層へのバックアップ機能は Generally Available となっております

• Generally Available: Vaulted Backup Support for Azure Files Standard Shares | Azure updates | Microsoft Azure
  https://azure.microsoft.com/en-US/updates?id=482659

(注 2) AKS のバックアップにおいて、運用層のバックアップは必須で取得いただく必要がございますが、コンテナー層のバックアップは任意での取得が可能となっております

2.コンテナーにバックアップ データが保存されないもの

上述のとおり、現在 一般公開されている (プレビュー機能ではない) Azure ファイル共有バックアップ (スナップショット レベル) 、Azure Blob バックアップ (運用バックアップ)、Azure ディスク バックアップは各コンテナーにはバックアップ データは転送されません。
それぞれについて簡単にご説明させていただきます。
共通している点はそれぞれのソリューションはコアとなる別のソリューションをバックアップ サービス側からトリガーし実現している点でございます。

2-1. Azure ファイル共有バックアップ (スナップショット レベル)

Azure ファイル共有 バックアップ (スナップショット レベル) は Azure Files の共有スナップショットの機能をバックアップ サービスと連携することによりスナップショット取得・削除の自動化を実現したバックアップ ソリューションです。

そのため、バックアップ データ (スナップショット データ) の保存先は Azure Files の共有スナップショットと同じく、そのストレージ アカウント自身 (のスナップショット領域)となります。
そのため、 Recovery Services コンテナーには転送されません。
下記のようにAzure ファイル共有のスナップショット リソースとして、Azure ファイル共有バックアップにて取得されたスナップショットも確認可能です。(“発信側” が “AzureBackup” となっているものです)

• バックアップ プロセスのしくみ - Azure ファイル共有のバックアップについて
  https://learn.microsoft.com/ja-jp/azure/backup/azure-file-share-backup-overview

  抜粋：スナップショット レベル | ファイル共有 API を使ってファイル共有のスナップショットが作成されます。 スナップショットの URL は、メタデータ ストアだけに格納されます。

• Azure Files の共有スナップショット
  https://learn.microsoft.com/ja-jp/azure/storage/files/storage-snapshots-files

2-2. Azure Blob バックアップ (運用バックアップ)

Azure Blob バックアップ (運用バックアップ) は Azure Blob のポイントインタイム リストアの機能をバックアップ サービスと連携することにより実現したバックアップ ソリューションです。

バックアップ データ (リストアに必要なデータ) の保存先は Azure Blob のポイントインタイム リストアと同じく、そのストレージ アカウント自身となります。
バックアップ コンテナーには転送されません。

• 運用バックアップのしくみ - Azure Blob の運用バックアップの概要
  https://learn.microsoft.com/ja-jp/azure/backup/blob-backup-overview

  抜粋：継続的バックアップ: 運用バックアップ (マネージド ローカル データ保護ソリューション) を構成して、ブロック BLOB の偶発的な削除や破損から保護できます。 データはソース ストレージ アカウント内にローカルに格納され、バックアップ コンテナーには転送されません。

• ブロック BLOB のポイントインタイム リストア
  https://learn.microsoft.com/ja-jp/azure/storage/blobs/point-in-time-restore-overview

2-3. Azure ディスク バックアップ

Azure ディスク バックアップ は マネージド ディスクの増分スナップショットの機能とバックアップ サービスを連携することによりスナップショット取得・削除の自動化を実現したバックアップ ソリューションです。

そのため、バックアップ データ (スナップショット データ) の保存先は マネージド ディスクのスナップショットと同じく、マネージド ディスクのスナップショットの専用領域 (運用層) となります。
Recovery Services コンテナーには転送されません。
また、下記のようにスナップショット リソースとして Azure ディスクのバックアップによって取得されたスナップショットも確認可能です。(タグが “CreatedBy：AzureBackup” となっているものです)

• バックアップと復元のプロセスのしくみ - Azure ディスク バックアップの概要
  https://learn.microsoft.com/ja-jp/azure/backup/disk-backup-overview#how-the-backup-and-restore-process-works

  抜粋： Azure ディスク バックアップでは、運用層のバックアップのみがサポートされています。 コンテナー ストレージ層へのバックアップのコピーはサポートされていません。 そのため、バックアップ コンテナーのストレージ冗長設定 (LRS/GRS) は、運用層に格納されているバックアップには適用されません。

• マネージド ディスクの増分スナップショットの作成
  https://learn.microsoft.com/ja-jp/azure/virtual-machines/disks-incremental-snapshots?tabs=azure-cli

本ブログ記事の説明は以上です。

皆様こんにちは、Azure Backup サポート チームです。
今回は、Azure VM Backup における VM ごとのバックアップ データ量の確認方法 についてご紹介します。

目次

1. 概要
2. バックアップ データの合計量を確認する方法
3. VM ごと のバックアップ データ量を確認する方法
3-1. 診断設定の構成方法
3-2. バックアップ レポートでのデータ量の確認方法
4. 現時点でできないこと

1. 概要

Azure VM Backup では、バックアップ データは Recovery Services コンテナーに保存されます。
このコンテナーで VM ごとのバックアップ データ量を確認するには、バックアップ レポートを利用する必要があります。
ただし、このレポートを使用するためには、事前にお客様ご自身で診断設定を構成していただく必要があります。
本記事では、診断設定の構成方法および、VM ごとのバックアップ データ量を確認する手順を解説します。

2. バックアップ データの合計量を確認する方法

まずは、Recovery Services コンテナーに保存されているバックアップ データの合計量を確認する方法をご紹介します。

この確認には、特別な設定は不要です。
Azure Portal で対象の Recovery Services コンテナーを開き、［概要］ ページの ［バックアップ］ タブ下部に表示される情報から、Recovery Services コンテナーに保存されているバックアップ データの合計量を確認できます。

3. VM ごとのバックアップ データ量を確認する方法

次に、Recovery Services コンテナーに保存されている各 VM のバックアップ データ量を確認する方法をご紹介します。

この確認には、診断設定の構成と、バックアップ レポートの利用が必要です。
以下の記事にて、設定から確認までの流れをご説明します。

3-1. 診断設定の構成方法

1. Log Analytics ワークスペースの作成

まず、診断ログの送信先となる Log Analytics ワークスペースを作成します。
ワークスペース名は任意で構いません。

Log Analytics ワークスペースの作成方法の詳細につきましては、以下の公式ドキュメントをご覧ください。
・Log Analytics ワークスペースの作成 - Azure Monitor | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/quick-create-workspace?tabs=azure-portal

2. Recovery Services コンテナーで診断設定を構成

次に、Recovery Services コンテナーの ［監視］ → ［診断設定］ を開き ［診断設定を追加する］ をクリックして構成を追加します。

構成時には、以下の 3 項目にチェックを入れてください

• Core Azure Backup Data
• Addon Azure Backup Policy Data
• Addon Azure Backup Storage Data

送信先には、先ほど作成した Log Analytics ワークスペースを選択します。
ターゲット テーブルの種類はリソース固有を選択してください。

診断設定の詳細につきましては、以下の公式ドキュメントをご覧ください。
・Azure Backup ユーザー向けの診断イベント - Azure Backup | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-diagnostic-events?tabs=recovery-services-vaults

Log Analytics をご利用いただく場合、Azure VM Backup の費用に加えて、ログのインジェストおよびクエリに対して別途費用が発生します。
Log Analytics の費用に関する詳細は、以下の公式ドキュメントをご参照ください。
・価格 - Azure Monitor | Microsoft Azure
　https://azure.microsoft.com/ja-jp/pricing/details/monitor/

3-2. バックアップ レポートでのデータ量の確認方法

Recovery Services コンテナーの ［管理］ → ［バックアップ レポート］ を開き ［作業の開始］ タブにて、先ほど作成した Log Analytics ワークスペースを選択してください。

次に ［バックアップ インスタンス］ タブを選択してください。

ページ下部にある バックアップ インスタンスごとのストレージ 欄にて、VM ごとのバックアップ データ量を確認することができます。

ただし、Recovery Services コンテナーにて診断設定を構成した直後にバックアップ レポートを確認いただいても、レポートのデータがすぐに表示されない場合があります。
そのため、Log Analytics にデータ送信するように Recovery Services コンテナーの診断設定を構成した 2 日以上後からレポートを表示することを推奨いたします。

これは、診断設定後の初回データ送信に時間がかかるためであり、以下の点にご留意ください。

診断を構成した後、最初のデータ プッシュが完了するまでに最大 24 時間かかることがあります。 Log Analytics ワークスペースへのデータの送信が開始された後、レポートのデータがすぐに表示されない場合があります。まだ終わっていない現在日のデータはレポートに表示されないためです。 詳細については、「バックアップ レポートで使用される規則」を参照してください。 Log Analytics にデータを送信するようにコンテナーを構成した 2 日後からレポートの表示を開始することをお勧めします。

Azure Backup のレポート構成方法や、レポート表示までの時間に関することの詳細は、以下の公式ドキュメントをご覧ください。
・Azure Backup のレポートを構成する - Azure Backup | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/backup/configure-reports?tabs=recovery-services-vaults

4. 現時点でできないこと

上記にて VM ごとのバックアップ データ量の確認方法をご案内いたしました。
一方で、現時点 (2025年9月17日) では、 VM ごとのバックアップ費用 を直接確認する方法は提供されておりません。
そのため、費用の算出につきましては、お客様ご自身で「Azure Backup の費用」に関する以下の公式サイトをご参照のうえ、VM ごとのバックアップ費用を計算いただく必要がございます。
・価格 – Azure Backup | Microsoft Azure
　https://azure.microsoft.com/ja-jp/pricing/details/backup/
なお、Recovery Services コンテナーごとの Azure VM Backup の合計費用につきましては、サブスクリプション → コスト分析よりご確認いただけます。
Azure VM Backup の合計費用の詳細は、以下の弊チーム ブログをご覧ください。
・Standard バックアップ ポリシーと Enhanced バックアップ ポリシーの料金の違い | Japan CSS ABRS Support Blog !!
　https://jpabrs-scem.github.io/blog/AzureVMBackup/VM_Backup_billing/#2

皆様こんにちは。Azure Site Recovery サポートです。
今回は Azure Site Recovery (以下、ASR ) にて「レプリケーションの有効化 が失敗する」「レプリケートが失敗している」といった場合に調査をするにあたり、ネットワーク観点で提供いただきたい情報をお伝えいたします。
ネットワーク観点以外で、サポートにて調査時に必要なログは下記をご覧ください

• ASR の障害調査に必要な情報
  https://jpabrs-scem.github.io/blog/AzureSiteRecovery/RequestForInvestigating_ASR/

該当シナリオ

1. A2A : Azure Site Recovery 機能を利用して、「Azure 仮想マシン」をレプリケート構成するシナリオ (Azure to Azure)
   • Azure から Azure へのディザスター リカバリー アーキテクチャ
     https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-architecture
2. H2A : Azure Site Recovery 機能を利用して、「Hyper-V ゲスト マシン」をレプリケート構成するシナリオ (Hyper-V to Azure)
   • Hyper-V から Azure へのディザスター リカバリー アーキテクチャ
     　 https://learn.microsoft.com/ja-jp/azure/site-recovery/hyper-v-azure-architecture

※　本ブログ記事は、「パブリック エンドポイント経由で ASR 構成する」場合の疎通確認スクリプトです。
　　プライベート エンドポイント経由で ASR 構成している場合のブログ記事ではありません。
　　プライベート エンドポイント構成の場合、ユーザーの環境毎に作成されているプライベート FQDN へ接続確立できているかどうかを、ユーザー側にて確認いただく必要があります。

目次

1. Azure Site Recovery の A2A・H2A シナリオにおける通信要件
2. Windows OS における ASR 疎通確認スクリプト
3. Linux OS における ASR 疎通確認スクリプト
4. 疎通確認スクリプトの構成
4-1. Windows OS 向けの疎通確認スクリプト内の構成
4-2. Linux OS 向けの疎通確認スクリプト内の構成
5. 手動でキャッシュ用ストレージ アカウントへの疎通を確認する方法
5-1. コマンドを使った疎通確認 - 手順
5-2. Azure Storage Explorer を使った確認 - 手順

1. Azure Site Recovery の A2A・H2A シナリオにおける通信要件

Azure 仮想マシンのレプリケートを構成したい場合には、レプリケート希望の Azure 仮想マシン上で、下記の通信要件を満たしている必要があります。

• A2A 接続の要件 (パブリック エンドポイント経由でレプリケート構成する場合)
  https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-architecture#connectivity-requirements
  

• H2A 接続の要件 (パブリック エンドポイント経由でレプリケート構成する場合)
  https://learn.microsoft.com/ja-jp/azure/site-recovery/hyper-v-azure-architecture#set-up-outbound-network-connectivity

上図は、 A2A の通信要件ドキュメント (パブリック エンドポイント経由) の画像です。
黄色罫線箇所のアドレスは、「A2A」「H2A」どちらのシナリオであっても同様に必要となる通信要件です。
「Service Bus」は、「レプリケート処理」自体には必要はありませんが、Azure 仮想マシン上のレプリケート状態などを、Azure へと送信し、Azure ポータル画面の「レプリケート ヘルス」欄にて正しいレプリケート状態を確認するために必要な通信先となります。必ず疎通できるようご設定下さい。
レプリケート希望の Azure 仮想マシンが ADE 暗号化済なのであれば、「Key Vault」への通信確立も必要となります。
A2A シナリオにおいて、Azure 仮想マシンのレプリケートを構成する場合、Azure 仮想マシン上に「モビリティ サービス エージェント」がインストールされ、機能することとなりますが、このモビリティ サービス エージェントを自動的に更新したい場合には「Azure Automation」への接続も必要となります。

2. Windows OS における ASR 疎通確認スクリプト

※　本疎通確認スクリプトは、あくまで「パブリック エンドポイント経由での ASR 利用」を想定とした確認スクリプトです。

【スクリプト実行手順】

1. 下記 リンク先から疎通確認スクリプトをダウンロード・展開ください
   ASRNWCheck.zip
   ※ ファイルの解凍パスワードは “SiteRecovery” となります。

2. マシン上にて、管理者特権の PowerShell コンソール を立ち上げ、Check_ASR_NW_Windows_A2A_H2A_ver1.0.ps1 を実行ください。
   (スクリプト実行対象マシン)

   • A2A (Azure to Azure) シナリオの場合：レプリケート希望の Azure 仮想マシン上
   • H2A (Hyper-V to Azure) シナリオの場合：対象の Hyper-V ホストマシン上

   (実行例 1)
   .\Check_ASR_NW_Windows_A2A_H2A_ver1.0.ps1 <キャッシュ用ストレージ アカウントとして設定しているストレージ アカウント名>
   (実行例 2)
   .\Check_ASR_NW_Windows_A2A_H2A_ver1.0.ps1
   ※　引数にキャッシュ用ストレージ アカウント名を渡さない場合、キャッシュ用ストレージ アカウントへの通信確認は行われません。
   (実行画面例 1)
   

   (実行画面例 2)
   

   ※　スクリプト実施時に実行ポリシーの制限によりスクリプトが実行できない場合は、下記コマンドを実行して実行ポリシーを変更後、再度スクリプト実効をお試しください。
   Set-ExecutionPolicy Unrestricted

   (参考) Set-ExecutionPolicy
   https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.security/set-executionpolicy?view=powershell-7.5

3. “Script Completed” が出力されれば、スクリプトは終了です。
   ※　スクリプト実行完了までには、環境によっては 20 分ほど要する場合がございます。20 分経っても完了しない場合は、control + c を押下して強制終了してください。
   

4. スクリプト実行が完了すると、スクリプトと同じフォルダ内に以下のようなログファイルが出力されますので、弊社までご提供ください。
   ログファイル名: ASR_Check_NW_yyyymmdd_hhmmss.log
   
   ※ control + c にて強制終了した場合においても該当のログファイルが出力されますので、弊社までご提供ください。

3. Linux OS における ASR 疎通確認スクリプト

※　本疎通確認スクリプトは、あくまで「パブリック エンドポイント経由での ASR 利用」を想定とした確認スクリプトです。

【スクリプト実行手順】

1. 下記 リンク先から疎通確認スクリプトをダウンロード・展開ください
   ASRNWCheck.zip
   ※ ファイルの解凍パスワードは “SiteRecovery” となります。

2. レプリケート希望の Azure 仮想マシン (Linux OS) マシン上にて、Check_ASR_NW_Linux_A2A_ver1.0.sh を配置します。
   必要に応じて chmod コマンドなどを用いてパーミッションを変更してください。
   chmod 777 Check_ASR_NW_Linux_A2A_ver1.0.sh

3. スクリプトを実行ください。
   (実行例 1)
   ./Check_ASR_NW_Linux_A2A_ver1.0.sh -s <キャッシュ用ストレージ アカウントとして設定しているストレージ アカウント名>
   (実行例 2)
   Check_ASR_NW_Linux_A2A_ver1.0.sh
   ※　引数にキャッシュ用ストレージ アカウント名を渡さない場合、キャッシュ用ストレージ アカウントへの通信確認は行われません。
   (実行画面例)
   

4. “Script Completed” が出力されれば、スクリプトは終了です。
   ※　スクリプト実行完了までには、環境によっては 20 分ほど要する場合がございます。20 分経っても完了しない場合は、control + c を押下して強制終了してください。

5. スクリプト実行が完了すると、スクリプトと同じフォルダ内に以下のようなログファイルが出力されますので、弊社までご提供ください。
   ログファイル名: CheckNWResult_<ホスト名>_yyyymmddhhmm.log
   
   ※ control + c にて強制終了した場合においても該当のログファイルが出力されますので、弊社までご提供ください。

4. 疎通確認スクリプトの構成

4-1. Windows OS 向けの疎通確認スクリプト内の構成

Windows OS 向けの疎通確認スクリプト (Check_ASR_NW_Windows_A2A_H2A_ver1.0.ps1) では、下記を実施しています。

(1) 「HOSTNAME.EXE」「ipconfig.exe」実行によるマシン情報の出力
(2) プロキシ設定の確認
(3) Azure Site Recovery サービス (hypervrecoverymanager.windowsazure.com) への「tnc」「Invoke-webRequest」コマンド実行
(4) (ストレージ アカウントを引数に渡している場合) Azure ストレージ アカウント (XXX.blob.core.windows.net) への「tnc」「Invoke-webRequest」コマンド実行
(5) Microsoft Entra ID (login.microsoftonline.com) への「tnc」「Invoke-webRequest」コマンド実行
(6) TLS 設定 情報の出力

4-2. Linux OS 向けの疎通確認スクリプト内の構成

Linux OS 向けの疎通確認スクリプト (Check_ASR_NW_Linux_A2A_ver1.0.sh) では、下記を実施しています。

(1) 「ip a」「hostnamectl」コマンドによるマシン情報の出力
(2) プロキシ設定の確認
(3) Microsoft Entra ID (login.microsoftonline.com) への「nslookup」「nc」「curl」コマンド結果
(4) Azure Site Recovery サービス (hypervrecoverymanager.windowsazure.com) への「nslookup」「nc」「curl」コマンド結果
(5) (ストレージ アカウントを引数に渡している場合) Azure ストレージ アカウント (XXX.blob.core.windows.net) への「nslookup」「nc」「curl」コマンド結果

5. 手動でキャッシュ用ストレージ アカウントへの疎通を確認する方法

手動でストレージ アカウントへの接続を確認する方法を紹介します。

【確認オプション】

• (オプション 1 ) コマンドを使った疎通確認
• (オプション 2 ) Azure Storage Explorer を使って、対象マシンから、適当なファイルをストレージ アカウントの BLOB コンテナーへとアップロードまでできるかを確認

※ すでに「レプリケーションの有効化」作業を実施済の場合、「どのストレージ アカウントをキャッシュ用として設定したのか」は、Azure ポータル画面 > 対象の Recovery Services コンテナー > レプリケートされたアイテム > [プロパティ]画面より確認可能です。

5-1. コマンドを使った疎通確認 - 手順

OS 別に、下記コマンドを全て実行ください。
弊社サポートへのお問い合わせを希望される場合は、「実行コマンド」と「実行結果」が分かる内容をテキストファイル形式にて、弊社までご提供ください。

【Windows OS のマシンから確認する場合 - PowerShell にて確認】
nslookup <ストレージ アカウント名>.blob.core.windows.net
tnc -port 443 <ストレージ アカウント名>.blob.core.windows.net
Invoke-WebRequest https://<ストレージ アカウント名>.blob.core.windows.net

(※)プロキシを経由して、キャッシュ用ストレージ アカウントとの通信を行いたい場合は、追加で下記コマンドを実行ください。
Invoke-WebRequest https://<ストレージ アカウント名>.blob.core.windows.net -Proxy http://<プロキシ サーバーの IP アドレス>:<プロキシ ポート>

(実行結果例)

【Linux OS のマシンから確認する場合】
nslookup <ストレージ アカウント名>.blob.core.windows.net
nc -vz <ストレージ アカウント名>.blob.core.windows.net 443
curl -I https://<ストレージ アカウント名>.blob.core.windows.net

(※)プロキシを経由して、キャッシュ用ストレージ アカウントとの通信を行いたい場合は、追加で下記コマンドを実行ください。
curl -I --proxy http://<プロキシ サーバーの IP アドレス>:<プロキシ ポート> https://<ストレージ アカウント名>.blob.core.windows.net

(実行結果例)

5-2. Azure Storage Explorer を使った確認 - 手順

1. 対象マシン上で、次の URL から Azure Storage Explorer をインストールします。
   https://azure.microsoft.com/ja-jp/products/storage/storage-explorer/#overview
2. Azure ポータル画面 > ストレージ アカウント > [セキュリティとネットワーク] > [アクセス キー] > [ストレージ アカウント名] と [key] を確認しておきます。
   
3. 対象マシン上で、インストールした Azure Storage Explorer を使って、接続テストを行います。
   Azure Storage Explorer を起動し、Connect to Azure resources を選択します。
   
4. Storage account or service を選択します。
   
5. Account name and keyを選択し、Next をクリックします。
   
6. Account name に、手順「2」で確認した [ストレージ アカウント名] を、Account key に [key] を入力し、Next クリックします。
   
7. 内容を確認し、Connect をクリックします。
   
8. Explorer より、接続したストレージ アカウントの Blob を確認します。
   (Blob が未作成の場合) 任意の名前で Blob コンテナーを作成ください。
   
9. アップロードテスト用に 4 MB のファイルを生成します。PowerShell で、任意のディレクトリ上で次のコマンドを実行して下さい。
   fsutil file createnew dummy4MB.dat 4194304
   
   
10. 生成したファイルをストレージ アカウントの Blob コンテナー 上にアップロードします。
    [Upload] > [Upload Files…] をクリックし、ファイルのアップロードを行います。
    
11. 各コンテナーへのアップロードが正常終了することを確認します。
    
12. BLOB コンテナーへのアップロードが正常に行えることを確認した後は、テスト目的で任意に作成した BLOB コンテナーとファイルは削除ください。

ご案内は以上となります。

こんにちは、Azure Backup サポートです。
今回は、Azure VM Backup でリストアする際にステージングの場所として利用するストレージ アカウントについて、下記のとおりお伝えします。

目次

1. 公開情報 (Docs)
2. 利用できるストレージ アカウント
3. リストアされた後にストレージ アカウントに残るファイルについて
4. 参考画面ショット

1. 公開情報 (Docs)

まず最初に、本件に関する Docs は下記でございます。

・ ストレージ アカウント - Azure portal で Azure VM データを復元する方法
　 https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms#storage-accounts

抜粋:”Vault-Standard 復元ポイントからマネージド VM のディスクを復元するときに、マネージド ディスクと Azure Resource Manager (ARM) テンプレートが、ステージング場所にあるディスクの VHD ファイルと共に復元されます。 インスタント復元ポイントからディスクを復元する場合、マネージド ディスクと ARM テンプレートのみが復元されます。”

抜粋:リージョン間復元では、 ステージング場所 (ストレージ アカウントの場所) は、Recovery Services コンテナーが セカンダリ リージョンとして扱うリージョンに存在する必要があります。 たとえば、Recovery Services コンテナーは米国東部 2 リージョンにあります (geo 冗長性とリージョン間復元が有効になっています)。 これは、セカンダリ リージョンは米国中部であることを意味します。 そのため、VM のリージョン間復元を行なうには、米国中部でストレージ アカウントを作成する必要があります。
すべての地域の Azure リージョン間レプリケーションのペアリングに関する記事をご覧ください。

2. 利用できるストレージ アカウント

選択できるストレージ アカウントは下記の条件を満たすものです。
・ リストア先 (=ターゲット) のサブスクリプション内およびコンテナーと同じリージョンにある
・ LRS / ZRS / GRS の冗長性
・ Premium Storage アカウントではない
・ (ストレージアカウントのネットワーク設定でパブリックアクセスが制限されている場合) 例外の “信頼されたサービスの一覧にある Azure サービスがこのストレージ アカウントにアクセスすることを許可します” をチェックしている
・ 階層型名前空間 (HierarchicalNamespace) が有効化されていない

3.リストアされた後にストレージ アカウントに残るファイルについて

マネージド ディスクの Azure VM の復元が完了しますと対象のストレージ アカウントの中に下記のファイルが残ります。
下記のとおり、ストレージ アカウントにファイルが残るかおよび、どのファイルが残るかはリストア シナリオによって異なります。

4.参考画面ショット

VM 名：vm-temp-01 という Azure VM (OS ディスク 1 つ、データディスク 2 つ) を (2) のディスクの復元にてリストアしたあとのストレージ アカウントです。

コンテナー名：
vmtemp01-d90848d6dcef467a9624f5c9cbfc1ad7
上記の通り、Azure VM 名にランダムな文字列のコンテナー名のコンテナーが作成されます。

VHD：
vmtemp01-osdisk-20250822-025019.vhd
vmtemp01-datadisk-001-20250822-025019.vhd
vvmtemp01-datadisk-000-20250822-025019.vhd
上記の通り、Azure VM 名にディスク種別および LUN 番号リストア日時 (UTC表記) が付加された vhd ファイルが作成されます。

json：
azuredeployfe1ece11-f3b3-49cc-b7c4-04dc93f1afa2.json
config-vmtemp01-fe1ece11-f3b3-49cc-b7c4-04dc93f1afa2.json
parameterfe1ece11-f3b3-49cc-b7c4-04dc93f1afa2.json
上記の通り、
「azuredeploy<リストア ジョブで使用されるJob ID>」
「config-<VM 名>-<リストア ジョブで使用されるJob ID>」
「parameter<リストア ジョブで使用されるJob ID>」の名前から始まるファイルが 3 つ作成されます。

「Job ID」は、コマンドからの確認や、Recovery Services コンテナー > バックアップ ジョブ > 「ジョブのエクスポート」より確認ができます。

・ジョブをエクスポートする
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-manage-windows-server#export-jobs

みなさんこんにちは、Azure Backup サポートです。
今回は Azure Backup のバックアップ失敗、リストア失敗の時の調査をするにあたり、提供いただきたい情報をお伝えいたします。
なお、 Azure Backup の NW 観点の障害調査に必要なログに関しては、下記をご覧ください。
・ Azure Backup の障害調査に必要な情報 (疎通確認)
　 https://jpabrs-scem.github.io/blog/AzureBackupGeneral/RequestForInvestigatingNW/

目次

1. Azure VM バックアップの障害調査に必要なログ
 1-1. Azure VM バックアップ の VSS 障害調査に追加で必要なログ
2. Azure VM バックアップ の ファイル レベル リストア (ILR) 失敗調査に必要なログ
3. Azure Backup for SAP HANA in Azure VM の障害調査に必要なログ
 3-1. SAP HANA の backup.log 及び backint.log
 3-2. opt 配下の log
4. MARS (Microsoft Azure Recovery Services) エージェントを利用したバックアップ の障害調査に必要なログ
 4-1. MARS (Microsoft Azure Recovery Services) エージェントのログ
 4-2. システム情報
 4-3. イベント ログ
 4-4. 各種証明書の確認およびインポート
  4-4-1. 個人 > 証明書
  4-4-2. 信頼されたルート証明書 > 証明書
  4-4-3. 証明書インポート手順

1. Azure VM バックアップの障害調査に必要なログ

下記の 環境情報 と ログ情報 の収集をお願いいたします。

環境情報

・ Subscription ID
・ Recovery Services コンテナー名、およびそのリソースグループ名
・ バックアップ対象 VM 名、およびそのリソースグループ名
・ OS およびバージョン情報

ログ情報

下記を参考に zip などにまとめてご提供いただけますと幸いです。

・Windows の場合

C:\Windows\System32\winevt\Logs
C:\WindowsAzure\

・Linuxの場合

/var/log/

全量いただけることが望ましいですが、全量が困難な場合は下記をご提供ください。

/var/log/azure/*
/var/log/syslog*
/var/log/waagent.*

1-1. Azure VM バックアップ の VSS 障害調査に追加で必要なログ

Azure VM バックアップの下記のようなエラーが出ることがございます。

Error Code : Snapshot operation failed due to VSS Writers in bad state.
Error Message : ExtensionFailedVssWriterInBadState

その場合には VSS 観点での調査が必要であるため、上記 1. Azure VM バックアップの障害調査に必要なログ に加えて下記 URL 先のログの採取をお願いいたします。
可能な限り “[A]”が望ましいですが、”[B]” の方法で採取いただいても、ある程度は調査が可能な場合がございます。
・ VSS エラーが発生している事象の調査
　 https://jpwinsup.github.io/mslog/storage/vss/vss-error/

2. Azure VM バックアップ の ファイルレベル リストア (ILRリストア) 失敗調査に必要なログ

下記の 環境情報 と ログ情報 の収集をお願いいたします。

環境情報

・ Subscription ID
・ Recovery Services コンテナー名、およびそのリソースグループ名
・ バックアップ対象 VM 名、およびそのリソースグループ名、OS 名
・ リストア先の VM 名、およびそのリソースグループ名、OS 名

ログ情報

zip などにまとめてご提供いただけますと幸いです。

• (Windows の場合) “ディスクの管理” の画面の画面ショット
  

• 実行したスクリプト、および実行後に作成されたフォルダ一式

  • Windowsの場合
    ・ スクリプトファイル : IaaSVMILRExeForWindows.exe
    ・ スクリプト実行後に作成されるフォルダー : 仮想マシン名(小文字)+スクリプトファイル実行日時

    下記例では “okt-temp-win-20220212145642” が作成されています。
    

    “okt-temp-win-20220212145642”の中身
    

  • Linux の場合
    ・ スクリプトファイル :

    例) vm02kensho_1_jpe_6591639015130036692_802427195716_899298aac7c04bf094ad68bfc5b9584ed206b94b62d965.py
    ※ 上記「vm02kensho」の箇所に、小文字の仮想マシン名が含まれます

    ・ スクリプト実行後に作成されるフォルダー : 仮想マシン名(小文字)+スクリプトファイル実行日時/Script

    スクリプトを実行後、「vm02kensho-20220212151619」ディレクトリが自動生成されていることがわかる。
    

    ls -all

    

    「vm02kensho-20220212151619」ディレクトリの中身、および作成されたディレクトリの Scripts ディレクトリの中身は下記の通り

    ls -allR

    

3. Azure Backup for SAP HANA in Azure VM の障害調査に必要なログ

3.0 環境情報とログ

1. Azure VM バックアップの障害調査に必要なログ の 環境情報 ならびに ログ情報 - Linuxの場合 の取得をお願いいたします。

3.1 SAP HANA の backup.log 及び backint.log

• xx にはインスタンスナンバーが入ります。
  • /hana/shared/HXE/HDBxx/(hostname)/trace/backup.log
  • /hana/shared/HXE/HDBxx/(hostname)/trace/DB_<DB名>/backup.log
  • /hana/shared/HXE/HDBxx/(hostname)/trace/backint.log
  • /hana/shared/HXE/HDBxx/(hostname)/trace/DB_<DB名>/backint.log

※ お手数ですが、全ての DB の backup.log 及び backint.log の採取をお願いいたします。
※ 上記パスに該当のログが無い場合は以下を試し、コマンド実行結果に表示されるディレクトリの場所のログをアップロードしてください。

1
2
3
4

sudo -i # rootユーザーに切り替えます
cd /    # ディレクトリの最上層に移動します
find ./ -name "backup.log"  # findコマンドにより該当のログの場所を特定します
find ./ -name "backint.log" # findコマンドにより該当のログの場所を特定します

3.2 opt 配下の log

/opt/msawb/var/log ディレクトリ配下のファイルを zip 等におまとめのうえで、アップロードしてください。

4. MARS (Microsoft Azure Recovery Services) エージェントを利用したバックアップ の障害調査に必要なログ

4.0 環境情報と Windows ログ

1. Azure VM バックアップの障害調査に必要なログ の 環境情報 ならびに ログ情報 - Windows の場合 の取得をお願いいたします。
※ MARS バックアップ のバックアップ対象の環境が Azure VM でない場合は Azure VM 名 / VM リソース グループ名は不要です。

上記に加えて下記もご対応お願いいたします。

4.1 MARS (Microsoft Azure Recovery Services) エージェントのログ

まず、下記 リンク先から調査用スクリプトをダウンロードしてください。
WABDiag.zip

ダウンロードいただきました WABDiag.tx を .ps1 に変更して使用し、問題が発生しているマシンより Azure Backup ログの収集をお願いいたします。
※ ファイルの解凍パスワードは “AzureBackup” となります。

1. WABDiag.ps1 を管理者権限の PowerShell で実行します。

実行コマンド : <スクリプトのパス>\WABDiag.ps1 <パス\保存するフォルダ名>
実行例 : C:\WABDiag\WABDiag.ps1 C:\Logs

実行結果にファイル パスが無い旨のメッセージが表示される可能性がございますが、対象のファイル自体が無い事を示すメッセージとなりますので、無視していただいて問題ございません。

PowerShell の実行ポリシーの制限によりスクリプトが実行できない場合

PowerShellを管理者権限で起動し、下記コマンドを実行し実行ポリシーを変更後、再度実行していただけますでしょうか。

コマンド : Set-ExecutionPolicy Unrestricted

また現在の実行ポリシーを後ほど元に戻す場合は、変更前に下記コマンドを実行し、設定されているポリシーを確認、メモし、スクリプト実行後に同様の手順で変更していただきますようお願いいたします。

コマンド : Get-ExecutionPolicy

• 参考
  実行ポリシーについて - PowerShell
  https://docs.microsoft.com/ja-jp/powershell/module/microsoft.powershell.core/about/about_execution_policies?view=powershell-7.2

4.2 システム情報

1. 対象のマシンに管理者権限を保持するユーザーでログオンします。
2. 管理者権限でコマンド プロンプトを起動し、以下のコマンドで取得します。

   msinfo32 /nfo <出力ファイル名>
   実行例) msinfo32 /nfo SVR_msinfo32.nfo

3. 生成されたファイルをご提供ください。
   

4.3 イベント ログ

1. 対象のマシンに管理者権限を保持するユーザーでログオンします。
2. [スタート] > [管理ツール] > [イベント ビューアー] を開きます。
3. 左側ペインの以下のイベントに対して、右クリックをし、[すべてのイベントを名前をつけて保存] を選択し、ファイルの種類が “イベント ファイル (.evtx)” であることを確認し、任意の名前を付けて、[保存] をクリックします。
   ※ ファイルの種類が “イベント ファイル (.csv)” も併せて取得をお願いいたします。
   a) [イベント ビューアー (ローカル)] - [Windows ログ] - [システム]
   b) [イベント ビューアー (ローカル)] - [Windows ログ] - [Application]
4. 保存したイベント ログ ファイルをご提供ください。

4.4 各種証明書の確認およびインポート

下記詳細手順のもと、証明書をご確認いただき、その画面キャプチャを zip などにおまとめの上ご提供お願いいたします。

証明書の確認方法

対象マシン上で [スタート] > [ファイル名を指定して実行] > “certlm.msc” と入力して [OK] を選択し、以下項目 4.4.1, 4.4.2 の証明書が存在するかご確認ください。
※ Windows Server 2012 以前の OS の場合は、MMC スナップインより証明書スナップインを起動してください。

4.4.1 個人 > 証明書

[個人] > [証明書] にて、下記 2 つの証明書が存在することを確認し、その画面キャプチャをご提供ください。
※ もし下記証明書が存在していなかった場合には、その点ご返信いただけますと幸いです。

・ CB_<MARS のバックアップを実施する予定の Recovery Services コンテナー名>-xx-xx-xxxx-vaultcredentials
・ CB_<ホスト名>._xxxxxxxxxxxxxxxxxx

もし「CB_<ホスト名>._xxxxxxxxxxxxxxxxxx」の証明書の期限がきれている場合には、MARS エージェントが正常に起動しない可能性があります。
その際には、下記を参考に MARS エージェントの再インストールを実施してください。それにより証明書も再インストールされます。
・ MARS エージェントの再インストール手順
　 https://jpabrs-scem.github.io/blog/MARSBackup/How_to_re-install/

4.4.2 信頼されたルート証明書 > 証明書

[信頼されたルート証明機関] > [証明書] にて、下記ドキュメントに記載されているルート証明書がすべて存在することを確認し、その画面キャプチャをご提供ください。

・ ルート証明機関 / Azure 証明機関の詳細 | Microsoft Learn
　 https://learn.microsoft.com/ja-jp/azure/security/fundamentals/azure-CA-details?tabs=root-and-subordinate-cas-list#root-certificate-authorities

また、ドキュメントに記載されているルート証明書の “Thumbprint” の値と、対象のマシンにて証明書をダブル クリックし、[詳細] > [拇印] で表示されている値が一致していることを確認し、その画面キャプチャを併せてご提供ください。

もし上記ドキュメントに記載されているルート証明書が一部存在していない場合には、MARS エージェントが正常に起動しない可能性があります。
その際には、下記 4-4-3. 証明書インポート手順 を参考に、証明書のインポートを実施してください。

4.4.3 証明書インポート手順

1. 証明書をインポートしたいマシンに、管理者権限でログインします。
2. [スタート] > [ファイル名を指定して実行] > “certlm.msc” と入力して [OK] を選択します。
   ※ Windows Server 2012 以前の OS の場合は、MMC スナップインより証明書スナップインを起動してください。
3. ユーザーアカウント制御が起動する場合は管理者権限での実行を許可します。
4. 左側の [証明書 (ローカル コンピューター)] を展開し、[信頼されたルート証明機関] > [証明書] を開きます。
5. [証明書] を右クリックし [すべてのタスク] > [インポート] を選択します。
6. 証明書のインポート ウィザードが起動しますので、下記の様に進めます。
   • 「証明書のインポート ウィザードの開始」画面で [次へ] をクリック。
   • 「インポートする証明書のファイル」にて、上記ドキュメントよりダウンロードした証明書を選択します。
   • 「証明書ストア」にて、[証明書をすべて次のストアに配置する] > [信頼されたルート証明機関] を選択します。
   • 「証明書のインポート ウィザードの完了」にて、[完了] を選択します。
7. [信頼されたルート証明機関] > [証明書] ストアに証明書がインポートされた事を確認します。

皆様こんにちは。Azure Backup サポートです。
今回は Azure Backup のバックアップ失敗、リストア失敗の時の調査をするにあたり、NW 観点で提供いただきたい情報をお伝えいたします。
NW 観点以外の情報採集提供依頼については下記をご覧ください
・ Azure Backup の障害調査に必要な情報
　 https://jpabrs-scem.github.io/blog/AzureBackupGeneral/RequestForInvestigating/

目次

1. Windows VM における Azure Backup 疎通確認
2. Linux VM における Azure Backup 疎通確認

1. Windows VM における Azure Backup 疎通確認

まず、下記リンク先から疎通確認スクリプトのダウンロードをお願いします。
Check_Backup_NW_ver1.7.zip

(スクリプト実行手順)

1. 疎通確認スクリプトをダウンロードし、展開してください。
   ※ ファイルの解凍パスワードは “AzureBackup” となります。

2. PowerShell を右クリックし、管理者として実行をクリックしてください。
   

3. PowerShell にて手順 1 で展開したスクリプトの場所に移動してください。
   例) “Takato” というユーザーのデスクトップ上の PowerShell というフォルダ内にスクリプトをダウンロードしたときの移動コマンド

   cd C:\Users\Takato\Desktop\powershell

4. 以下コマンドを実行し、スクリプトを実行してください。
   (現在画像とバージョンが異なりますが、同様の手順でございます。)

   .\Check_Backup_NW_ver1.3.ps1

   
   ※ 実行ポリシーの制限により上記スクリプトが実行できない場合には、PowerShell を管理者権限で起動し、下記コマンドより実行ポリシーの設定を変更後、再度スクリプトを実行していただけますと幸いです。

   Set-ExecutionPolicy Unrestricted

5. 以下のような “ScriptStart Completed” 出力がされるまで、お待ちください。
   ※ コマンドの実行には、環境によって 20 分ほど要する場合がございます。20 分経っても完了しない場合は、control + c を押下して強制終了してください。

   

6. コマンド実行が完了すると、スクリプトと同じフォルダ内に以下のようなログ ファイルが出力されますので、弊社までご提供お願いいたします。
   ログファイル名: AzureBackup_Check_NW_yyyymmdd_hhmmss.log

   
   ※ control + c にて強制終了した場合においても該当のログ ファイルが出力されますので、弊社までご提供お願いいたします。

2. Linux VM における Azure Backup 疎通確認

まず、下記 リンク先から疎通確認スクリプトのダウンロードをお願いします。
Check_Backup_NW_Linux_ver1.5.zip

(スクリプト実行手順)

1. 疎通確認スクリプトをダウンロードし、展開してください。
   ※ ファイルの解凍パスワードは “AzureBackup” となります。

2. 対象の Linux マシンにスクリプトを移動し実行します。
   必要に応じて chmod コマンドなどを用いてパーミッションを変更してください。

   chmod 777 Check_Backup_NW_Linux_ver1.4.sh

   下記のように実行します。

   ./Check_Backup_NW_Linux_ver1.4.sh

3. 実行完了
   実行が完了すれば下記のファイルが作成されますので、弊社までご提供お願いいたします。
   ログファイル名: CheckNWResult_(ホスト名)_(YYYYMMDDHHMM).log

   

こんにちは、Azure Backup サポートです。
今回は Azure Backup での異なる可用性ゾーンへの復元 ( = クロス ゾーン リストア / CZR ) についてご紹介します。
今回ご紹介する内容は、それぞれの公開情報に掲載されておりますが、一つのページに集約されておりません。
よくお問い合わせいただく内容ですので、本記事では情報を集約化してお伝えします。

目次

1. CZR を行うための各条件
 1-1. Azure VM の条件
 1-2. Recovery Services コンテナーの条件
 1-3. 利用できる復元オプション
2. 参考情報

1. CZR を行うための各条件

CZR を利用することで、Azure VM バックアップによって保護されている VM またはディスクを、復旧ポイントから別のゾーンに復元することができます。
CZR を利用するために Recovery Services コンテナーおよび Azure VM バックアップにより保護されている VM が満たすべき条件を下記にまとめました。

1-1. Azure VM の条件

CZR を行うためには、Azure VM バックアップにより保護されている VM が次の条件を満たす必要があります。

• マネージド VM であること
• クロス リージョン リストア (CRR) を行う場合、ゾーン固定 VM であること
• 暗号化された Azure VM ではないこと

Azure VM が特定の可用性ゾーンに固定されているかどうかを確認する方法

ご参考までに、Azure VM が可用性ゾーンに固定されているかどうかの、Azure ポータル画面での確認方法を説明いたします。
VMの概要欄に「可用性ゾーン xxx」 と表示されていれば、表示されているゾーンに固定されており、「可用性ゾーン xxx」 といった表示がない場合はゾーン固定されていないと判断できます。
たとえば、下記画像の VM 「CZR-stand-z1」は可用性ゾーン「ゾーン1」に固定されている状態です。

一方で下記画像の VM 「CZR-standard」はどのゾーンにも固定されていない状態となります。
(この場合は可用性ゾーンは空欄になります。)

1-2. Recovery Services コンテナーの条件

CZR は以下の条件を満たす Recovery Services コンテナーで行うことができます。

• Recovery Services コンテナーのストレージ レプリケーションの種類が「ゾーン冗長」、または「geo 冗長」かつ CRR が有効になっていること
• ただし、ストレージ レプリケーションの種類が「geo 冗長」かつ CRR が有効の場合は、セカンダリ リージョンへの復元を行う際にのみゾーン指定して復元可能
  ※ 1-1. Azure VM の条件 で説明の通り、ゾーン固定 VM である必要有
  ※ プライマリ リージョンへは CRR を有効化していてもゾーン指定して復元することは不可能
• 復旧ポイントの「回復の種類」が「スナップショットと Vault-Standard」もしくは「Vault-Standard」であること
  ※ 「スナップショット」のみの場合は、ゾーン指定して復元することは不可能

[!TIP]
CRR については下記の弊社ブログにて紹介しております。
・ Azure VM Backup におけるクロス リージョン リストア (CRR) について | Japan CSS ABRS Support Blog !! (jpabrs-scem.github.io)
　 https://jpabrs-scem.github.io/blog/AzureVMBackup/CRR/

セカンダリ リージョン (ペア リージョン) について、および可用性ゾーンをサポートしているリージョンについては下記ドキュメントをご覧ください。
・ Azure のリージョン間レプリケーション | Microsoft Learn
　 https://learn.microsoft.com/ja-jp/azure/reliability/cross-region-replication-azure#azure-paired-regions
・ Availability Zones をサポートする Azure サービス | Microsoft Learn
　 https://learn.microsoft.com/ja-jp/azure/reliability/availability-zones-service-support#azure-regions-with-availability-zone-support

Azure Portal で Recovery Services コンテナー の「ストレージ レプリケーションの種類」を確認する方法

ご参考までに、「ストレージ レプリケーションの種類」が「ゾーン冗長」に設定している場合の Azure ポータル画面上の見え方を説明いたします。
該当の Recovery Services コンテナー > 設定 - プロパティ > バックアップ構成 - 更新 ボタン から「ストレージ レプリケーションの種類」が確認できます。
たとえば、下記画像の Recovery Services コンテナーでは「ゾーン冗長」が設定されています。

Azure Portal で 復旧ポイントの「回復の種類」を確認する方法

ご参考までに、復旧ポイントの「回復の種類」を Azure ポータル画面にて確認する方法を説明いたします。

まずは該当の Recovery Services コンテナー > 保護されたアイテム - バックアップ アイテム > Azure Virtual Machine ボタンを選択します。

続いて確認したい VM の行にて、詳細 - View details ボタンを選択します。

すると選択した VM の復旧ポイント一覧が表示され、ここから「回復の種類」を確認できます。

1-3. 利用できる復元オプション

CZR は次の復元を行う場合にのみ利用できます。

• VM の作成
• ディスクの復元

なお、既存のディスクの置き換え はサポートされていません。

VM の作成

復旧ポイントから VM の新規作成を行う際、前述の条件を満たしている場合に、復元先の可用性ゾーンを指定することができます。

具体的な復元の手順は下記の公開情報をご覧ください。

• VM の作成 | Azure Backup を使用して Azure portal を使用して VM を復元する - Azure Backup | Microsoft Learn
  https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms#create-a-vm

ディスクの復元

復旧ポイントから ディスクの復元を行う際、前述の条件を満たしている場合に、復元先の可用性ゾーンを指定することができます。

具体的な復元の手順は下記の公開情報をご覧ください。

• ディスクを復元する | Azure Backup を使用して Azure portal を使用して VM を復元する - Azure Backup | Microsoft Learn
  https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms#restore-disks

2. 参考情報

• 復元オプション | Azure Backup を使用して Azure portal を使用して VM を復元する - Azure Backup | Microsoft Learn
  https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms#restore-options
• VM の作成 | Azure Backup を使用して Azure portal を使用して VM を復元する - Azure Backup | Microsoft Learn
  https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms#create-a-vm
• ディスクを復元する | Azure Backup を使用して Azure portal を使用して VM を復元する - Azure Backup | Microsoft Learn
  https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms#restore-disks
• セカンダリ リージョンに復元する | Azure Backup を使用して Azure portal を使用して VM を復元する - Azure Backup | Microsoft Learn
  https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms#restore-in-secondary-region
• サポートされる復元方法 | Azure VM バックアップのサポート マトリックス - Azure Backup | Microsoft Learn
  https://learn.microsoft.com/ja-jp/azure/backup/backup-support-matrix-iaas#supported-restore-methods
• FAQ-Azure VM をバックアップする - Azure Backup | Microsoft Learn
  https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-vm-backup-faq#azure-------------------------

皆様こんにちは、Azure Backup サポートです。
今回は、「VMSnapshot」拡張機能の再インストール手順 (Windows OS の場合) についてご案内いたします。

目次

1. 概要
2. 「VMSnapshot」拡張機能の再インストール手順 (Windows)

1. 概要

「VMSnapshot」拡張機能は、Azure VM Backup (Azure 仮想マシンをまるごとバックアップする機能) において、対象の Azure 仮想マシン上にインストールされる拡張機能です。
Azure VM Backup にて何らかのエラーが発生した場合、トラブルシューティングの一環として本記事の記載に従って「VMSnapshot」拡張機能を再インストールしていただき、再度バックアップを実行させることで、エラーが解消されるかを依頼する場合がございます。

・(参考) Azure VM バックアップについて - Azure Backup | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-vms-introduction#backup-process
　“Windows VM の場合、VMSnapshot 拡張機能がインストールされます。
　 Linux VM の場合、VMSnapshotLinux 拡張機能がインストールされます。”

・(参考) Azure Backup 用の VM スナップショットの Windows 拡張機能 - Azure Virtual Machines | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/virtual-machines/extensions/vmsnapshot-windows

なお、下記公開ドキュメント上では、Azure ポータル画面 > Azure 仮想マシン > [拡張機能とアプリケーション] 画面から、アンインストールすることができるという説明を記載しておりますが
これは アンマネージド ディスクから作成している Azure 仮想マシンの場合のみ となります。
マネージド ディスク の Azure 仮想マシンの場合は、本記事に従って 「VMSnapshot」拡張機能の再インストールをお試しください。

・(参考) ExtensionStuckInDeletionState - 拡張機能の状態がバックアップ操作に対応していません
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-vms-troubleshoot#extensionstuckindeletionstate---extension-state-is-not-supportive-to-the-backup-operation
　“バックアップ拡張機能 [VmSnapshot] または [VmSnapshotLinux] を選択し、 [アンインストール] を選択します。”

(画面例 : マネージド ディスク の Azure 仮想マシンの場合は、[拡張機能とアプリケーション] 画面上には「VMSnapshot」拡張機能は表示されません)

2. 「VMSnapshot」拡張機能の再インストール手順 (Windows)

• 1. PowerShell にて Azure アカウントにログインし、下記コマンドを実行し、該当の Azure 仮想マシン上から「VMSnapshot」拡張機能を削除してください

     (実行コマンド)

     1	Remove-AzVMExtension -ResourceGroupName "<Azure 仮想マシンのリソース グループ>" -VMName "<Azure 仮想マシン名>" -Name "VMSnapshot"

     上記コマンド実行後、「Y」を入力して、拡張機能の削除を指示します
     

     ・(参考) Remove-AzVMExtension (Az.Compute) | Microsoft Learn
     https://learn.microsoft.com/ja-jp/powershell/module/az.compute/remove-azvmextension?view=azps-11.0.0

• 2. 該当の Azure 仮想マシン にサインインし、Windows + r を押下して “ファイル名を指定して実行” を開き “services.msc” と入力して、サービスを開いてください
     

• 3. “Windows Azure Guest Agent” を右クリックし、停止をクリックして、サービスを停止してください
     

     

     

• 4. Windows + r を押下して “ファイル名を指定して実行” を開き “regedit” と入力して、レジストリエディターを開いてください
     

• 5. HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsAzure に移動し、これを安全な場所にエクスポートしてください

     (補足)
     レジストリ キーの値をあくまでバックアップ目的でエクスポート (退避) します
     「VMSnapshot」拡張機能が正常に再インストール完了すれば、こちらのエクスポートしたファイルは削除いただいて構いません

     

     

• 6. HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsAzure\HandlerState に移動し、Microsoft.Azure.RecoveryServices.VMSnapshot_X.X.X.X を削除してください
     (X.X.X.X は、マシン上の数字と読み替えてください)
     

     

• 7. 管理者権限にてコマンドプロンプトを開き以下のコマンド (2 つ) を実行してください

     (実行コマンド)

     1 2	REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v IsProviderInstalled /t REG_SZ /d False /f REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgentPersistentKeys" /v IsCommonProviderInstalled /t REG_SZ /d False /f

     

• 8. サービスより “Windows Azure Guest Agent” を右クリックし、開始をクリックして、サービスを開始してください
     

     

• 9. Windows Azure Guest Agent が正常に開始した段階で、再度マシン上には「Microsoft.Azure.RecoveryServices.VMSnapshot_X.X.X.X」のレジストリ キーが自動追加される想定ですが、
     念のため、次回の Azure VM Backup のスケジュール バックアップもしくは「今すぐバックアップ」より、バックアップをトリガーしてください

     ・(参考) バックアップをすぐに実行する
     https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-vms-first-look-arm#run-a-backup-immediately

• 10. Azure VM Backup ジョブが正常に完了することを確認してください
      もしバックアップ ジョブが正常に完了した場合には、手順 5 でエクスポートした下記ファイルは削除いただいて構いません
      ・ エクスポートしていたレジストリ キーのファイル

「VMSnapshot」拡張機能の再インストール手順 (Windows OS の場合) は以上となります。

皆様こんにちは、Azure Backup サポートです。
今回は、Azure VM Backup において、
「Standard バックアップ ポリシー (標準ポリシー) 」でバックアップを取得した場合と
「Enhanced バックアップ ポリシー (拡張ポリシー) 」でバックアップを取得した場合のそれぞれの料金の違いについて説明します。

(参考 関連ブログ記事)
・料金計算ツールを用いた Azure VM Backup の料金見積もりについて | Japan CSS ABRS Support Blog !! (jpabrs-scem.github.io)
　https://jpabrs-scem.github.io/blog/AzureVMBackup/VM_Backup_calculator/

目次

1. Standard バックアップ ポリシーと Enhanced バックアップ ポリシーの機能の違いについて
2. Standard バックアップ ポリシーと Enhanced バックアップ ポリシーの料金の違い
3. スナップショット料金の請求先について

1. Standard バックアップ ポリシーと Enhanced バックアップ ポリシーの機能の違いについて

それぞれのバックアップ ポリシーで Azure VM Backup を取得する場合の機能の違いは下記公開ドキュメントをご参照ください。
・拡張ポリシーを使用して Azure VM をバックアップする - Azure Backup | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-vms-enhanced-policy?tabs=azure-portal

2. Standard バックアップ ポリシーと Enhanced バックアップ ポリシーの料金の違い

Azure VM Backup の料金

Azure VM Backup を利用する場合、その料金を見積もる際には以下 3 点が課金項目となります。
　(1) Azure 仮想マシンのインスタンスに対する課金
　(2) Recovery Services コンテナーに保管されるバックアップ データに対する課金
　(3) Azure VM Backup の機能で取得されるスナップショットに対する課金

(1) と (2) の課金は、「Standard バックアップ ポリシー」でバックアップ取得しても、「Enhanced バックアップ ポリシー」でバックアップ取得しても、どちらも同じ料金計算方式となります。

この 2 項目は、下記公開ドキュメント上で説明している「保護されたインスタンス サイズ (1) 」「バックアップ ストレージの課金 (2) 」箇所に相当します。

(参考ドキュメント)
・バックアップのコスト
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-vms-introduction#backup-costs
　引用 : “保護されたインスタンス サイズの計算は、”実際の” VM のサイズに基づきます。”
　引用 : “同様に、バックアップ ストレージの課金は、Azure Backup に格納されているデータ量 (各回復ポイントの実際のデータの合計) に基づきます。”

いっぽう (3) の課金は、「Standard バックアップ ポリシー」でバックアップ取得する場合と、「Enhanced バックアップ ポリシー」でバックアップ取得する場合とで、料金の加算方法が変わってきます。

「Azure VM Backup の機能で取得されるスナップショットに対する課金」の加算方法の違い

「Standard バックアップ ポリシー」では、初回のスナップショット取得時点では料金は発生しません。
「Enhanced バックアップ ポリシー」では、初回のスナップショット取得時点で、使用データ量分のスナップショットに対して料金が発生します。

また、1 GB あたりの課金額は以下の通りそれぞれ違いがあります。

Standard (標準) ポリシー : 0.12 ドル/ 1 GB
Enhanced (拡張) ポリシー : 0.05 ドル/ 1 GB

※ リージョンにより料金が異なる場合がございます。(上記 および 以下の参考例は、USEast2 の価格となります。)

下記の表は 100 GB の容量をもつ Azure 仮想マシンに対して、毎日 1 GB の増分が発生するケースにおいて、スナップショットを 4 日間保管した場合の比較表となります。
※ 表中の料金は前日からの増分により発生した課金の月額を示しており、実際の料金は保存期間によって変動する場合があります。
(参考例)

※1 便宜上 100 GB と記載しておりますが、より正確には初回のスナップショット取得時点では 0 GB となります。
(その後の変更ブロック発生によりスナップショット サイズが増大いたします)

上記サンプルケースでは Enhanced バックアップ ポリシー 利用時の方が費用は高くなりますが、初回のバックアップ データ量が減った場合や、翌日以降の増分データ量が増加する場合は、Standard バックアップ ポリシー利用時の方が割高となるシナリオも考えられます。

「(3) Azure VM Backup の機能で取得されるスナップショットに対する課金」における
リージョン毎のスナップショット料金詳細は下記をご参照ください。

Standard バックアップ ポリシー - スナップショットに対する料金

下記リンクから、リージョン・通貨をご希望のものへと設定変更いただければ、スナップショットに対する料金を確認できます。
・Azure ページ BLOB Storage の価格 | Microsoft Azure
　https://azure.microsoft.com/ja-jp/pricing/details/storage/page-blobs/

Enhanced バックアップ ポリシー - スナップショットに対する料金

下記リンクから、リージョン・通貨をご希望のものへと設定変更いただければ、スナップショットに対する料金を確認できます。
・料金 - Managed Disks | Microsoft Azure
　https://azure.microsoft.com/ja-jp/pricing/details/managed-disks/

3. スナップショット料金の請求先について

　(1) Azure 仮想マシンのインスタンスに対する課金
　(2) Recovery Services コンテナーに保管されるバックアップ データに対する課金
　(3) Azure VM Backup の機能で取得されるスナップショットに対する課金

上記料金の請求書上では、各項目 および バックアップ ポリシーの違いによって、次に示す表のように表示されます。
Azure Backup の 料金として請求される項目は (1) (2) であり、(3) は スナップショットにかかった料金 として別の項目として請求されます。

　( 赤文字部分は、対象 Recovery Services コンテナーの「ストレージ レプリケーションの種類」によって変わります)

ご参考までに、弊社検証環境にて確認した各項目の表示例を以下に示します。
画像 1 : コスト分析画面にて確認した (1) および (2) の表示例（ストレージ レプリケーションの種類 : ローカル冗長 (LRS)）

画像 2 : コスト分析画面にて確認した (3) の表示例 (Standard バックアップ ポリシー)

(参考) 画像 2 のバックアップ対象 の VM の Azure Managed Disk のリソース グループ名 : rgsqlag

画像 3 : コスト分析画面にて確認した (3) の表示例 (Enhanced バックアップ ポリシー)

(参考) 画像 3 の復元ポイント コレクションのリソース グループ名 : azurebackuprg_eastus_1

(補足)
各バックアップ ポリシーにて取得されるスナップショットはそれぞれ以下のスナップショット層へ格納されます。
　・Standard バックアップ ポリシー : LRS のスナップショット層
　・Enhanced バックアップ ポリシー : ZRS のスナップショット層

(参考ドキュメント)
・拡張ポリシーを使用して Azure VM をバックアップする
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-vms-enhanced-policy?tabs=azure-portal
　引用 : “インスタント復元層では、ゾーン冗長ストレージ (ZRS) の回復性を使用してゾーン冗長性が確保されています。”

本記事の内容は以上となります。

みなさんこんにちは、Azure Backup サポートです。

MARS バックアップや SQL Server バックアップなどのバックアップにおいて、お客様によってはバックアップや復元で使用する通信がプロキシを経由する構成とされていることがあります。
ご利用のプロキシでテナント制限の構成をしている場合、Microsoft Entra ID (旧称 Azure Active Directory) への通信ができず、バックアップ対象のサーバーからバックアップサービス利用のための Azure 認証が失敗することで、バックアップの有効化をはじめとした各種操作ができないことがあります。

このブログでは、バックアップ対象のサーバーのプロキシ環境でテナント制限をしている場合のバックアップの失敗について、テナント制限が原因でバックアップが失敗しているかの判断方法と対応方法について記載してます。

目次

1. テナント制限とは
2. テナント制限されている場合の判断方法について (Azure Portal へのログインによる確認)
3. テナント制限されている場合の判断方法について (Backup のログからの確認)
4. 回避策について

1. テナント制限とは

以下のブログ引用に記載がございますが、テナント制限をすることでプロキシを経由した通信について特定の Microsoft Entra ID テナント以外のアクセスが制限されます。　

・ブログ引用

テナント制限の機能では、ユーザーがアクセス可能な Azure AD テナントを制限することが可能です。
具体的には、クライアント端末から Azure AD に対する認証の通信をプロキシ経由させ、そのプロキシから送信されるデータに許可対象の Azure AD テナントの情報を付与します。その結果、それ以外の Azure AD テナントへのアクセスがブロックされる動作となります。

・テナント制限とは | テナント制限について
https://jpazureid.github.io/blog/azure-active-directory/tenant-restriction/#%E3%83%86%E3%83%8A%E3%83%B3%E3%83%88%E5%88%B6%E9%99%90%E3%81%A8%E3%81%AF

2．テナント制限されている場合の判断方法について (Azure Portal へのログインによる確認)

バックアップ対象のサーバーから Azure Potal を利用しテナント制限によって許可されていないテナントへアクセスを試行すると、 「ネットワーク管理者によってアクセスがブロックされました」という以下のようなエラーメッセージが表示されます。 (エラーコード: AADSTS500021)
このメッセージを確認できた場合、テナント制限によりサーバーからのテナントアクセスが制限されていると判断できます。

・テナント制限とは | テナント制限について
https://jpazureid.github.io/blog/azure-active-directory/tenant-restriction/#%E3%83%86%E3%83%8A%E3%83%B3%E3%83%88%E5%88%B6%E9%99%90%E3%81%A8%E3%81%AF

以下のドキュメント引用からもテナント制限されている場合に出力されるエラーコードであることがわかります。

・ドキュメント引用

AADSTS500021
‘{tenant}’ テナントへのアクセスが拒否されました。 AADSTS500021 は、テナント制限機能が構成されており、ユーザーが、ヘッダー Restrict-Access-To-Tenant で指定されている許可されたテナントの一覧にないテナントにアクセスしようとしていることを示します。

・Microsoft Entra 認証と承認のエラー コード
https://learn.microsoft.com/ja-jp/azure/active-directory/develop/reference-error-codes

3．テナント制限されている場合の判断方法について (Backup のログからの確認)

バックアップ対象のサーバーのログからもテナント制限されているか確認することができます。
各ログに「AADSTS500021」の文字列がある場合、テナント制限されていると判断できます。

以下にログファイル名とログが格納されるディレクトリをご案内します。
(ログが格納されるディレクトリは既定の設定の場合を示しています)

＜Azure Backup for SQL in VM の場合＞

・ログファイル名
　WorkloadExtensionHandlerXX.log
・ディレクトリ
　WindowsAzure\Logs\Plugins\Microsoft.Azure.RecoveryServices.WorkloadBackup.AzureBackupWindowsWorkload\バージョン\WorkloadExtnLogFolder
・エラー出力例

Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException:
　AADSTS500021: Access to ‘IDMAADTenantjpepod01’ tenant is denied.

＜Microsoft Azure Recovery Services (MARS) の場合＞

・ログファイル名
　CBEngine XX.errlog
・ディレクトリ
　C:\Program Files\Microsoft Azure Recovery Services Agent\Temp
・ディレクトリ(MABS)
　C:\Program Files\Microsoft Azure Backup Server\DPM\MARS\Microsoft Azure Recovery Services Agent\Temp\
・エラー出力例

WARNING Exception in GetAADToken | Params: {Data = }{Message = AADSTS500021: Access to ‘IDMAADTenantjpepod01’ tenant is denied.

4．回避策について

バックアップが失敗している対象サーバーから「AADSTS500021」のメッセージが出力されている場合、テナント制限が原因でバックアップが失敗している可能性がございます。
ご利用のプロキシ環境において、以下テナントへのアクセス許可設定についてご確認ください。

Azure Backup では、O365 の以下のテナントに接続が必要です。
以下は、バックアップ利用の際に使用されるテナントになります。

IDMServiceAADTenant<リージョン>pod01.onmicrosoft.com

お客様の環境のリージョンに合わせて、以下テナントのアクセスを許可してください。
※現時点でテナント名やテナント ID の公開情報はないため、以下のリージョン以外のテナント名やテナント ID の確認がご希望の場合、Azure Backup の窓口へお問い合わせをお願いいたします。

＜東日本リージョンの Azure Backup のテナント情報＞

テナント名 : IDMServiceAADTenantjpepod01.onmicrosoft.com
テナント ID : 6e92595a-0b9c-49e4-a1e9-884d0ab4f4f0

＜西日本リージョンの Azure Backup のテナント情報＞

テナント名 : IDMServiceAADTenantjpwpod01.onmicrosoft.com
テナント ID : 4617fbbe-e76e-4071-90cd-6f5e7f5d5244

備考：
テナント制限の操作に関してご確認したい場合、Entra ID のお問合せをお願いいたします。
専門のエンジニアが対応することで円滑で正確な対応が可能となります。

みなさんこんにちは、Azure Backup サポートです。
今回は、「Oracle DB を導入している Azure 仮想マシンを Azure VM Backup でバックアップ/リストアすることは可能か」という点について説明します。

目次

1. Oracle DB を導入している Azure 仮想マシンを Azure VM Backup でバックアップ/リストアすることは可能か
1-1. Oracle DB が搭載される Azure 仮想マシンが Windows OS の場合
1-2. Oracle DB が搭載される Azure 仮想マシンが Linux OS の場合

1. Oracle DB を導入している Azure 仮想マシンを Azure VM Backup でバックアップ/リストアすることは可能か

「Azure VM Backup」は、Azure 仮想マシン単位でバックアップできるサービスです。
Azure 仮想マシン自体のバックアップ、リストアという観点では可能でございます。
ただし、対象 Azure 仮想マシン の OS が Windows か Linux かによって、取得されるスナップショットの整合性や、お客様にて参照いただきたい公開ドキュメントが異なってまいります。

・ スナップショットの整合性
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-vms-introduction#snapshot-consistency

Azure VM Backup をご利用いただくにあたって、前提となるサポート マトリックスや、一般的なバックアップ/リストア手順は下記をご参照ください。

・ Azure VM バックアップのサポート マトリックス - Azure Backup | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/backup/backup-support-matrix-iaas

・ Recovery Services コンテナーに Azure VM をバックアップする - Azure Backup | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-vms-prepare

・ Azure portal を使用して VM を復元する - Azure Backup | Microsoft Learn
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms

1-1. Oracle DB が搭載される Azure 仮想マシンが Windows OS の場合

Windows OS の Azure VM Backup を取得する際、仕様として OS 内部の VSS (ボリューム シャドウ コピー サービス) と呼ばれるサービスと連携してバックアップ データ (= スナップショット) を取得します。
VSS に対応したアプリケーションにおいては、アプリケーション レベルの整合性を担保したスナップショットを取得することが可能ですので、Oracle DB 側で VSS に対応していれば、「アプリケーション整合性」にてバックアップが取得可能です。
ご利用の Oracle DB が VSS に対応しているかが不明な場合は別途 Oracle 社にお問い合わせいただけますと幸いです。
もし、ご利用いただく予定の Oracle DB が VSS に対応していない場合、Oracle DB のアプリケーションの整合性は担保いたしませんが、Azure VM Backup 自体のバックアップ取得は可能でございます。

下記情報は弊社外のサイトでございますが、ご参考になれば幸いです。
弊社情報ではございませんのでその点ご留意ください。

・ (Oracle社) VSSを使用したデータベースのバックアップおよびリカバリの目的
※Oracle DB すべてが VSS に対応しているかはわかりかねますので、Oracle 社へとお問い合わせください。
　https://docs.oracle.com/cd/F19136_01/ntqrf/purpose-of-database-backup-and-recovery-with-vss.html#GUID-6A44D80C-0427-4DB8-AD3C-BD5426AECC2B

なおこの点は下記ブログにも同様の内容を説明しております。

・ 1.3 Oracle DB for Windows VM の Azure VM Backup について
　https://jpabrs-scem.github.io/blog/AzureVMBackup/Consistencies/#1-3

1-2. Oracle DB が搭載される Azure 仮想マシンが Linux OS の場合

以下二種類の方法いずれかで Oracle DB の「アプリケーション整合性」を担保したバックアップを取得することが可能となります。
（一種類目）Oracle データベースの バージョンが 12 未満 の場合、貴社にて事前/事後スクリプトをご準備いただくことで、Azure VM Backup にて「アプリケーション整合性」のバックアップが可能となります。
（二種類目）OS が 「Oracle Linux」 かつ、Oracle データベースの バージョンが 12.1 以上 の場合、貴社にて事前/事後スクリプトをご準備する必要なく、Azure VM Backup にて「アプリケーション整合性」のバックアップが可能となります。

必要な事前作業と DB 復元時の作業詳細については、以下ドキュメントをご参照ください。

・（一種類目 参考）Linux VM のアプリケーション整合性バックアップ - Azure Backup | Microsoft Docs
　https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-linux-app-consistent

・（二種類目 参考）Linux データベースのマネージド事前/事後スクリプトのサポート マトリックス
　https://learn.microsoft.com/ja-jp/azure/backup/backup-support-matrix-iaas#support-matrix-for-managed-pre-and-post-scripts-for-linux-databases
　 抜粋 :

・（二種類目 参考）Azure Backup を使用して Azure Linux VM で Oracle Database をバックアップおよび復旧する（作業詳細記載あり） - Azure Virtual Machines | Microsoft Docs
　https://learn.microsoft.com/ja-jp/azure/virtual-machines/workloads/oracle/oracle-database-backup-azure-backup?msclkid=f5e49016bd1811ec9d618313a2d3bc55&tabs=azure-portal
　“現在のところ、拡張フレームワークでサポートされているアプリケーションは Oracle 12.x 以降と MySQL です。”

説明は以上となります。

皆様こんにちは。Azure Backup サポートです。
今回は、Azure VM Backup で　[既存を置換] を用いる場合にいただくご質問について下記の通りご案内いたします。

目次

1. [既存を置換]の際、元のディスクはどうなるのか
2. [既存を置換]の際、 バックアップが走る件について
2.1. バックアップを走らせない方法 1
2.2. バックアップを走らせない方法 2

1. [既存を置換]の際、元のディスクはどうなるのか

結論から申し上げますと削除されずに残ります。
Azure VM Backup のリストアの [既存を置換] はバックアップ データよりディスクを復元し、 Azure VM のディスクを置き換えるまでを行います。
そのため、元の古いディスクは削除されずにディスク リソースとして残り続けます (課金も行われます)。そのため、不要な場合は手動で削除いただく必要がございます。

なお、リストアによって復元されるディスクの命名規則に関しては下記をご覧ください。
・Azure VM Backupでリストアされるディスク名に関して
https://jpabrs-scem.github.io/blog/AzureVMBackup/About_Restored_Disk/

下記公開情報にも記載されております。
・既存のものを置き換える - 復元オプション- Azure portal で Azure VM データを復元する方法
https://learn.microsoft.com/ja-jp/azure/backup/backup-azure-arm-restore-vms

ディスクの交換操作の後、元のディスクはリソース グループに保持されます。 元のディスクが必要ない場合は、それを手動で削除することを選択できます。

2. [既存を置換]の際、 バックアップが走る件について

現在の仕様として [既存を置換] のリストアを行う際には、ディスクを置き換える前の状態のバックアップを取得するために、リストアジョブと並行してバックアップ ジョブが自動で実施されます。

このバックアップ ジョブは、復元時のオプション [復元前のバックアップをスキップする] を有効化することで、スキップすることが可能でございます。
詳細につきましては、2.1. バックアップを走らせない方法 1 にてご案内いたします。

なお、バックアップを無効にしている、且つ復元時のオプション [復元前のバックアップをスキップする] を無効化していた場合には、バックアップ ジョブが失敗 (※) いたしますのであらかじめご注意ください。
(※) : バックアップ ジョブは失敗いたしますが、[既存を置換] のリストアは成功いたします。

2.1. バックアップを走らせない方法 1

[既存を置換] のリストア時のオプション [復元前のバックアップをスキップする] のチェックを有効化することで、リストア ジョブと並行して動作するバックアップ ジョブがスキップされます。

例)

2.2. バックアップを走らせない方法 2

そのほか、[既存を置換] のリストア時の自動で走るバックアップ ジョブを走らせたくない場合は [既存を置換] ではなく、[ディスクの復元] を実施いただき、復元したディスクを手動で Azure VM に対してスワップしていただくことが可能です。

Azure Portal ＞ 対象の仮想マシン ＞ 左ペインのディスク からディスクのスワップ、デタッチ＆アタッチ が可能です。
※　本作業を行った場合も、元々アタッチされていた OS ディスク・ データ ディスクはディスク リソースとして残り続けます。
　　ディスクのスワップ・デタッチ＆アタッチ後、元々アタッチされていた OS ディスク・ データ ディスクに対しては、お客様にて不要であれば削除いただけます。

みなさんこんにちは、Azure Migrate サポートです。
今回は Azure Migrate 機能を使って Azure へとマシンを移行後、不要となった Recovery Services コンテナーや、関連する Azure リソースを削除するときのポイントを説明します。

目次

ポイント 1 : 削除可能な Azure リソースについて
ポイント 2 : Recovery Services コンテナー上の削除作業について

ポイント 1 : 削除可能な Azure リソースについて

Azure Migrate 機能を使って Azure へとマシンを移行後、Azure Migrate 関連のリソースを削除したいという場合には
削除すべき Azure リソースは「Recovery Services コンテナー」リソース以外にも複数あります。
また、以下に挙げるシナリオ例によって、削除対象となる Azure リソースが異なってまいります。

• プライベート エンドポイント経由で Azure へと移行したのか
• 物理マシンを Azure へと移行したのか
• VMWare VM をエージェントレス方式で移行したのか

どのシナリオで、どの Azure リソースが削除対象になるのかは下記ドキュメントにまとめておりますので、シナリオ毎に確認ください。

• (参考) Azure Migrate プロジェクトの削除
  https://learn.microsoft.com/ja-jp/azure/migrate/how-to-delete-project

なお、Azure Migrate 関連の Azure リソースを確認する際には、Azure Migrate プロジェクトのリソース グループ > [非表示の型の表示] をクリックすることで、関連するすべてのリソースが表示されるようになります。

上記のとおり、各種リソースの削除が必要となるため、Azure Migrate プロジェクト用にリソース グループを作成することもご検討ください。
Azure Migrate プロジェクト用にリソース グループを作成することで、Azure Migrate プロジェクトが不要になった際に、各種リソースをリソース グループごと削除できるようになります。

ポイント 2 : Recovery Services コンテナー上の削除作業について

Azure Migrate プロジェクトに紐づいている Recovery Services コンテナーを削除する前には、Recovery Services コンテナー上に存在している複数項目の登録解除や削除作業が必要となります。
(先に削除しておかなければ、多くの場合 Recovery Services コンテナーの削除を指示してもエラーとなって Recovery Services コンテナーを削除できません。)

例えば下記作業などが事前に必要となります。

• Recovery Services コンテナーに登録されているレプリケーション ポリシーの削除
• Recovery Services コンテナーに登録されている Hyper-V サイトの削除
• Recovery Services コンテナーに紐づくプライベート エンドポイントの削除

ただし、[PowerShell スクリプトを使用して削除する] をご利用いただく場合は、スクリプトによって
「Recovery Services コンテナー上の関連付け項目の削除」から「Recovery Services コンテナーの削除」まで自動的に行われ、より簡単に削除できます。

• (参考) Site Recovery Services コンテナーを削除する
  https://learn.microsoft.com/ja-jp/azure/site-recovery/delete-vault

• (参考) ポリシーを編集する | レプリケーション ポリシーの関連付け解除と削除
  https://learn.microsoft.com/ja-jp/azure/site-recovery/vmware-azure-set-up-replication#edit-a-policy

• (参考) VMM サーバーの登録解除
  https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-manage-registration-and-protection#unregister-a-vmm-server

• (参考) Hyper-V サイト上の Hyper-V ホストの登録解除
  https://learn.microsoft.com/ja-jp/azure/site-recovery/site-recovery-manage-registration-and-protection#unregister-a-hyper-v-host-in-a-hyper-v-site

また、Recovery Services コンテナーと関連するリソースに対し、削除のロックがかかっている場合、ロックを解除してから削除する必要があります。
ロックについては、ご利用の Azure Migrate プロジェクトのリソース グループ > ロックからロックされているリソースが確認できます。

Azure Migrate 観点では、移行が完了しており、かつ対象の Recovery Services コンテナーが現在その他のレプリケーション等で使用されていない場合、対象の Recovery Services コンテナーの削除を行っても 移行元VM ・移行先 Azure VM・ネットワークには影響いたしません。
対象の Recovery Services コンテナーが使用されているかどうかの確認 (現在バックアップもしくはレプリケーションが行われているかどうかの確認) は、お客様にてご確認の上、削除の判断をお願いいたします。

本記事の内容は以上となります。