アプライアンス管理コンソールでバックアップ プランの違反を特定する

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

このセクションでは、バックアップ プラン違反の潜在的な原因、アプライアンス管理コンソールがバックアップ プラン違反の発生を特定する方法、バックアップ プラン違反の発生をモニタリングする方法について説明します。以下が含まれています。

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

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

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

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

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

失敗したジョブ

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

ホストごとに複数のアプリケーション

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

VM が VM として管理され、Backup and 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 番目の例（1 時間あたり 5 ジョブ）で 100 個のアプリケーションがある場合、アプライアンスは 1 日あたり 15 個のアプリケーションしか管理しません。これにより、85 件のバックアップ プラン違反が発生します。

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

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

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

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

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

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

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

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

  • 予想されるジョブの実行時間
  • ジョブの実行が失敗した理由

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

アプリケーションに、ポリシー ウィンドウが重複する複数のバックアップ プラン ポリシーがあり、この重複する時間中に両方のポリシーでジョブが失敗した場合、アプライアンスは 1 つのアラートのみを生成します。重複するポリシーに対して重複するアラートは開始されず、重複が排除されます。ジョブ未実行アラートは、アプリケーション、ポリシータイプ、期間ごとに集計されます。

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

バックアップ プランの違反をモニタリングして表示するには、[モニタリング] タブ、メール通知、または Report Manager を使用して、マネージド アプライアンスから行います。

モニタリング

バックアップ プラン違反の詳細は、[Monitor] タブ（[Monitor] > [Events]）からイベントとして表示できます。[Monitor] タブの使用方法については、Monitor をご覧ください。

レポート マネージャー

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

次のステップ