バックアップ プラン ポリシーのベスト プラクティス

これらのベスト プラクティスに従うことで、ポリシー テンプレートの作成と変更時にユーザーが犯す一般的なミスを回避できます。

ポリシー テンプレートは、目標復旧時点（RPO）と目標復旧時間（RTO）に応じて構成する必要があります。時間の経過とともに、これらのテンプレートに変更を加える必要が生じる場合があります。

初期データのバックアップの取得

ポリシー テンプレートのポリシーがアプリケーションのデータのバックアップを初めて作成する場合、データ全体がバックアップされます。後続のバックアップは増分バックアップになります。

1 つのポリシー テンプレートで複数のアプリケーションを保護するには、ポリシー テンプレートを少数のアプリケーションに適用します。最初の完全なデータの取得が完了したら、ポリシー テンプレートを他のアプリケーションに適用します。ポリシー テンプレートがすべてのアプリケーションに適用されるまで、このプロセスを繰り返します。

ボリュームのサイズ変更

保護されたデータを含むボリュームのサイズを変更すると、一部のアプリケーション タイプでは、そのボリュームのスナップショット ポリシーが次回実行されたときに、そのボリュームのデータが過去に何回バックアップされたかに関係なく、完全バックアップ オペレーションが実行されることがあります。これには、サイズ変更された VMWare VMDK、および LVM にない Microsoft Windows アプリケーションと Linux アプリケーションのエージェント ベースのバックアップが含まれます。

影響を受けるアプリケーション タイプのボリュームのサイズを変更する必要がある場合は、すべてのデータをキャプチャすることがアプリケーション サーバー、ネットワーク、バックアップ/リカバリ アプライアンスに与える影響を検討してください。

ジョブの同時実行

バックアップ/リカバリ アプライアンスは、デフォルトで 6 つのスナップショット ジョブを同時に実行できます。同じ期間にスケジュールされるジョブ数が許可されている数を超える場合、ポリシー スケジューラは許可されている数のジョブを起動し、他のジョブをキューに追加します。

各ユーザーのネットワーク設計、データ レイアウト、ストレージ クラスは異なるため、最適な同時実行ジョブ数に達するまで同時実行をテストします。

ポリシーのスケジュール

管理コンソールでは、ポリシーの構成時にポリシー スケジュールを指定する 2 つの方法がサポートされています。

  • ウィンドウあり。特定の頻度と時間枠に従って個別のスナップショット バックアップ スケジュールを定義します（たとえば、毎日 30 分ごとに UTC の 09:00 ～ 17:00 にバックアップを実行します）。バックアップ/リカバリ アプライアンスに、指定した頻度で複数のバックアップ ジョブを実行するか、指定した時間枠で 1 回実行するように指示できます。
  • 継続的。連続スナップショット バックアップ スケジュールを定義します（たとえば、最初のジョブを UTC 01:00 に開始し、8 時間ごとにバックアップ ジョブを実行します）。このポリシー スケジュールでは、ジョブは指定された時間間隔で継続的に（24 時間 365 日）実行されます。

頻度の計算

期間はスケジュールされた実行間の時間で、頻度は単位時間あたりの実行ジョブ数です。たとえば、スケジュールでジョブを 4 時間ごとに実行するように指定した場合、期間は 4 時間で、想定される頻度は 1 日 6 回です。ジョブの完了に 1 時間かかり、ポリシーの頻度が 12 時間の場合、ポリシーのジョブは前のジョブの完了から 11 時間後に再び実行されます。

必要な目標復旧時点（RPO）を達成し、ジョブが完了するのに十分な時間を確保できる頻度を選択してください。

  • スナップショット ポリシーの最小推奨頻度は 1 時間（ローカル RPO）です。
  • StreamSnap ポリシーは、頻度が 1 時間以上のスナップショット ポリシー（リモート RPO）を参照できます。

バックアップ プラン ポリシーでのデータベース ログの保護

データベースのスナップショット ポリシーを作成するときに、指定した頻度でログファイルをキャプチャすることもできます。データベース ログをキャプチャする頻度は、データベースの頻度とは別に定義されます。たとえば、データベースは毎日キャプチャされ、そのログは 1 時間ごとにキャプチャされます。

データベース ログ バックアップの頻度は分単位で設定します。ログがキャプチャされる頻度は、関連するデータベースがキャプチャされる頻度を超えてはなりません。たとえば、データベースの回収頻度が 24 時間ごとの場合、ログファイルの回収頻度は 24 時間未満にする必要があります。

頻度と保持は、データベースのスナップショット ポリシーの詳細設定で定義されます。ログの取得は、関連するデータベースがキャプチャされる日付の境界、期間、頻度に関係なく行われます。

ログ保護機能は、バックアップ プランのスナップショット ポリシーの [Enable Database Log Backup] 詳細設定で有効にします。頻度と保持は、バックアップ プラン ポリシーの詳細設定でも定義されます。

データベースのログを格納するために必要な物理的なスペースは、管理コンソールによって自動的に管理されます。少なくとも、管理コンソールでは一般的なログサイズとその保持期間が評価され、必要に応じて容量が追加されます。

ログバックアップを有効にして、データベース ログのストレージ要件をより効率的に管理するには、次の表を参照してください。

設定 入力
バックアップ後にログを切り捨てまたはパージする 本番環境ログをパージするには、[はい] に設定する必要があります。ログのパージを管理するには、このオプションを選択します。これにより、各ログ バックアップの終了時にログのパージが実行されます。デフォルトは [Do Not Truncate] です。

[Enable database log backup] が [No] に設定され、[Truncate or purge log after backup] が [Yes] に設定されているポリシーでは、各データベース バックアップの終了時にログのパージが実行され、すべてのログがパージされます。
ログ バックアップの保持期間 Backup and DR ステージング ディスク内のログ バックアップは、ここで設定された値まで保持されます。バックアップ ログの保持期間は、スナップショットの保持期間とは異なる場合があります。
ログ ステージング ディスクの増加サイズ 必要に応じてログ バックアップ ステージング ディスクを拡張する割合を設定します。
推定変化率 データベース データが 1 日あたりどの程度変化するかを推定します。
データベース ログ バックアップを圧縮する これを使用すると、アプリレベルのデータベース API を使用して、データベース ログのバックアップを圧縮モードで実行できます。
データベース ログのバックアップを有効にする [データベース ログのバックアップを有効にする] オプションを使用すると、バックアップ プラン ポリシーでデータベースと関連するすべてのログファイルをバックアップできます。ログは、ログバックアップ ジョブの実行時にバックアップされます。オプションは [Yes] または [No] です。[Yes] に設定すると、関連するオプションが有効になります。
RPO Enable Database Log Backup が [Yes] に設定されている場合、RPO によってデータベース ログのバックアップ頻度が定義されます。頻度は分単位で設定します。データベースのバックアップ間隔を超えないようにしてください。
ログを複製する （StreamSnap テクノロジーを使用）[Enable Database Log Backup] が [有効] に設定されている場合、[Replicate Logs] の詳細設定で、データベース ログのバックアップをリモート バックアップ/リカバリ アプライアンスに複製できます。ログバックアップ レプリケーション ジョブを実行するには、テンプレートに StreamSnap レプリケーション ポリシーと、リモート バックアップ/リカバリ アプライアンスを指定するリソース プロファイルが含まれている必要があります。また、データベースのレプリケーションが少なくとも 1 回正常に完了している必要があります。レプリケートされたログバックアップの保持期間内の任意のデータベース イメージに、リモート サイトでログバックアップを使用できます。この機能はデフォルトで有効になっています。

ログ レプリケーションは、StreamSnap テクノロジーを使用して、ローカル バックアップ / リカバリ アプライアンスとリモート バックアップ / リカバリ アプライアンス間のレプリケーションを実行します。ログ レプリケーションは、ローカル スナップショット プールからリモート アプライアンスのスナップショット プールに直接行われます。

注: データベースが保護され、データベース バックアップ イメージがリモート バックアップ/リカバリ アプライアンスに複製されるまで、ログ レプリケーションは行われません。
Send Logs to OnVault Pool [Yes] に設定すると、ログが 1 つ以上の OnVault ストレージ プールに複製され、別のサイトの OnVault プールからポイントインタイム復元が可能になります。

ジョブの優先度とスケジューリング

すべてのアクティビティはジョブとして実行されます。ジョブは、ポリシーの作成時に構成されたスケジュールに従って実行されます。

ジョブによっては、他のジョブよりもはるかに時間がかかる場合があります。期限切れジョブは高速です。スナップショット ジョブは、アプリケーションまたは VM のサイズや、前回のスナップショット以降に変更されたデータの量などの変数によって異なります。アプリケーションまたは VM の最初のスナップショットはすべて新しいデータであるため、時間がかかることがあります。

ポリシー スケジューラは、アプリケーションに適用された 1 つ以上のポリシーが実行されるタイミングを特定し、スケジュールされた開始時間になるとポリシーをキューに入れるジョブを開始します。ポリシータイプごとに、実行中のジョブによってシステムが圧倒されないようにするペーシング メカニズムがあります。このペーシング メカニズムは、ジョブスロットを使用してこの安定状態を実現します。つまり、ジョブが特定の時間に開始されるように設定されている場合でも、ジョブスロットが使用可能になった場合にのみ実行されます。

複数のアプリケーションが同じジョブ優先度で同時に実行されるようにスケジュールされている場合、実行するアプリケーションの選択はランダムに行われ、同じ優先度のすべてのアプリケーションで公平性が確保されます。

ジョブの再試行

ジョブが失敗すると、スケジューラはジョブの実行を自動的に再試行します。ジョブが初めて失敗すると、スケジューラは 4 分間待機してから再試行可能にします。ジョブの試行が 3 回失敗すると、ジョブは失敗としてマークされ、再試行されなくなります。次のジョブは、ポリシーのスケジュールに従って試行されます。

スケジューラは、ジョブの再試行を他の利用可能なジョブと同様に扱います。ジョブの数よりも対応できるスロット数が多い場合は、ジョブがキューに追加されます。これにより、再試行がウィンドウ内に開始されず、ジョブが失敗としてマークされる可能性があります。

ジョブの再試行は [モニタ] に報告されます。ジョブの再試行を識別するために、Monitor は、各再試行ジョブの名前に最初に a、次に b、最後に c を追加します。

次のステップ