Azure Backup のレポートを構成する

バックアップ管理者の一般的な要件は、長期間にわたるデータに基づいて、バックアップに関する分析情報を得ることです。 このようなソリューションのユース ケースには、次のようなものがあります。

  • 使用されるクラウド ストレージの割り当てと予測。
  • バックアップおよび復元の監査。
  • さまざまな細分性レベルで主要な傾向を特定する。

現在、Azure Backup では、Azure Monitor ログAzure ブックを使用するレポート ソリューションが提供されます。 これらのリソースにより、バックアップ資産全体でバックアップに関する豊富な分析情報を得ることができます。 この記事では、Azure Backup レポートを構成および表示する方法について説明します。

サポートされるシナリオ

  • バックアップ レポートは、Azure VM、Azure VM の SQL、Azure VM の SAP HANA、Microsoft Azure Recovery Services (MARS) エージェント、Microsoft Azure Backup Server (MABS)、System Center Data Protection Manager (DPM)、Azure Database for PostgreSQL サーバー、Azure BLOB、Azure ディスクでサポートされています。 Azure ファイル共有のバックアップの場合、2020 年 6 月 1 日以降に作成されたレコードのデータが表示されます。
  • Azure ファイル共有のバックアップでは、2021 年 2 月 1 日より後に作成されたレコードについて、保護されたインスタンス上のデータが表示されます (古いレコードの既定値は 0 です)。
  • DPM ワークロードの場合、バックアップ レポートは DPM バージョン 5.1.363.0 以降、およびエージェント バージョン 2.0.9127.0 以降でサポートされています。
  • MABS ワークロードの場合、バックアップ レポートは MABS バージョン 13.0.415.0 以降、およびエージェント バージョン 2.0.9170.0 以降でサポートされています。
  • バックアップ レポートは、ユーザーがアクセスできる Log Analytics ワークスペースにデータが送信されている限り、すべてのバックアップ項目、コンテナー、サブスクリプション、およびリージョンにわたって表示できます。 一連のコンテナーのレポートを表示するには、コンテナーがデータを送信している Log Analytics ワークスペースへの閲覧者アクセス権のみが必要です。 個々のコンテナーへのアクセス権は必要ありません。
  • お客様が、ご自分の顧客のサブスクリプションへの委任アクセス権を持つ Azure Lighthouse ユーザーである場合は、Azure Lighthouse でこれらのレポートを使用して、ご利用のすべてのテナントにわたってレポートを表示することができます。
  • 現時点では、データは最大で 100 個の Log Analytics ワークスペースにわたって (複数のテナントにわたって) バックアップ レポートで表示できます。

    Note

    クエリの複雑さと処理されるデータの量によっては、多数のワークスペース (場合によっては 100 未満) を選択するときにエラーが発生する可能性があります。 一度にクエリを実行するワークスペースの数を制限することをお勧めします。

  • ログ バックアップ ジョブのデータは、現在レポートに表示されません。

注意

以下のセクションで説明されている機能には、バックアップ センター経由でもアクセスできます。 バックアップ センターは、Azure における単一の統合管理エクスペリエンスです。 それを使用して、企業は大規模なバックアップを管理、監視、運用、分析することができます。 このソリューションを使用すると、個々のコンテナーのスコープに限定されずに、主なバックアップ管理操作のほとんどを実行できます。

はじめに

レポートの使用を開始するには、次の手順に従います。

1.Log Analytics ワークスペースを作成するか、既存のものを使用する

バックアップ レポート データを格納するために、1 つ以上の Log Analytics ワークスペースを設定します。 この Log Analytics ワークスペースを作成できる場所とサブスクリプションは、コンテナーが存在する場所とサブスクリプションとは関係ありません。

Log Analytics ワークスペースを設定する場合は、「Azure portal で Log Analytics ワークスペースを作成する」を参照してください。

既定では、Log Analytics ワークスペースのデータは 30 日間保持されます。 より長期間のデータを表示するには、Log Analytics ワークスペースの保持期間を変更します。 保持期間を変更するには、「Azure Monitor Logsでのデータの保持ポリシーとアーカイブポリシーの構成」を参照してください。

2.コンテナーの診断設定を構成する

Recovery Services コンテナーなどの Azure Resource Manager リソースは、スケジュールされた操作およびユーザーがトリガーした操作に関する情報を診断データとして記録します。 コンテナーに対して診断設定を構成するには、次の手順に従います。

コンテナーの種類を選択します

Recovery Services コンテナーの監視セクションで [診断設定] を選択し、Recovery Services コンテナーの診断データのターゲットを指定します。 診断イベントの使用方法の詳細については、「Recovery Services コンテナーの診断設定を使用する」を参照してください。

Recovery Services コンテナー診断の設定のスクリーンショット。

Azure Backup には、特定のスコープ内のすべての Recovery Services コンテナーに対する診断設定の構成を自動化する組み込みの Azure Policy 定義も用意されています。 このポリシーの使用方法については、「大規模なコンテナーの診断設定を構成する」を参照してください。

注意

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

3.Azure portal でレポートを表示する

Log Analytics にデータを送信するようにコンテナーを構成したら、バックアップ センターに移動して [バックアップ レポート] を選択し、バックアップ レポートを表示します。 [作業の開始] タブで、関連するワークスペースを選択します。

バックアップ レポートのエントリのスクリーンショット。

レポートには、さまざまなタブが含まれています。

まとめ

このタブを使用して、バックアップ資産の概要を大まかに把握します。 バックアップ項目の合計数、使用されたクラウド ストレージの合計、保護されたインスタンスの数、ワークロードの種類あたりのジョブ成功率を一目で確認できます。 特定のバックアップ成果物の種類に関する詳細については、それぞれのタブにアクセスしてください。

バックアップ レポートの [概要] タブのスクリーンショット。

バックアップ項目

このタブを使用して、バックアップ項目レベルで使用されたクラウド ストレージの情報および傾向を確認します。 たとえば、Azure VM バックアップで SQL を使用している場合は、バックアップされている SQL データベースごとに使用されたクラウド ストレージを確認できます。 また、特定の保護状態のバックアップ項目のデータを表示するように選択することもできます。 たとえば、タブの上部にある [保護停止] タイルを選択すると、その下のすべてのウィジェットがフィルター処理され、[保護停止] 状態のバックアップ項目のデータのみが表示されます。

[バックアップ項目] タブ

使用法

このタブを使用して、バックアップの主要な請求先パラメーターを表示します。 このタブに表示される情報は、請求先エンティティ (保護されたコンテナー) レベルです。 たとえば、Azure にバックアップされている DPM サーバーの場合、DPM サーバーで消費される保護されたインスタンスとクラウド ストレージの傾向を表示できます。 同様に、Azure Backup の SQL または Azure Backup の SAP HANA を使用している場合、このタブには、これらのデータベースが含まれている仮想マシンのレベルでの使用に関する情報が表示されます。

[使用] タブ

Note

  • Azure ファイル、Azure BLOB、Azure ディスクのワークロードの場合、消費されるストレージは 0 と表示されます。 これは、フィールドでは、Azure ファイル、Azure BLOB、Azure ディスクに対して、コンテナーで使用されるストレージを参照するためです。レポートで現在サポートされているのは、スナップショット ベースのバックアップ ソリューションのみです。
  • DPM ワークロードの場合、レポートに表示されている使用量の値が、Recovery Services コンテナーの [概要] タブに表示されている使用量の集計値と比較してわずかに (DPM サーバーごとに 20 MB ほど) 異なることが、ユーザーから確認できることがあります。この違いは、バックアップ用に登録されているすべての DPM サーバーに、レポート用の成果物として表示されない "メタデータ" データソースが関連付けられているという事実によって説明されます。
ジョブ

このタブを使用して、1 日あたりの失敗したジョブの数やジョブの失敗の主な原因など、ジョブの長期傾向を表示します。 この情報は、集約レベルとバックアップ項目レベルの両方で表示できます。 グリッド内の特定のバックアップ項目を選択して、選択した時間の範囲内のそのバックアップ項目でトリガーされた各ジョブの詳細情報を表示します。

[ジョブ] タブ

Note

Azure Database for PostgreSQL、Azure BLOB、Azure ディスクのワークロードの場合、転送されたデータ フィールドは現在 [ジョブ] テーブルでは使用できません。

ポリシー

このタブを使用して、関連する項目の数や、特定のポリシーでバックアップされた項目によって使用されたクラウド ストレージの合計など、アクティブなすべてのポリシーに関する情報を表示します。 特定のポリシーを選択して、関連する各バックアップ項目に関する情報を表示します。

[ポリシー] タブ

最適化

このタブを使用すると、バックアップに関するコストを最適化できる潜在的な機会を把握できます。 以下に示すのは、[最適化] タブで得られる分析情報に関するシナリオです。

非アクティブなリソース

このビューを使用すると、長期間バックアップが正常に完了していないバックアップ項目を識別できます。 これは、バックアップ対象の基になっているマシンがもう存在しないこと (そしてバックアップの失敗に至っていること)、またはマシンに、バックアップが確実に作成されることを妨げている何らかの問題があることのいずれかを意味する可能性があります。

アクティブでないリソースを表示するには、 [最適化] タブに移動し、 [Inactive Resources] (非アクティブ リソース) タイルを選択します。 このタイルを選択すると、選択したスコープに存在するすべての非アクティブ リソースの詳細が含まれるグリッドが表示されます。 既定では、グリッドに、過去 7 日間に復旧ポイントがない項目が表示されます。 異なる時間範囲の非アクティブ リソースを見つけるには、タブの上部にある [時間の範囲] フィルターを調整します。

非アクティブ リソースを識別したら、そのリソースのバックアップ項目ダッシュボードまたは Azure リソース ペインの該当する方に移動して、問題をさらに調査できます。 実際の状況に応じて、マシンのバックアップを停止して (マシンが存在しなくなった場合) 不要なバックアップを削除する (それがコストの節約になります) か、マシンの問題を修正してバックアップが確実に行われるようにすることができます。

[最適化] タブ - [Inactive Resources]\(非アクティブ リソース\)

Note

Azure Database for PostgreSQL、Azure BLOB、Azure ディスクのワークロードの場合、非アクティブなリソース ビューは現在サポートされていません。

保有期間が長いバックアップ項目

このビューを使用すると、組織が必要としているよりも長い期間バックアップが保持されている項目を識別できます。

[ポリシーの最適化] タイルを選択してから [Retention Optimizations] (保有期間の最適化) タイルをクリックすると、日単位、週単位、月単位、または年単位の保有ポイント (RP) の保有期間が、指定した値よりも大きいすべてのバックアップ項目を含むグリッドが表示されます。 既定では、選択したスコープ内のすべてのバックアップ項目がグリッドに表示されます。 日単位、週単位、月単位、および年単位の RP 保有期間のフィルターを使用して、グリッドをさらに絞り込むことができます。また、保有期間を短縮してバックアップ ストレージのコストを節約できる可能性のある項目を識別することもできます。

SQL や SAP HANA のようなデータベース ワークロードの場合、グリッドに表示される保有期間は、差分バックアップ ポイントではなく、完全バックアップ ポイントの保有期間に対応しています。 保有フィルターにも同じことが当てはまります。

[最適化] タブ - [Retention Optimizations]\(保有期間の最適化\)

Note

Vault-Standard 層を使用しているバックアップ インスタンスの場合、保有期間の最適化グリッドでは、Vault-Standard 層の保有期間が考慮されます。 コンテナー層を使用していないバックアップ インスタンス (Azure ディスク バックアップ ソリューションによって保護された項目など) の場合、グリッドではスナップショット層の保有期間が考慮されます。

毎日の完全バックアップ用に構成されたデータベース

このビューを使用すると、毎日完全バックアップを行うように構成されているデータベース ワークロードを識別できます。 多くの場合、毎日の差分バックアップと毎週の完全バックアップを併せて使用すると、コスト効率が向上します。

[ポリシーの最適化] タイルをクリックしてから [バックアップ スケジュールの最適化] タイルを選択すると、毎日の完全バックアップ ポリシーが設定されているすべてのデータベースを含むグリッドが表示されます。 特定のバックアップ項目に移動し、毎週の完全バックアップと毎日の差分バックアップを併用するようにポリシーを変更することができます。

グリッドに予期したとおりデータベース ワークロードを表示できるようにするには、タブの上部にある [バックアップ管理の種類] フィルターでは、 [Azure VM での SQL][Azure VM での SAP HANA] の項目が選択されている必要があります。

[最適化] タブ - [Backup Management Type]\(バックアップ管理の種類\)

ポリシー準拠

このタブを使用すると、すべてのバックアップ インスタンスで毎日少なくとも 1 回のバックアップが成功したかどうかを確認できます。 週単位のバックアップ ポリシーが設定されている項目の場合、このタブを使用すると、すべてのバックアップ インスタンスで 1 週間に少なくとも 1 回のバックアップが成功したかどうかを確認できます。

使用できるポリシー準拠ビューには、次の 2 種類があります。

  • 期間ごとのポリシー準拠: このビューを使用すると、特定の日に少なくとも 1 回のバックアップが成功した項目の数と、その日に正常にバックアップされなかった項目の数を特定できます。 行をクリックすると、選択した日にトリガーされたすべてのバックアップ ジョブの詳細を確認できます。 時間の範囲を過去 60 日間などの大きな値に広げると、グリッドは週単位のビューで表示され、特定の週の各曜日で 1 回以上バックアップが成功したすべての項目の数が表示される点に注意してください。 同様に、広い時間範囲には月単位のビューがあります。

週単位でバックアップされた項目の場合、このグリッドは、特定の週に 1 回以上バックアップが成功したすべての項目を識別するのに役立ちます。 過去 120 日間などのより広い時間範囲の場合、グリッドは月単位のビューで表示され、特定の月の各週に 1 回以上バックアップが成功したすべての項目の数が表示されます。 日単位、週単位、および月単位のビューの詳細については、「バックアップ レポートで使用される規則」を参照してください。

期間ごとのポリシー準拠

  • バックアップ インスタンスごとのポリシー準拠: このビューを使用すると、バックアップ インスタンス レベルでポリシー準拠の詳細を確認できます。 緑色のセルは、特定の日のバックアップ インスタンスに少なくとも 1 回の成功したバックアップがあることを示します。 赤色のセルは、特定の日のバックアップ インスタンスに成功したバックアップが 1 つもないことを示します。 日単位、週単位、および月単位の集計は、期間ごとのポリシー準拠ビューと同じ動作に従います。 任意の行をクリックすると、選択した時間の範囲内の特定のバックアップ インスタンスにあるすべてのバックアップ ジョブを表示できます。

バックアップ インスタンスごとのポリシー準拠

Azure Backup レポートをメールで送信する

バックアップ レポートで使用できるメール レポート機能を使用すると、自動化されたタスクを作成して、メールで定期的なレポートを受信できます。 この機能を利用するには、指定した入力に基づいて、選択した Log Analytics (LA) ワークスペースからデータのクエリを実行するロジック アプリを Azure 環境にデプロイします。

ロジック アプリを作成したら、Azure Monitor Logs と Office 365 への接続を承認する必要があります。 これを行うには、Azure portal で [ロジック アプリ] に移動し、作成したタスクの名前を検索します。 [API 接続] メニュー項目を選択すると、承認する必要のある API 接続の一覧が開きます。 電子メールの構成と問題のトラブルシューティング方法について参照してください

Azure Backup レポートをカスタマイズする

バックアップ レポートには、Azure Monitor ログに対するシステム関数が使用されます。 これらの関数を使用して、LA の未加工の Azure Backup テーブルのデータを操作し、書式を設定したデータを返すことができます。これにより、簡単なクエリを使用して、バックアップ関連のすべてのエンティティの情報を簡単に取得できます。

バックアップ レポートをベースとして使用して独自のレポート ブックを作成するには、[バックアップ レポート] に移動し、レポートの上部にある [編集] をクリックして、レポートに使用されているクエリを表示して編集します。 カスタム レポートの作成方法の詳細については、Azure ブックのドキュメントを参照してください。

Excel へのエクスポート

任意のウィジェット (テーブルやグラフなど) の右上にある下矢印ボタンを選択すると、既存のフィルターが適用されたままの状態で、そのウィジェットの内容が Excel シートとしてエクスポートされます。 テーブルの行をさらに Excel にエクスポートする場合は、各グリッドの上部にある [ページごとの行] ドロップダウン矢印を使用して、ページに表示される行の数を増やすことができます。

[ダッシュボードにピン留めする]

ウィジェットを Azure portal のダッシュボードにピン留めするには、各ウィジェットの上部にあるピン ボタンを選択します。 この機能は、必要とする最も重要な情報を表示するために調整された、カスタマイズされたダッシュボードを作成するのに役立ちます。

テナント間のレポート

複数のテナント環境にわたるサブスクリプションへの委任アクセス権を持つ Azure Lighthouse を使用する場合は、既定のサブスクリプション フィルターを使用できます。 Azure portal の右上隅にある フィルター ボタンを選択して、データを表示するすべてのサブスクリプションを選択します。 これにより、テナント全体で Log Analytics ワークスペースを選択して、マルチテナント レポートを表示できます。

バックアップ レポートで使用される規則

  • フィルターは、各タブで左から右、上から下に処理されます。つまり、フィルターは、そのフィルターの右側または下に配置されているすべてのウィジェットにのみ適用されます。
  • 色分けされたタイルを選択すると、そのタイルの値に関連するレコードについて、そのタイルの下のウィジェットがフィルター処理されます。 たとえば、 [バックアップ項目] タブの [保護停止] タイルを選択すると、下のグリッドとグラフがフィルター処理され、[保護停止] 状態のバックアップ項目のデータが表示されます。
  • 色分けされていないタイルは選択できません。
  • まだ終わっていない現在日のデータはレポートに表示されません。 そのため、 [時間の範囲] の選択値が [過去 7 日間] の場合、レポートには過去 7 日間のレコードが表示されます。 現在の日付は含まれません。
  • レポートには、選択した時間の範囲内に "トリガーされた" ジョブの詳細 (ログジョブとは別のもの) が表示されます。
  • クラウド ストレージ保護されたインスタンスについて表示される値は、選択した時間の範囲の "終了" 時のものです。
  • レポートに表示されるバックアップ項目は、選択した時間の範囲の "終了" 時に存在する項目です。 選択した時間の範囲の間に削除されたバックアップ項目は表示されません。 バックアップ ポリシーにも同じ規則が適用されます。
  • 選択した時間範囲の期間が 30 日以下の場合は、毎日 1 つのデータポイントがある日単位のビューでグラフが表示されます。 時間範囲が 30 日より長く、90 日以下の期間にわたっている場合、グラフは週単位のビューで表示されます。 より広い時間範囲の場合は、月単位のビューでグラフが表示されます。 週単位または月単位でデータを集計すると、クエリのパフォーマンスが向上し、グラフ内のデータが読みやすくなります。
  • ポリシー準拠のグリッドは、前述のものと同様の集計ロジックに従います。 ただし、若干の違いがいくつかあります。 最初の違いは、週単位のバックアップ ポリシーを持つ項目では、日単位のビューがないことです (週単位および月単位のビューのみ使用可能)。 さらに、週単位のバックアップ ポリシーを持つ項目のグリッドでは、"月" は 30 日ではなく 4 週間の期間 (28 日) と見なされ、一部の週が考慮されなくなります。

トラブルシューティングの方法

バックアップ レポートでデータの不一致の問題が発生した場合は、以下の予備チェックを行います。

  1. すべてのコンテナーが必要な診断ログを Log Analytics ワークスペースに送信していることを確認します。

  2. バックアップ レポートで適切なフィルターを選択していることを確認します。

  3. バックアップ レポートの以下の制限を確認します。

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

    • SQL ログ バックアップ ジョブは現在、バックアップ レポートに表示されません。

    • 前述のように、レポートには現在日の部分的なデータは表示されず、完全な 1 日 (UTC) しか考慮されません。

      たとえば、レポートでは、3/23 4:30 PM – 3/24 10:00 AM の時間範囲を選択しても、内部的には、3/23 12:00 AM UTC – 3/24 11:59 PM UTC の期間でクエリが実行されます。 つまり、datetime の時刻コンポーネントはクエリによってオーバーライドされます。

      同様に、今日の日付が 3 月 29 日の場合、データは 3 月 28 日の終了時 (午後 11:59 UTC) までしか表示されません。 3 月 29 日に作成されたジョブについては、翌日 (3 月 30 日) にレポートを確認すると表示されます。

上記のいずれでもデータがレポートに表示されない場合は、Microsoft サポートにお問い合わせください。

クエリの読み込み回数

バックアップ レポートのウィジェットは、ユーザーの Log Analytics ワークスペースで実行される Kusto クエリを使用して機能します。 これらのクエリには、通常、大量のデータの処理が伴い、豊富な分析情報を得るために複数の結合が使用されます。 その結果、ユーザーが大規模なバックアップ資産全体にわたるレポートを表示するときに、ウィジェットが即座に読み込まれない可能性があります。 次の表は、さまざまなウィジェットの読み込みにかかる大まかな推定時間を示しています。これは、バックアップ項目の数とレポートが表示される時間の範囲に基づきます。

データ ソースの数 期間 おおよその読み込み時間
~ 5000 回 1 か月 タイル:5 ~ 10 秒
グリッド:5 ~ 10 秒
グラフ:5 ~ 10 秒
レポート レベルのフィルター:5 ~ 10 秒
~ 5000 回 3 か月 タイル:5 ~ 10 秒
グリッド:5 ~ 10 秒
グラフ:5 ~ 10 秒
レポート レベルのフィルター:5 ~ 10 秒
~ 10000 回 3 か月 タイル:15 ~ 20 秒
グリッド:15 ~ 20 秒
グラフ:1 ~ 2 分
レポート レベルのフィルター:25 ~ 30 秒
~ 15000 回 1 か月 タイル:15 ~ 20 秒
グリッド:15 ~ 20 秒
グラフ:50 ~ 60 秒
レポート レベルのフィルター:20 ~ 25 秒
~ 15000 回 3 か月 タイル:20 ~ 30 秒
グリッド:20 ~ 30 秒
グラフ:2 ~ 3 分
レポート レベルのフィルター:50 ~ 60 秒

Power BI レポートの変更点

  • レポート作成用の以前の Power BI テンプレート アプリ (Azure ストレージ アカウントのデータをソースとしていました) は、非推奨となる予定です。 レポートを表示するために、Log Analytics へのコンテナーの診断データの送信を開始することをお勧めします。

  • また、ストレージ アカウントまたは LA ワークスペースに診断データを送信する V1 スキーマも、非推奨のパスにあります。 これは、V1 スキーマに基づいてカスタム クエリまたは自動化を記述していた場合は、現在サポートされている V2 スキーマを使用するようにそれらのクエリを更新することが推奨されていることを意味します。

次のステップ

監視とレポート作成の詳細については、Azure Backup をご参照ください。