SQL Server Always On 可用性グループをバックアップする

  • [アーティクル]

Azure Backup では、すべてのノードが Recovery Services コンテナーと同じリージョンおよびサブスクリプション内にある場合に、SQL Server Always On 可用性グループ (AG) のバックアップをエンド ツー エンドでサポートします。 ただし、AG ノードが複数のリージョン、サブスクリプション、またはオンプレミスや、Azure 全体に分散している場合は、注意すべき考慮事項がいくつかあります。

Note

  • Azure Backup では、基本的な可用性グループ データベースのバックアップはサポートされていません。
  • サポートされている構成とシナリオの詳細については、SQL バックアップのサポート マトリックスに関する記事を参照してください。

Azure Backup の SQL AG で使用されるバックアップ設定では、プライマリ レプリカからの完全および差分バックアップのみがサポートされています。 そのため、これらのバックアップ ジョブは、バックアップの設定に関係なく、常にプライマリ ノードで実行されます。 コピーのみの完全およびトランザクション ログ バックアップの場合は、バックアップが実行されるノードを決定する際に AG のバックアップ設定が考慮されます。

AG のバックアップの設定 完全および差分バックアップの実行場所 コピーのみおよびログ バックアップの取得元
プライマリ プライマリ レプリカ プライマリ レプリカ
[セカンダリのみ] プライマリ レプリカ セカンダリ レプリカのいずれか 1 つ
[セカンダリを優先] プライマリ レプリカ セカンダリ レプリカが推奨されますが、プライマリ レプリカでもバックアップを実行できます。
なし/任意 プライマリ レプリカ 任意のレプリカ

ワークロード バックアップ拡張機能は、ノードが Azure Backup サービスに登録されたときにインストールされます。 AG データベースがバックアップ用に構成されている場合は、バックアップ スケジュールが AG のすべての登録済みノードにプッシュされます。 それらのスケジュールがすべての AG ノードで起動すると、それらのノード上のワークロード バックアップ拡張機能によりノード間の同期がとられて、バックアップを実行するノードが決定します。 ノードの選択は、セクション 1 で説明するように、バックアップの種類とバックアップ設定によって異なります。

選択したノードではバックアップ ジョブが続行されますが、他のノードでトリガーされたジョブはスキップされます。

Note

Azure Backup では、セカンダリ レプリカの中から選ぶ際に、バックアップの優先順位やレプリカは考慮しません。

Recovery Services コンテナーへの AG ノードの登録

Recovery Services コンテナーでは、コンテナーと同じリージョンおよびサブスクリプション内の VM からのデータベースのバックアップのみをサポートしています。

  • プライマリ ノードをコンテナーに登録する必要があります (そうしないと、完全バックアップを実行できません)。
  • バックアップ設定が "セカンダリのみ" である場合は、少なくとも 1 つのセカンダリ ノードをコンテナーに登録する必要があります (そうしないと、ログまたはコピーのみの完全バックアップを実行できません)。

上記の条件が満たされていない場合は、エラー コード FabricSvcBackupPreferenceCheckFailedUserError で AG データベースのバックアップの構成に失敗します。

参考として次の AG デプロイについて考えてみましょう。

Diagram for AG deployment as reference.

上記の AG デプロイのサンプルに基づいて、さまざまな考慮事項を次に示します。

  • リージョン 1 およびサブスクリプション 1 内にプライマリ ノードがあるので、この AG を保護するには Recovery Services コンテナー (コンテナー 1) がリージョン 1 およびサブスクリプション 1 内にある必要があります。
  • VM3 は別のサブスクリプション内にあるので、コンテナー 1 に登録することはできません。
  • VM4 は別のリージョン内にあるので、コンテナー 1 に登録することはできません。
  • バックアップ設定が "セカンダリのみ" である場合は、VM1 (プライマリ) と VM2 (セカンダリ) をコンテナー 1 に登録する必要があります (完全バックアップにはプライマリ ノードが必要で、ログにはセカンダリ ノードが必要なため)。 その他のバックアップ設定では、VM1 (プライマリ) をコンテナー 1 に登録する必要があり、VM2 は省略可能です (すべてのバックアップをプライマリ ノードで実行できるため)。
  • VM3 はサブスクリプション 2 内のコンテナー 2 に登録でき、AG データベースはコンテナー 2 での保護の対象となりますが、コンテナー 2 にプライマリ ノードが存在しないため、バックアップの構成に失敗します。
  • 同様に、VM4 はリージョン 2 内のコンテナー 4 に登録できますが、プライマリ ノードがコンテナー 4 に登録されていないので、バックアップの構成に失敗します。

フェールオーバーの処理

AG がセカンダリ ノードの 1 つにフェールオーバーされた後は、次のようになります。

  • 完全および差分バックアップが新しいプライマリ ノードから続行されます (それがコンテナーに登録されている場合)。
  • バックアップ設定に基づいて、ログおよびコピーのみの完全バックアップがプライマリまたはセカンダリ ノードから続行されます。

Note

フェールオーバーがバックアップと重ならなければ、フェールオーバー時にログ チェーンは切断されません。

上記の AG デプロイのサンプルに基づいて、考えられるさまざまなフェールオーバーを次に示します。

  • VM2 へのフェールオーバー
    • 完全および差分バックアップが VM2 から行われます。
    • バックアップ設定に基づいて、ログおよびコピーのみの完全バックアップが VM1 または VM2 から行われます。
  • VM3 (別のサブスクリプション) へのフェールオーバー
    • コンテナー 2 ではバックアップが構成されていないので、バックアップは行われません。
    • バックアップ設定が "セカンダリのみ" ではない場合は、プライマリ ノードがコンテナー 2 に登録されているので、コンテナー 2 でバックアップを構成できます。 ただし、これにより競合またはバックアップ エラーが発生する可能性があります。 これについて詳しくは、「マルチリージョン AG のバックアップの構成」を参照してください。
  • VM4 (別のリージョン) へのフェールオーバー
    • コンテナー 4 ではバックアップが構成されていないので、バックアップは行われません。
    • バックアップ構成が "セカンダリのみ" ではない場合は、プライマリ ノードがコンテナー 4 に登録されているため、バックアップをこのコンテナーで構成できるようになります。 ただし、これにより競合またはバックアップ エラーが発生する可能性があります。 これについて詳しくは、「マルチリージョン AG のバックアップの構成」を参照してください。

マルチリージョン AG のバックアップの構成

Recovery Services コンテナーでは、異なるサブスクリプション間または異なるリージョン間のバックアップをサポートしていません。 ここでは、複数のサブスクリプションまたは Azure リージョンにまたがる AG のバックアップを有効にする方法と、関連する考慮事項について説明します。

  • すべてのノードからのバックアップを本当に有効にする必要があるかどうかを評価します。 1 つのリージョンまたはサブスクリプションにほとんどの AG ノードが含まれており、他のノードへのフェールオーバーがめったに発生しない場合は、その最初のリージョンでバックアップを設定するだけで十分です。 他のリージョンやサブスクリプションへのフェールオーバーが頻繁に発生し、長期間にわたる場合は、他のリージョンでもバックアップを事前に設定することが必要になる場合があります。

  • バックアップが有効になっている各コンテナーには、独自の復旧ポイント チェーンのセットがあります。 これらの復旧ポイントからの復元は、そのコンテナーに登録されている VM に対してのみ実行できます。

  • 完全および差分バックアップは、プライマリ ノードを含むコンテナーでのみ正常に実行されます。 他のコンテナーでは、これらのバックアップは失敗し続けます。

  • ログ バックアップは、新しいコンテナー (つまり、新しいプライマリ ノードが存在するコンテナー) でログ バックアップが実行され、古いコンテナーのログ チェーンが "中断" されるまで、以前のコンテナーで機能し続けます。

    Note

    15 日間というハード制限があり、それを超えると、ログ バックアップは失敗し始めます。

  • コピーのみの完全バックアップは、すべてのコンテナーで機能します。

  • 各コンテナーでの保護は個別のデータ ソースとして扱われ、別途請求されます。

2 つのコンテナー間のログ バックアップの競合を回避するために、バックアップ設定を [プライマリ] に設定することをお勧めします。 これにより、プライマリ ノードを含むどのコンテナーでもログ バックアップが作成されるようになります。

上記の AG デプロイのサンプルに基づいて、すべてのノードからのバックアップを有効にする手順を次に示します。 すべての手順でバックアップ設定が満たされていることを前提としています。

手順 1: リージョン 1、サブスクリプション 1 (コンテナー 1) でバックアップを有効にする

プライマリ ノードがリージョンおよびサブスクリプション内にあるので、バックアップを有効にする通常の手順が機能します。

手順 2: リージョン 1、サブスクリプション 2 (コンテナー 2) でバックアップを有効にする

  1. プライマリ ノードがコンテナー 2 に存在するように、AG を VM3 にフェールオーバーします。
  2. コンテナー 2 で AG データベースのバックアップを構成します。
  3. この時点で:
    1. 登録されているどのノードもこのバックアップを実行できないので、コンテナー 1 での完全または差分バックアップは失敗します。
    2. ログ バックアップがコンテナー 2 で実行され、コンテナー 1 のログ チェーンが "切断される" まで、コンテナー 1 でのログ バックアップは成功します。
  4. AG を VM1 にフェールバックします。

手順 3: リージョン 2、サブスクリプション 1 (コンテナー 4) でバックアップを有効にする

手順 2 と同じです。

Azure とオンプレミスにまたがる AG のバックアップ

SQL Server 用の Azure Backup は、オンプレミスでは実行できません。 プライマリ ノードが Azure 内にあり、バックアップ設定が Azure 内のノードによって満たされている場合は、上記のマルチリージョン AG 用のガイダンスに従って、Azure でレプリカのバックアップを有効にできます。 オンプレミスのノードへのフェールオーバーが発生した場合、Azure での完全および差分バックアップは失敗し始めます。 ログ バックアップは、ログ チェーンが切断されるか、15 日が経過するまで続行できます。

AG データベースでのバックアップ ジョブの調整

現在、バックアップ調整の制限は、個々のマシン レベルで適用されます。 既定の制限は 20 です。20 件を超えるバックアップが同時にトリガーされると、最初の 20 件が実行され、残りはキューに入れられます。 実行中のジョブが完了すると、キューに入っているものの実行が開始されます。

同時実行のバックアップによってノード上のメモリ、IO、または CPU に負荷がかかっている場合は、この値を小さい値に変更できます。 調整はノード レベルで行われるため、AG ノードが不均衡になると、バックアップの同期に関する問題が発生する可能性があります。 これを理解するために、2 ノードの AG を例にとって考えてみましょう。

たとえば、1 つ目のノードで 50 個のスタンドアロン データベースが保護されており、両方のノードでそれぞれ 5 個の AG データベースが保護されています。 実質的には、ノード 1 で 55 件のデータベース バックアップ ジョブがスケジュールされているのに対し、ノード 2 ではわずか 5 件です。 また、これらのバックアップはすべて、1 時間おきに同時に実行されるように構成されています。 ある時点で、55 件のバックアップがすべてノード 1 でトリガーされ、そのうちの 35 件がキューに入れられます。 これらの一部は、AG データベースのバックアップになります。 しかし、ノード 2 では、AG データベースのバックアップがキューを使用せずに進められます。

AG データベース ジョブが一方のノードではキューに入れられ、もう一方のノードでは実行されているので、バックアップの同期 (セクション 6 で説明) が正しく機能しません。 ノード 2 ではノード 1 がダウンしているものと見なしている可能性があるため、そこからのジョブは同期の対象になっていません。 そのため、両方のノードで別々にバックアップを実行できるため、ログ チェーンの切断や追加のバックアップが発生する可能性があります。

保護されている AG データベースの数が調整の制限を超えると、同様の問題が発生する可能性があります。 そのような場合、DB1 などのバックアップがノード 1 ではキューに入れられる可能性があるのに対し、ノード 2 では実行されます。

こうした同期の問題を回避するために、次のバックアップ設定を使用することをお勧めします。

  • 2 ノードの AG の場合、バックアップ設定を [プライマリ] または [セカンダリのみ] に設定します。これにより、1 つのノードでのみバックアップを実行でき、他方では常にスキップされるようになります。
  • 2 ノードを超える AG の場合、バックアップ設定を [プライマリ] に設定します。これにより、プライマリ ノードのみでバックアップを実行でき、他方ではスキップされるようになります。

AG バックアップの課金

スタンドアロンの SQL インスタンスと同様に、1 つのバックアップ AG インスタンスが 1 つの保護されたインスタンスと見なされます。 1 つのインスタンス内のすべての保護されたデータベースのフロントエンド サイズの合計について課金されます。 次のデプロイについて考えてみましょう。

Diagram showing the calculation of protected instances of databases.

保護されたインスタンスは次のように計算されます。

保護されたインスタンス/課金インスタンス フロントエンド サイズの計算対象となるデータベース
AG1 DB1、DB2
AG2 DB4
VM2 DB3
VM3 DB6
VM4 DB5

保護されたデータベースの AG 内外への移動

Azure Backup では、SQL インスタンスまたは AG 名\データベース名をデータベースの一意の名前と見なします。 スタンドアロン DB が保護されていた場合、その一意の名前は StandAloneInstanceName\DBName でした。 それが AG の下に移動すると、一意の名前が AGName\DBName に変わります。 そのスタンドアロン データベースのバックアップは、エラー コード UserErrorBackupFailedStandaloneDatabaseMovedInToAG で失敗し始めます。

AG の下で保護されるように、そのデータベースを構成する必要があります。 これは、別の復旧ポイント チェーンを持つ新しいデータ ソースとして扱われます。 データを保持した状態でスタンドアロン データベースの以前の保護を停止することで、今後のバックアップがトリガーされて失敗するのを回避できます。 同様に、保護された AG データベースが AG の外部に移動して、スタンドアロン データベースになった場合、そのバックアップはエラー コードUserErrorBackupFailedDatabaseMovedOutOfAG で失敗し始めます。

スタンドアロン インスタンスの下で保護されるように、そのデータベースを構成する必要があります。 これは、別の復旧ポイント チェーンを持つ新しいデータ ソースとして扱われます。 データを保持した状態で AG データベースの以前の保護を停止することで、今後のバックアップがトリガーされて失敗するのを回避できます。

AG へのノードの追加または削除

バックアップ用に構成されている AG に新しいノードが追加されると、既に登録されている AG ノード上で実行されているワークロード バックアップ拡張機能により、AG トポロジの変更が検出され、次回のスケジュールされたデータベース検出ジョブの実行中に Azure Backup サービスに通知されます。 この新しいノードが、他の既存のノードと同じ Recovery Services コンテナーにバックアップ用として登録されると、Azure Backup サービスでは、AG バックアップの実行に必要なメタデータを使用してこの新しいノードを構成するワークフローをトリガーします。

この後、新しいノードでは、Azure Backup サービスからの AG バックアップ スケジュール情報を同期させ、同期されたバックアップ プロセスへの参加を開始します。 新しいノードでバックアップ スケジュールを同期できず、バックアップに参加できない場合、ノードの再登録をトリガーすると、AG バックアップ用にもノードの再構成が強制的に行われます。 同様に、ノードの追加でも、この場合はワークロード拡張機能によって AG トポロジの変更が検出され、Azure Backup サービスに通知されます。 このサービスでは、削除されたノードでノードの "構成解除" ワークフローを開始して AG データベース用のバックアップ スケジュールをクリアし、AG 関連のメタデータを削除します。

Azure Backup からの AG ノードの登録解除

1 つ以上のデータベースがバックアップ用に構成されている AG にノードが 1 つ含まれている場合、Azure Backup ではそのノードの登録解除を許可しません。 これは将来、そのノードがないとバックアップ設定を満たすことができない場合にバックアップ エラーが発生するのを防ぐためです。 ノードの登録を解除するには、最初にそれを AG から削除する必要があります。 ノードの "構成解除" ワークフローが完了したら、そのノードをクリーンアップして、登録を解除できます。

Azure Backup から AG SQL 可用性グループへのデータベースの復元では、データベースを AG に直接復元する方法がサポートされていません。 データベースをスタンドアロンの SQL インスタンスに復元してから、AG に参加させる必要があります。

SQL データベース サーバーの可用性グループの再作成シナリオ

次のシナリオでは、可用性グループ (AG)、重複した AG、バックアップ項目の再作成が、"保護可能な項目" または "保護された項目" として一覧表示されます。

  • 既に保護されている AG を再作成すると、[バックアップの構成] ページおよび [保護された項目] 一覧に重複した AG として表示されます。 以前の AG に既に存在するバックアップ データを保持したい場合は、新しい AG 項目でバックアップを再作成してスケジュールする前に、[保護を停止してデータを保持する] オプションを使ってバックアップを停止します。

    設計上、Azure Backup は重複項目を [保護された項目] 一覧、[バックアップの構成] ページまたは [保護可能な保護された] 一覧に一覧表示し、バックアップ データを保持するまでこれらの項目を表示します。

  • 以前の AG からのバックアップ データが不要な場合は、新しい AG でバックアップを再作成してスケジュールする前に、以前の項目に対して [保護を停止してデータを削除する] オプションを使ってバックアップ操作を停止します。

    注意

    保護を停止してデータを削除することは破壊的な操作です。

  • 上記の保護停止プロセスのいずれかを実行した後、AG を再作成して、バックアップの失敗を回避できます。

次のステップ

具体的には、次の方法を学習します。