このページは Cloud Translation API によって翻訳されました。

Microsoft SQL Server のバックアップと DR サービス

SQL Server データをキャプチャする

Backup and DR サービスを使用すると、次のタイプの Microsoft SQL Server アプリケーションをキャプチャできます。

インスタンス
Always On 可用性グループのデータベース
データベースの整合性グループ
個々のデータベース
システムデータベース
ユーザーデータベース
VM 内のデータベース

Backup and DR は、Microsoft SQL Server がプライマリストレージを書き込む場所とは別に Microsoft SQL Server データを移動して管理します。

バックアップ/リカバリアプライアンスは、アプリケーションデータをステージングディスクに保存します。ステージングディスクのスナップショットにより、バックアップ/復元アプライアンスは履歴データを維持できます。

Microsoft SQL Server データのバックアップの準備をする

Microsoft SQL Server データのバックアップの準備は、次の 4 つのステップで構成されます。

Microsoft SQL Server データベースをホストするサーバーを追加します。
VM と Microsoft SQL Server データベースを検出します。
RPO と RTO に従って、Backup and DR のポリシーテンプレートとリソースプロファイルを定義します。

Microsoft SQL Server の完全復元モデルを使用するデータベースは、データベースとそのログの両方をキャプチャできます。したがって、キャプチャされたデータベースは、ログをロールフォワードすることで特定の時点に復元できます。
Backup and DR ポリシーテンプレートとリソースプロファイルを Microsoft SQL Server データベースに割り当てます。

データキャプチャ

データをキャプチャする際は、次の点を考慮してください。

ステージングディスクが自動的に作成され、サーバーにマウントされます。
最初に、ステージングディスクに完全なコピーが作成されます。以降のコピーは、変更されたブロックのみで構成されます。
ステージングディスクがサーバーからマウント解除されます。
ステージングディスクのスナップショットがバックアップ/リカバリアプライアンスで作成されます。

SQL Server データベースのログをキャプチャする

データベースログのキャプチャは、スナップショットポリシーの [詳細と設定] で設定します。これにより、単一のスナップショットポリシーで、Microsoft SQL Server データベースと、Microsoft SQL Server データベースを含む整合性グループのログをキャプチャできます。

データベースログのキャプチャ頻度は、データベースの頻度とは別に定義されます。たとえば、データベースは毎日キャプチャされ、ログは 1 時間ごとにキャプチャされます。

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

ログの保持も、関連するデータベースとは別に定義されます。保持期間を別々に設定することで、データベースのすべてのスナップショットバージョンと OnVault バージョンをカバーするのに十分なログ情報を維持できます。たとえば、データベースのスナップショットデータが 3 日間保持され、OnVault データが 7 日間保持される場合、ログ保持期間を 7 日間に設定できます。この例では、キャプチャされた単一のデータベースイメージを選択し、そのログを期間全体にわたってロールフォワードできます。

データベースログは、バックアップと DR のスナップショットプール内の単一のステージングディスクにステージングされます。スナップショットプールの容量を節約するには、詳細設定を使用して、ログを圧縮するようにデータベースに指示します。

Microsoft SQL Server データベーストランザクションログをリモートバックアップ/復元アプライアンスに複製するように指定できます。リモートサイトのログは、レプリケートされたログの保持範囲内の任意のデータベースイメージに使用できます。

データベースログのステージングディスクのサイズを変更する

データベースのログのバックアップを格納するために必要な物理スペースは、Backup and DR によって自動的に管理されます。これはログステージングディスクと呼ばれ、ソースサーバーによって管理されるストレージとは異なります。Backup and DR は、少なくとも一般的なログサイズとその保持期間を評価し、必要に応じてより大きなディスクを使用します。

データベースのログのストレージ要件をより効率的かつ効果的に管理するために、スナップショットポリシーには次の詳細設定が用意されています。

Log Backup Retention Period: ログの保持は、関連付けられたデータベースとは別に定義されます。保持率を別々に設定することで、データベースのすべてのスナップショットバージョンをカバーするのに十分なログ情報を保持できます。ログの保持期間は必須の設定です。
Log Staging Disk Size Growth: ログが保存されているステージングディスクを自動的に増やす割合を定義します。
推定変更率: 1 日あたりの変更率（パーセント）を定義します。これにより、バックアップ/復元アプライアンスは、ログの保持に必要なステージングディスクのサイズをより正確に計算できます。
Compress Database Log Backup: バックアップ/復元アプライアンスでキャプチャする前に、ログを圧縮するようにソースデータベースに指示します。データベースサーバーは、ログバックアップ中にログ圧縮を実行します（デフォルトは有効）。

SQL Server のデータキャプチャオプション

以降のセクションでは、SQL Server のデータキャプチャオプションについて説明します。

インスタンス、個々のデータベース、データベースのグループをキャプチャする

Backup and DR エージェントは、物理サーバーと仮想サーバー上のインスタンス、ユーザーデータベース、システムデータベース、データベースのグループをキャプチャするために使用されます。

SQL Server インスタンスをキャプチャするときに、インスタンス全体をキャプチャするか、インスタンス内の選択したデータベースをキャプチャするかを選択できます。インスタンス全体を保護すると、データベースがインスタンスに追加されるたびに、次の Backup and DR キャプチャジョブに自動的に含まれます。インスタンス内のデータベースは休止され、単一のバックアッププランでキャプチャされます。

バックアッププランポリシーで Backup and DR データベースとログのキャプチャが有効になっている場合、そのインスタンス内のすべてのデータベースを同じ時点に復元できます。インスタンス内のすべてのデータベースまたは個々のデータベースのログの復元とロールフォワードは、Backup and DR ユーザーインターフェースから 1 回の操作で実行されます。

インスタンスの個々のメンバーには、必要に応じてマウント、クローン、LiveClone、復元オペレーションでアクセスできます。

整合性グループをキャプチャする

整合性グループは、単一のバックアッププランポリシーテンプレートとリソースプロファイルで同時に休止とキャプチャが行われるデータベースのグループです。整合性グループへのメンバーシップは手動で割り当てられ、メンバーが頻繁に変更されないデータベースのグループに適しています。データベースグループの新しいメンバーを自動的に保護するには、SQL Server インスタンスでデータベースを作成して保護します。

整合性グループは、その名のとおり、複数のデータベース間で一貫したポイントインタイムキャプチャと復元を保証します。バックアッププランポリシーで Backup and DR のデータベースとログキャプチャ技術が有効になっている場合、そのグループ内のすべてのデータベースを同じポイントインタイムに復元できます。整合性グループ内のすべてのデータベースまたは個々のデータベースのログの復元とロールフォワードは、Backup and DR ユーザーインターフェースから 1 つのアクションで実行されます。整合性グループのメンバーは同じインスタンスに存在する必要があります。

整合性グループは、次の要素で構成できます。

1 つ以上のシステムデータベース
1 つ以上のユーザーデータベース
システムデータベースとユーザーデータベースを一緒に
0 個以上のファイルシステム（ドライブ文字またはマウントポイント）

整合性グループの個々のメンバーには、マウント、クローン、LiveClone、復元オペレーションでアクセスできます。

クラスタ化されたフェイルオーバーインスタンスのデータベースは、アクティブノードから検出される必要があります。保護されると、GO はクラスタ内のアクティブな SQL ノードに従います。フェイルオーバー状態でも、保護ジョブは引き続き実行されます。キャプチャとアクセスオペレーションを高速化するだけでなく、整合性グループは、データベースを個別に保護するよりもシステムリソース（VDisk）の消費量が少なくなります。

バックアップイメージをサーバーにマウントしてデータベースの整合性チェックを実行することで、データベースバックアップの整合性を定期的に検証できます。ワークフロー機能を使用して、検証プロセスを自動化できます。

VM のデータベースとブートボリュームをキャプチャする

VM でデータベースをキャプチャするときに、VM のブートボリュームもキャプチャできます。VM のブートボリュームがデータベースとともにキャプチャされると、完全に機能するデータベースと VM のイメージが表示されます。その後、イメージを新しい永続的な場所に移行できます。

SQL Server データを複製する

データは、復元、障害復旧、テスト、開発の目的で、2 番目のバックアップ/リカバリアプライアンスまたはクラウドに複製できます。データレプリケーションは、地理的に分散した環境での効率的なデータ管理の妨げとなってきました。バックアップと DR のレプリケーションでは、次の圧縮によってこれらの問題に対処します。

ネットワークの使用量を全体的に削減します。
専用の WAN アクセラレータやオプティマイザーが不要になります。
AES-256 暗号化標準を使用してデータを暗号化します。バックアップ/復元アプライアンス間の認証は、1,024 ビットの証明書を使用して行われます。

レプリケーションは、Backup and DR ポリシーテンプレートのポリシーによって制御されます。

Production to Mirror ポリシーには、データを 2 番目のバックアップ/リカバリアプライアンスに複製するためのオプションがいくつかあります。
Production to OnVault ポリシーは、Backup and DR 独自のエンジンを使用して、データをオブジェクトストレージに転送します。

ログを複製する

ポリシーの [Enable Database Log Backup] が [Enable] に設定されている場合、[Replicate Logs advanced setting allows] を使用すると、Microsoft SQL Server データベーストランザクションログをリモートバックアップ/復元アプライアンスに複製できます。ログ複製ジョブを実行するには、テンプレートに StreamSnap 複製ポリシーと、リモートバックアップ/リカバリアプライアンスを指定するリソースプロファイルが含まれている必要があります。また、データベースの複製が少なくとも 1 回正常に完了している必要があります。レプリケートされたログの保持範囲内のデータベースイメージについては、リモートサイトのログを使用できます。この機能はデフォルトで有効になっています。

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

ログは OnVault プールに複製されることもあります。有効にすると（デフォルトではない）、ログは有効な OnVault ポリシーまたはリソースプロファイル（ポリシーで選択された OnVault プール 1 と、リソースプロファイルで指定された OnVault プール 1）。OnVault プールのログ保持期間は、常にスナップショットプールのログ保持期間と一致します。

SQL Server データにアクセスする

完全復旧モデルを使用する Microsoft SQL Server データベースの場合、Backup and DR は、特定の時点までロールフォワードされたデータベースのコピーを即座に提示できます。ロールフォワードオペレーションは管理コンソールで指定します。

基本復元モデルを使用する Microsoft SQL Server データベースの場合、Backup and DR は、保持期間が経過していないデータベースのバックアップを即座に提示できます。

使用する Microsoft SQL Server リカバリモデルに関係なく、iSCSI インターフェースを使用して Microsoft SQL Server データにアクセスできます。VMware（GCVE）を使用している場合、ESXi ホストに提示された NFS データストアを使用してデータにアクセスすることもできます。

ロールベースのアクセス制御

データ、Backup and DR の機能、リソースにアクセスできるユーザーを制御できます。キャプチャされたデータは機密情報としてマークできます。また、Backup and DR ユーザーに機密データへのアクセス権限を付与できます。

マウント

バックアップと DR のマウント機能を使用すると、データを移動せずにデータにすぐにアクセスできます。キャプチャされたデータベースのコピーは、Backup and DR ユーザーインターフェースを使用してロールフォワードし、任意のデータベースサーバーにマウントできます。Backup and DR には、Microsoft SQL Server データベースをマウントする方法が 2 つあります。

仮想アプリケーションのマウントは、キャプチャした Microsoft SQL Server データを Microsoft SQL Server データベースとしてターゲットサーバーに提示し、利用可能にします。これにより、非本番環境で使用する本番環境データベースのコピーを作成して管理できます。仮想アプリケーションマウントはバックアップ/リカバリアプライアンスから作成され、データベース、サーバー、ストレージの管理者による手動の介入は必要ありません。仮想アプリケーションマウントは、データベースレポート、分析、完全性テスト、テストと開発に使用できます。仮想データベースの詳細については、SQL Server データベースを新しい仮想データベースとしてマウントすると SQL Always On 可用性グループにデータベースをマウントするをご覧ください。
標準マウント（直接マウントとも呼ばれます）では、キャプチャした Microsoft SQL Server データをデータベースではなくファイルシステムとしてターゲットサーバーに提供します。これは、データベースが破損または消失した場合や、データベースサーバーが置き換えられる場合に便利です。このような場合、復元オペレーションを使用してデータベースを復元することはできません。代わりに、イメージをマウントし、マウントされたイメージからデータベースサーバーの元の場所にデータベースファイルをコピーできます。直接マウントについては、キャプチャした Microsoft SQL データをマウントするをご覧ください。

LiveClone

LiveClone は、ユーザーに提供する前に更新してマスクできる Microsoft SQL Server データの独立したコピーです。これにより、開発チームとテストチームは、データを手動で管理したり、本番環境に干渉したりすることなく、最新のデータセットで作業できます。

クローンズ

クローン機能は、本番環境データのコピーをソースとは異なる場所に移動します。クローンオペレーションの完了に必要な時間は、関連するデータの量によって異なります。クローンについては、SQL Server データベースのクローンを作成するをご覧ください。

復元

復元では、本番環境データが指定された時点に戻ります。復元オペレーションでは、実際にデータが移動します。復元オペレーションは通常、大規模なデータ破損の後に実行されます。復元オペレーションの完了に必要な時間は、関連するデータの量によって異なります。

データベースを復元してログを適用するには、復元されたデータベースが復元モードになっている必要があります。データベースを復元モードで復元し、ログを特定の時点までロールフォワードできます。Restore with no Recovery を指定せずにデータベースを復元すると、ログが適用されずにデータベースが復元され、オンラインになります。復元については、SQL Server データベースを復元するをご覧ください。ダウンタイムをほぼゼロにして復元するには、まず SQL データをマウントして移行するで説明されているようにデータをマウントします。

SQL Server データへのアクセスを自動化するワークフロー

ワークフローは、キャプチャされた Microsoft SQL Server データへのアクセスを自動化します。ワークフローではデータを直接マウントまたは LiveClone として提示できます。

直接マウント（標準またはアプリケーション対応）は、提示前にマスクする必要がない Microsoft SQL Server データに適しています。マウントされたデータのコピーを手動で更新することも、スケジュールに基づいて自動的に更新することもできます。直接マウントを使用すると、キャプチャされた Microsoft SQL Server データにすぐにアクセスできます。データを実際に移動する必要はありません。
LiveClone は、手動で更新することもスケジュールに基づいて更新することもできる、本番環境の Microsoft SQL Server データのコピーです。ユーザーに提供する前に、LiveClone でセンシティブデータをマスクできます。

Backup and DR の Microsoft SQL Server データの自動キャプチャとアクセス制御をワークフローとそのオプションのデータマスキング機能と組み合わせることで、セルフプロビジョニング環境を作成できます。ユーザーは独自の環境をほぼ瞬時にプロビジョニングできます。

たとえば、バックアップと DR 管理者は、指定したスケジュールに従って Microsoft SQL Server データをキャプチャするバックアップテンプレートポリシーを作成できます。管理者は、キャプチャされた本番環境の Microsoft SQL Server データをセンシティブとしてマークして、適切なアクセス権を持つユーザーのみがアクセスできるようにします。

アクセス権を定義してデータをキャプチャしたら、次のような処理を行うワークフローを作成できます。

キャプチャされた Microsoft SQL Server データを LiveClone または直接マウントとして提供します。
LiveClone またはマウント可能な Microsoft SQL Server データを更新する（スケジュールに基づいて更新することも、オンデマンドで更新することもできます）
必要に応じて、更新された LiveClone の Microsoft SQL Server データに自動的にスクリプトを適用するこれは、機密性の高い Microsoft SQL Server データをマスクする場合に便利です。

ワークフローが完了すると、適切なアクセス権を持つユーザーが、LiveClone またはマウント可能な Microsoft SQL Server データを使用して各自の環境をプロビジョニングできるようになります。

既存のバックアッププロダクトと連携するバックアップと DR

本番環境データベースを使用してアプリケーション開発を加速しようとする企業が増えるにつれて、Backup and DR は、同じ本番環境データベース環境で動作する従来のバックアッププロダクトと共存する必要があることが多くなっています。これらのベストプラクティスに従うことで、Backup and DR は本番環境データベースからデータをキャプチャする他のプロダクトと完全に共存できます。

Backup and DR には独自の変更ブロックトラッキング方法があるため、SQL やその他のバックアップ取得方法を使用するバックアップソリューションは、スケジュールされた Backup and DR データキャプチャジョブの影響を受けません。

バックアップジョブは I/O を大量に消費する可能性があります。バックアップウィンドウ中にデータベースのパフォーマンスに影響する可能性があります。Backup and DR はジョブ中の影響を最小限に抑えますが、ブロックレベルの増分永久更新でも I/O を生成し、少し時間がかかります。

要件	以前のバックアップソフトウェアとバックアップと DR が、時間が重なる形でジョブを実行するようにスケジュールされていないこと。
ベストプラクティス	以前のバックアップソフトウェアが終了する時刻に開始するように、バックアップと DR のデータベースジョブをスケジュールします。以前のバックアップソフトウェアが、バックアップと DR のジョブが通常完了する直後に実行されるようにスケジュールしないでください。
理由	従来のバックアップジョブと Backup and DR ジョブが同時に実行されると、データベースサーバーのパフォーマンスに重大な影響が生じ、不安定になったり、停止したりする可能性があります。

データベースログは、データベース内の個々のトランザクションをキャプチャするために使用され、ポイントインタイムリカバリを可能にします。ほとんどのアジリティユースケースは、本番環境からデータベーススナップショットを定期的に取得することを中心に展開されます。一般的な頻度は、ユースケースに応じて、毎日、毎週、または 2 週間に 1 回です。そのため、アプリケーションデベロッパーが非本番環境インスタンスをソース（本番環境）の特定の時点に配置する必要は通常ありません。これにより、通常は Backup and DR のアジリティソリューションの一部としてログをキャプチャして管理する必要がなくなります。

要件	ログを管理（キャプチャまたは切り捨て（パージ））できるシステムは 1 つだけです。以前のバックアップソフトウェアまたはバックアップと DR のいずれかです。
ベストプラクティス	すべてのログ管理を以前のバックアップソフトウェアで実行し続け、この環境のログを保護するために Backup and DR を使用しないでください。
理由	ログを管理（キャプチャまたは切り捨て（パージ））するようにシステムが構成されていて、以前のバックアップソフトウェアもログをキャプチャまたは切り捨て / パージしている場合、一方または両方のシステムでログチェーンが不完全になる可能性があり、データベースを特定の時点に復元することが困難または不可能になる可能性があります。

Backup and DR for Microsoft SQL Server のその他のドキュメント

このページは、Backup and DR を使用して Microsoft SQL Server データベースを保護および復元する方法に固有の一連のページの一つです。詳細については、以下をご覧ください。

次のステップ

Backup and DR サービス用に SQL Server データベースを準備する。