バックアップ プランの違反を特定する

ポリシー テンプレートとリソース プロファイルは、管理コンソールの [バックアップ プラン] セクションで定義します。これらの設定は、App Manager のアプリケーションと VM に適用されます。バックアップ プランの違反は、ジョブ（またはアクション）がポリシー テンプレートのポリシーで定義された要件を満たしていない場合に発生します。

このセクションでは、バックアップ プラン違反の考えられる原因、管理コンソールでバックアップ プラン違反が発生したときに特定される方法、発生したバックアップ プラン違反をモニタリングするために使用できる方法について詳しく説明します。これには次のものが含まれます。

バックアップ プランのポリシー違反の考えられる原因

管理コンソールでは、バックアップ プランをアプリケーションとデータセットに適用します。App Manager サービスでのアプリケーション コピーデータの管理は、バックアップ テンプレートで定義したルールと、それに関連付けられたポリシーに基づいています。バックアップ テンプレートには、データソース（スナップショットまたはレプリケーション）と各データソースのスケジュール（頻度、保持、開始時間、終了時間）を定義する 1 つ以上のポリシーが含まれています。バックアップ プランの違反は、バックアップ プラン ポリシーで定義されているジョブ（またはアクション）がポリシーのスケジュールに従って開始されない場合、発生します。

各バックアップ/リカバリ アプライアンスは、1 時間ごとにバックアップ プランの分析を自動的に実行し、スケジュールされたジョブでバックアップ プラン違反が発生したときに特定できるようにします。このバックグラウンド オペレーションは、バックアップ プラン ポリシーの期間の終了にできるだけ近づいて、バックアップ プラン違反の可能性をアラートします。バックアップ/リカバリ アプライアンスがバックアップ プラン違反をモニタリングする方法をご覧ください。

管理コンソールでは、管理者がポリシー テンプレートのライブラリを作成できます。各バックアップ プラン ポリシーの主な特徴の 1 つは、このポリシーの実行タイミングを決定するスケジュールです。

バックアップ プラン違反は、多くの場合、ジョブ スロット数の設定に関する問題が原因と見なされます。スロット数は、同時に実行できるジョブの数を決定します。ただし、ジョブスロット数を増やしても、バックアップ プラン違反が停止するとは限りません。実際には、バックアップ プランの違反は、次のセクションで説明するいずれかの条件に関連している可能性があります。

失敗したジョブ

バックアップ プラン違反の一般的な原因は、ジョブが失敗することです。たとえば、Oracle ホストにアクセスできない場合、バックアップ/リカバリ アプライアンスは Oracle RMAN からデータをキャプチャできず、スナップショット ジョブが失敗します。ジョブが失敗した場合は、環境を確認して、すべてのアプリケーションとホストにアクセスできることを確認します。

ホストあたり複数のアプリケーション

ホストに複数のアプリケーションがあり、各アプリケーションが（整合性グループとしてグループ化されるのではなく）個別のポリシー テンプレートによって管理されている場合、空きスロットがある場合でも、一度に実行できるスナップショット ジョブは 1 つのアプリケーションに限られます。

VM が VM として管理され、バックアップと DR エージェントによって管理されるアプリケーションも含まれている場合、一度に実行できるデータ キャプチャ ジョブは 1 つのアプリケーションに限られます。

ホストに D:\、E:\、F:\ ドライブがあり、個々のドライブが個別のバックアップ テンプレートで管理されている場合、各ドライブは順番に管理されます。たとえば、ポリシーの実行可能時間帯が 01:00（UTC）～ 03:00（UTC）で、最初のドライブのスナップショット ジョブの完了に 3 時間かかる場合、他の 2 つのドライブはその日のスナップショット ジョブを実行しません。

考えられる解決策の 1 つは、バックアップ プラン ポリシーのウィンドウを延長して、合計実行時間を延長することです。別の解決策として、複数のアプリケーションを整合性グループに含めることもできます。

バックアップ プランの違反は誤検出である可能性があります

バックアップ プランの違反が実際には誤検出（特定の条件が存在することを誤って示す結果）である場合があります。バックアップ プランの違反がすべて実際の違反であるとは限りません。次の 2 つの例に示すように、誤検出が発生する可能性があります。

  • クラスタ化されたボリュームを持つ VM のコピーデータを管理している。バックアップ プラン ポリシーが実行されていても、VM がボリュームを制御していない場合、この障害はバックアップ プラン違反と見なされます。
  • ジョブ（VM、アプリケーションなど）でバックアップ プラン ドリブンのスケジューラがオフになっている場合、バックアップ プラン ポリシーを適用するたびにバックアップ プラン違反が発生する可能性があります。

バックアップ/リカバリ アプライアンスの制約付きリソース

バックアップ/リカバリ アプライアンスでリソースが制限されている場合は、ネットワーク ポートのスループット、iSCSI イニシエータの最大数、バックエンド ストレージまたはフロントエンド ストレージのスループット能力などの問題が考えられます。この場合、スロット数を増やしても効果はありません。

ポリシー ウィンドウのサイズまたはジョブの実行時間

数時間実行されるジョブは、他のアプリケーションで使用できるジョブスロットを保持します。各アプリケーションがジョブを平均 1 分で完了し、5 つのスロットがある場合、1 時間あたり 300 件のジョブを実行できます。各アプリケーションが平均 1 時間かかり、5 つのスロットがある場合、1 時間あたり 5 件のジョブを実行できます。ただし、ポリシーの合計時間枠が 3 時間の場合、このバックアップ プラン ポリシーを使用するアプリケーションの数は、24 時間以内に可能なアプリケーション コピー データ管理の合計に大きな影響を与えます。

たとえば、アプリケーションが 100 個ある場合、最初の例（1 時間あたり 300 件のジョブ）では、アプライアンスは約 20 分ですべてのアプリケーションを完了します。ただし、2 番目の例で 100 個のアプリケーション（1 時間あたり 5 個のジョブ）がある場合、アプライアンスは 1 日あたり 15 個のアプリケーションのみを管理します。これにより、85 件のバックアップ プラン違反が発生します。

ジョブの実行時間は制御できませんが、実行中のアプリケーションのスケジュール設定時間を確認できます。新しいアプリケーションの最初のスナップショット ジョブ中にジョブ時間が長くなることもあります。オンランプ設定を使用すると、取り込みジョブがスロットをロックし、すでに取り込まれたアプリケーションをロックアウトするのを防ぐことができます。

バックアップ/リカバリ アプライアンスがバックアップ プラン違反をモニタリングする方法

各バックアップ/リカバリ アプライアンスは、バックアップ プランの分析を 1 時間ごとに自動的に実行し、スケジュールされたジョブでバックアップ プラン違反が発生したときに特定できるようにします。このバックグラウンド オペレーションは、バックアップ プラン ポリシー期間の終了にできるだけ近づいて、バックアップ プランの違反の可能性をアラートします。

分析中、アプライアンスは過去 1 時間以内に営業時間が終了したすべてのバックアップ プラン ポリシーを確認します。各ポリシーでバックアップ プランの違反がないか確認されます。ポリシー期間の終了から 60 分以内にバックアップ プラン ポリシーでバックアップ プランの違反が発生した場合、それらの違反がイベント データベースにエントリされます。ポリシーにバックアップ プランの違反がない場合、アラートやイベントは生成されません。

バックアップ プランのポリシーの完了期間である 60 分以内にバックアップ プランの違反が発生すると、アラートが開始され、イベント通知が生成されます。バックアップ プラン違反アラートは、システム モニター イベント（モニタリングを参照）またはメール通知イベントの形式で受け取ることができます。各アラートには、特定のアプリケーションで違反している各バックアップ プラン ポリシーに関する詳細情報が含まれます。これには、イベント メッセージ、ポリシー名とタイプ、違反時間とタイプ、ジョブ情報（予想されるジョブ、許容範囲、成功、失敗）などの情報が含まれます。バックアップ プラン違反アラートには、レポート マネージャーのバックアップ プランのコンプライアンス レポートの一部として含まれるバックアップ プラン違反レポートに表示される詳細レベルが含まれます。

プラットフォーム サーバーログ（udppm ログファイル）も作成され、分析の実行日時、分析されたポリシー、分析結果の概要が示されます。

バックアップ プランの分析では、処理中のジョブが原因で生じる可能性のある差異が考慮されます。特定の状況では、ジョブは割り当てられたポリシーの開始時間内に開始されますが、予想よりも長く実行され、指定されたポリシーの時間枠内に完了できない場合があります（ジョブが午後 10 時に開始されて午後 11 時 30 分に終了する場合など）。最初は、ジョブは成功と見なされ、バックアップ プラン違反アラートが発生しません。ただし、ジョブが完了すると、次のバックアップ プラン分析サイクルの一部として再評価され、バックアップ プラン違反としてフラグが立てられることがあります。バックアップ プラン ポリシーの成功または失敗は、ジョブが実際に完了したタイミングによって異なります。

分析中に、バックアップ プラン ポリシーで 1 つ以上のジョブの実行に失敗したことがアプライアンスで判断された場合、バックアップ プラン違反が発生し、生成されたアラートまたはイベントには、失敗したジョブに関する次の追加情報が含まれます。

  • ジョブの推定実行時間
  • ジョブの実行に失敗した理由

また、アプライアンスはタイムラインを調べて、そのジョブタイプに使用可能なスロットがなかったためにジョブが実行されなかったかどうかを判断します。これが理由である場合、アラートまたはイベントにこの情報が含まれます。

アプリケーションにポリシー期間が重複する複数のバックアップ プラン ポリシーがあり、この重複期間中に両方のポリシーでジョブが失敗した場合、アプライアンスは 1 つのアラートのみ生成します。重複するポリシーに対して重複するアラートが開始されることはありません。失敗したジョブのアラートは、アプリケーション、ポリシーの種類、期間別に集計されます。

バックアップ プランの違反をモニタリングする

バックアップ プラン違反は、[モニタリング] タブ、メール通知、または レポート マネージャーを使用してモニタリングおよび表示できます。

モニタリング

バックアップ プランの違反の詳細は、[モニタリング] タブ（[モニタリング] > [イベント]）でイベントとして確認できます。[モニタリング] タブの使用方法については、モニタリングをご覧ください。

レポート マネージャー

バックアップ プラン違反レポートの完全なライブラリは、管理コンソールの レポート マネージャーで利用できます。これらのレポートを使用すると、現在の成功率を確認する方法が簡素化され、同じ名前の複数のアプリケーションを簡単に区別できます。

次のステップ