Exchange Serverリソースのバックアップ戦略の定義
変更を提案
PDF
バックアップ ジョブを作成する前にバックアップ戦略を定義しておくと、データベースの正常なリストアに必要なバックアップを確実に作成できます。バックアップ戦略の大部分は、サービス レベル アグリーメント（SLA）、目標復旧時間（RTO）、および目標復旧時点（RPO）によって決まります。
SLAは、求められるサービス レベル、およびサービスに関連する多くの問題（サービスの可用性やパフォーマンスなど）への対応を定義したものです。RTOは、サービスの停止からビジネス プロセスの復旧までに必要となる時間です。RPOは、障害発生後に通常処理を再開するためにバックアップ ストレージからリカバリする必要があるファイルの経過時間に関する戦略を定義したものです。SLA、RTO、およびRPOは、バックアップ戦略に関与します。
Exchangeデータベースでサポートされるバックアップ タイプ
SnapCenterを使用してExchangeメールボックスをバックアップするには、データベースやデータベース可用性グループ（DAG）などのリソース タイプを選択する必要があります。Snapshotテクノロジを通じて、リソースが配置されているボリュームのオンラインの読み取り専用コピーが作成されます。
| バックアップ タイプ | 説明 |
|---|---|
フル / ログ バックアップ |
データベースと、切り捨てられたログを含むすべてのトランザクション ログがバックアップされます。 フル バックアップが完了すると、Exchange Serverにより、データベースにコミット済みのトランザクション ログが切り捨てられます。 通常はこのオプションを選択します。ただし、バックアップ時間が短い場合は、フル バックアップでトランザクション ログ バックアップを実行しないように選択することもできます。 |
フル バックアップ |
データベースとトランザクション ログがバックアップされます。 切り捨てられたトランザクション ログはバックアップされません。 |
ログ バックアップ |
すべてのトランザクション ログがバックアップされます。 データベースにコミット済みの切り捨てられたログはバックアップされません。フル データベース バックアップの合間にトランザクション ログを頻繁にバックアップするスケジュールを設定すると、リカバリ ポイントをより細かく選択できます。 |
データベース プラグインのバックアップ スケジュール
バックアップ頻度（スケジュール タイプ）はポリシーで指定され、バックアップ スケジュールはリソース グループの設定で指定されます。バックアップの頻度またはスケジュールを決定する場合に最も重要な要因となるのは、リソースの変更率とデータの重要性です。使用頻度の高いリソースは1時間ごとにバックアップする必要がありますが、ほとんど使用されないリソースは1日に1回バックアップすれば十分です。その他の要因としては、組織におけるリソースの重要性、サービス レベル アグリーメント（SLA）、目標復旧時点（RPO）などがあります。
SLAは、求められるサービス レベル、およびサービスに関連する多くの問題（サービスの可用性やパフォーマンスなど）への対応を定義したものです。RPOは、障害発生後に通常処理を再開するためにバックアップ ストレージからリカバリする必要があるファイルの経過時間に関する戦略を定義したものです。SLAとRPOはデータ保護戦略に関わる要件です。
使用頻度の高いリソースであっても、フル バックアップは1日に1～2回で十分です。たとえば、定期的なトランザクション ログ バックアップを実行すれば、必要なバックアップが作成されます。データベースを頻繁にバックアップするほど、 SnapCenterが復元時に使用するトランザクション ログが少なくなり、復元操作が高速化されます。
バックアップ スケジュールには、次の2つの要素があります。
-
バックアップ頻度
バックアップ頻度 (バックアップを実行する頻度) は、一部のプラグインでは スケジュール タイプ と呼ばれ、ポリシー構成の一部です。ポリシーでは、バックアップ頻度として、毎時、毎日、毎週、または毎月を選択できます。頻度を選択しなかった場合は、オンデマンドのみのポリシーが作成されます。 設定 > ポリシー をクリックすると、ポリシーにアクセスできます。
-
バックアップ スケジュール
バックアップ スケジュール（バックアップが実行される日時）は、リソース グループ設定の一部です。たとえば、週次バックアップのポリシーが構成されたリソース グループがある場合は、毎週木曜日の午後 10 時にバックアップするようにスケジュールを構成できます。 リソース > リソース グループ をクリックすると、リソース グループのスケジュールにアクセスできます。
データベースに必要なバックアップ ジョブの数
必要なバックアップ ジョブの数を左右する要因としては、リソースのサイズ、使用中のボリュームの数、リソースの変更率、サービス レベル アグリーメント（SLA）などがあります。
バックアップの命名規則
Snapshotのデフォルトの命名規則を使用するか、カスタマイズした命名規則を使用できます。デフォルトのバックアップ命名規則ではSnapshot名にタイムスタンプが追加されるので、コピーが作成されたタイミングを特定できます。
Snapshotでは、次のデフォルトの命名規則が使用されます。
resourcegroupname_hostname_timestamp
バックアップ リソース グループには、次の例のように論理的な名前を付ける必要があります。
dts1_mach1x88_03-12-2015_23.17.26
この例では、各構文要素に次の意味があります。
-
dts1 はリソース グループ名です。
-
mach1x88 はホスト名です。
-
03-12-2015_23.17.26 は日付とタイムスタンプです。
または、[スナップショット コピーにカスタム名形式を使用する] を選択して、リソースまたはリソース グループを保護しながらスナップショット名の形式を指定することもできます。たとえば、customtext_resourcegroup_policy_hostnameやresourcegroup_hostnameなどの形式です。デフォルトでは、Snapshot名にタイムスタンプのサフィックスが追加されます。
バックアップ保持オプション
バックアップ コピーを保持する日数を選択するか、または保持するバックアップ コピーの数（ONTAPでは最大255個のコピー）を指定することができます。たとえば、組織の必要に応じて、10日分のバックアップ コピーや130個のバックアップ コピーを保持できます。
ポリシーを作成する際に、バックアップ タイプおよびスケジュール タイプの保持オプションを指定できます。
SnapMirrorレプリケーションを設定すると、デスティネーション ボリュームに保持ポリシーがミラーリングされます。
SnapCenter は、スケジュール タイプに一致する保持ラベルを持つ保持されたバックアップを削除します。リソースまたはリソース グループに対してスケジュール タイプが変更されると、古いスケジュール タイプ ラベルのバックアップがシステムに残ることがあります。
|
バックアップ コピーを長期にわたって保持する場合は、SnapVaultバックアップを使用する必要があります。 |
Exchange Serverのソース ストレージ ボリュームにトランザクション ログ バックアップを保持する期間
SnapCenter Plug-in for Microsoft Exchange Serverでは、最新の状態へのリストア処理を実行するために、トランザクション ログ バックアップが必要です。この場合、2つのフル バックアップの間の任意の時点の状態にデータベースがリストアされます。
たとえば、Plug-in for Exchange が午前 8 時に完全バックアップとトランザクション ログ バックアップを実行し、午後 5 時にもう一度完全バックアップとトランザクション ログ バックアップを実行した場合、最新のトランザクション ログ バックアップを使用して、午前 8 時から午後 5 時までの任意の時点にデータベースを復元できます。トランザクション ログが使用できない場合、Plug-in for Exchange は、Plug-in for Exchange が完全バックアップを完了した時点にデータベースを復元するポイントインタイム リストア操作のみを実行できます。
通常、最新の状態へのリストア処理に必要なのは1～2日分のみです。デフォルトでは、SnapCenterの保持期間は最短の2日間です。