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

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

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

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

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

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

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

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

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

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

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

データキャプチャ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

その名が示すように、整合性グループは、複数のデータベース間で一貫したポイントインタイムの取得と復元を保証します。バックアップと DR のデータベースとログのキャプチャテクノロジーがバックアッププランポリシーで有効になっている場合、そのグループ内のすべてのデータベースを同じ時点に復元できます。整合性グループ内のすべてのデータベースまたは個々のデータベースのログの復元とロールフォワードは、バックアップと 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 ポリシーテンプレートポリシーによって制御されます。

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

ログを複製する

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

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

ログを OnVault プールに複製することもできます。有効になっている場合（デフォルトではない）、ログは有効な OnVault ポリシーまたはリソースプロファイルの組み合わせで指定された各 OnVault プールに送信されます（OnVault プール（ポリシーで選択された 1 つと、リソースプロファイルで指定された 1 つ）。OnVault プールのログ保持期間は、常にスナップショットプールのログ保持期間と一致します。

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

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

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

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

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

データ、バックアップと DR の機能、リソースにアクセスできるユーザーを制御できます。キャプチャされたデータに機密性の高いマークを付け、バックアップユーザーと DR ユーザーに機密データへのアクセス権を付与できます。

マウント

バックアップと DR のマウント機能を使用すると、データを移動することなくデータにすぐにアクセスできます。キャプチャされたデータベースのコピーは、バックアップと DR のユーザーインターフェースを使用してロールフォワードし、任意のデータベースサーバーにマウントできます。バックアップと 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 内の機密データをマスクできます。

バックアップと 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

本番環境データベースを使用したアプリケーション開発の迅速化を望む企業が増えるにつれ、バックアップと DR は、同じ本番環境データベース環境で動作するレガシーバックアッププロダクトと共存することが求められるケースが増えています。これらのベストプラクティスに従えば、バックアップと DR は、本番環境データベースからデータをキャプチャする他の製品と完全に共存できます。

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

バックアップジョブは I/O 使用率が高くなる場合があります。時間がかかり、バックアップ期間中のデータベースのパフォーマンスに影響する可能性があります。バックアップと DR により、ジョブ中の影響は最小限に抑えられますが、ブロックレベルの増分更新でも I/O を生成する必要があり、少し時間がかかります。

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

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

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

次のステップ

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

Microsoft SQL Server のバックアップと DR に関するその他のドキュメント

このページは、バックアップと DR による Microsoft SQL Server データベース、バイナリ、サポートファイルの保護と復元に固有のシリーズのページの 1 つです。

詳細については、以下をご覧ください。