Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

バックアップ/リカバリアプライアンス上の 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 日間に定義できます。この例では、キャプチャされた単一のデータベースを選択し、そのログを期間全体にわたってロールフォワードできます。

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

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

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

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

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

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

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

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

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

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

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

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

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

キャプチャ整合性グループ

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

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

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

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

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

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

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

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

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

SQL Server データをレプリケートする

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

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

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

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

ログを複製する

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

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

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

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

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

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

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

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

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

マウント

Backup and 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 として提示できます。

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

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

たとえば、Backup and 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 データを使用して各自の環境をプロビジョニングできるようになります。

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

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

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

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

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

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

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

Microsoft SQL Server の Backup and DR に関するその他のドキュメント

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

次のステップ

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