Azure Backup では、すべてのノードが Recovery Services コンテナーと同じリージョンおよびサブスクリプション内にある場合に、SQL Server Always On 可用性グループ (AG) のバックアップをエンド ツー エンドでサポートします。 ただし、AG ノードが複数のリージョン、サブスクリプション、またはオンプレミスや、Azure 全体に分散している場合は、注意すべき考慮事項がいくつかあります。
現在サポートされているバックアップと復元のシナリオを確認するには、サポート マトリックスを参照してください。 よく寄せられる質問については、 よく寄せられる質問を参照してください。
注
Azure Backupでは、基本的な可用性グループ データベースのバックアップはサポートされていません。
SQL Server バージョン別のバックアップ優先動作
セカンダリ レプリカでの完全バックアップと差分バックアップのサポートは、SQL Serverバージョンによって異なります。 AG バックアップの基本設定とSQL Serverバージョンによって、バックアップの種類ごとに選択されたノードが決まります。
SQL Server 2022 以前
Azure Backup の SQL AG で使用されるバックアップ設定では、プライマリ レプリカからの完全および差分バックアップのみがサポートされています。 そのため、これらのバックアップ ジョブは、バックアップの設定に関係なく、常にプライマリ ノードで実行されます。 コピーのみの完全およびトランザクション ログ バックアップの場合は、バックアップが実行されるノードを決定する際に AG のバックアップ設定が考慮されます。
| AG バックアップのオプション | 完全バックアップと差分バックアップを実行する | コピーのみおよびログ バックアップの取得元 |
|---|---|---|
| プライマリ | プライマリ レプリカ | プライマリ レプリカ |
| [セカンダリのみ] | プライマリ レプリカ | セカンダリ レプリカのいずれか 1 つ |
| [セカンダリを優先] | プライマリ レプリカ | セカンダリ レプリカが推奨されますが、プライマリ レプリカでもバックアップを実行できます。 |
| なし/任意 | プライマリ レプリカ | 任意のレプリカ |
SQL Server 2025 以降
SQL Server 2025 以降では、セカンダリ レプリカでも完全バックアップと差分バックアップがサポートされます。 バックアップ設定によって、両方のバックアップの種類が一様に管理されるようになりました。 [セカンダリのみ] または [セカンダリを優先] を設定した場合、完全バックアップと差分バックアップではプライマリ ノードが不要になります。
| AG バックアップのオプション | 完全バックアップと差分バックアップを実行する | コピーのみおよびログ バックアップの取得元 |
|---|---|---|
| プライマリ | プライマリ レプリカ | プライマリ レプリカ |
| [セカンダリのみ] | セカンダリ レプリカのいずれか 1 つ | セカンダリ レプリカのいずれか 1 つ |
| [セカンダリを優先] | セカンダリ レプリカが推奨されますが、プライマリ レプリカでもバックアップを実行できます。 | セカンダリ レプリカが推奨されますが、プライマリ レプリカでもバックアップを実行できます。 |
| なし/任意 | 任意のレプリカ | 任意のレプリカ |
Azure Backup サービスにノードを登録すると、そのノードにワークロード バックアップ拡張機能がインストールされます。 バックアップ用に AG データベースを構成すると、バックアップ スケジュールが AG のすべての登録済みノードにプッシュされます。 スケジュールはすべての AG ノードで実行され、これらのノードのワークロード バックアップ拡張機能は互いに同期して、バックアップを実行できるノードを決定します。 ノードの選択は、バックアップの種類と、SQL Serverバージョン別のバックアップ基本設定の動作で説明されているバックアップの基本設定によって異なります。
選択したノードではバックアップ ジョブが続行されますが、他のノードでトリガーされたジョブはスキップされます。
注
Azure Backup では、セカンダリ レプリカの中から選ぶ際に、バックアップの優先順位やレプリカは考慮しません。
Recovery Services コンテナーへの AG ノードの登録
Recovery Services コンテナーでは、コンテナーと同じリージョンおよびサブスクリプション内の VM からのデータベースのバックアップのみがサポートされています。
SQL Server 2022 以前:
- プライマリ ノードをボールトに登録します（そうしなければ完全バックアップを実行できません）。
- バックアップの設定が "セカンダリのみ" である場合は、少なくとも 1 つのセカンダリ ノードをコンテナーに登録します (そうしないと、ログまたはコピーのみの完全バックアップを実行できません)。
上記の条件が満たされていない場合、AG データベースのバックアップの構成はエラー コード FabricSvcBackupPreferenceCheckFailedUserError で失敗します。
SQL Server 2025 以降:
- AG バックアップ構成では、プライマリ ノードの登録は 必須ではなくなりました 。 完全バックアップと差分バックアップはセカンダリ レプリカで実行できるようになったため、セカンダリ ノードのみを登録してバックアップを構成できます (バックアップ優先が [セカンダリのみ] または [ セカンダリを優先する] の場合)。
- プライマリ バックアップ設定では、プライマリ ノードを登録する必要があります。
- 選択したバックアップ設定を満たすノードを少なくとも 1 つ登録します。
注
プライマリ ノードの登録要件の緩和は、AG データベースの検出中に検出されたSQL Serverバージョンによって制限されます。 AG 内のレプリカが 2022 以前SQL Server実行されている場合、その AG のプライマリ ノード登録要件は引き続き有効です。
参考として次の AG デプロイについて考えてみましょう。
示した AG デプロイのサンプルに基づいて、さまざまな考慮事項を次に示します。
- リージョン 1 およびサブスクリプション 1 内にプライマリ ノードがあるので、この AG を保護するには Recovery Services コンテナー (コンテナー 1) がリージョン 1 およびサブスクリプション 1 内にある必要があります。
-
VM3は、異なるサブスクリプション内にあるので、コンテナー 1 に登録できません。 -
VM4は、異なるリージョン内にあるので、コンテナー 1 に登録できません。 - バックアップ設定が セカンダリのみの場合は、VM1 (プライマリ) と VM2 (セカンダリ) をコンテナー 1 に登録します。 SQL Server 2022 以前では、完全バックアップにはプライマリ ノードが必要であるため、両方のノードを登録します。SQL Server 2025 以降では、VM2 だけで十分です。 その他のバックアップ設定については、VM1 (プライマリ) を Vault 1 に登録します。VM2 は省略可能です。
- VM3 をサブスクリプション 2 のコンテナー 2 に登録すると、AG データベースはコンテナー 2 で保護対象として表示されますが、コンテナー 2 にプライマリ ノードがないため、バックアップの構成は 2022 年以前SQL Server失敗します。 SQL Server 2025 以降では、バックアップ設定が [セカンダリのみ]または [セカンダリ優先] の場合は、コンテナー 2 でバックアップを構成できます。
- 同様に、VM4 をリージョン 2 の vault 4 に登録することはできますが、プライマリ ノードが vault 4 に登録されていないため、SQL Server 2022 以前ではバックアップの構成は失敗します。 SQL Server 2025 以降では、バックアップ設定が [セカンダリのみ]または [セカンダリ優先] の場合は、コンテナー 4 でバックアップを構成できます。
フェールオーバーの処理
AG がセカンダリ ノードの 1 つにフェールオーバーされた後は、次のようになります。
- SQL Server 2022 以前: 完全バックアップおよび差分バックアップは、新しいプライマリ ノードがコンテナーに登録されている場合、そのノードから継続されます。
- SQL Server 2025 以降: 完全バックアップと差分バックアップは、バックアップ設定を満たすノードから続行されます。 セカンダリのみまたは優先セカンダリの場合、これらのバックアップはセカンダリ レプリカで実行できます。
- バックアップ設定に基づいて、ログおよびコピーのみの完全バックアップがプライマリまたはセカンダリ ノードから続行されます。
注
フェールオーバーがバックアップと重ならなければ、フェールオーバー時にログ チェーンは切断されません。
上記の AG デプロイのサンプルに基づいて、考えられるさまざまなフェールオーバーを次に示します。
- VM2 へのフェールオーバー
- 完全および差分バックアップが VM2 から行われます。
- バックアップ設定に基づいて、ログおよびコピーのみの完全バックアップが VM1 または VM2 から行われます。
- VM3 (別のサブスクリプション) へのフェールオーバー
- 保存庫 2 においてはバックアップが構成されていないため、バックアップは行われないでしょう。
- SQL Server 2022 以前では、バックアップ設定がセカンダリ専用でない場合は、プライマリ ノードがこのコンテナーに登録されているため、Vault 2 でバックアップを構成できるようになりました。 SQL Server 2025 以降では、Vault 2 に登録されているノードが選択したバックアップ設定を満たす場合にバックアップを構成することもできます。 この状態により、競合やバックアップエラーが発生する可能性があります。 詳細については、「 複数リージョン AG のバックアップを構成する」を参照してください。
- VM4 (別のリージョン) へのフェールオーバー
- ボールト 4 ではバックアップが設定されていないので、バックアップは行われません。
- SQL Server 2022 以前では、バックアップ設定がセカンダリ専用でない場合は、プライマリ ノードがこのコンテナーに登録されているため、Vault 4 でバックアップを構成できるようになりました。 SQL Server 2025 以降では、Vault 4 に登録されているノードが選択したバックアップ設定を満たしている場合にバックアップを構成することもできます。 この状態により、競合やバックアップエラーが発生する可能性があります。 詳細については、「 複数リージョン AG のバックアップを構成する」を参照してください。
マルチリージョン AG のバックアップの構成
Recovery Services ボールトでは、異なるサブスクリプション間または異なるリージョン間のバックアップをサポートしていません。 ここでは、複数のサブスクリプションまたは Azure リージョンにまたがる AG のバックアップを有効にする方法と、関連する考慮事項について説明します。
すべてのノードからのバックアップを本当に有効にする必要があるかどうかを評価します。 1 つのリージョンまたはサブスクリプションにほとんどの AG ノードが含まれており、他のノードへのフェールオーバーがめったに発生しない場合は、その最初のリージョンでバックアップを設定するだけで十分です。 他のリージョンやサブスクリプションへのフェールオーバーが頻繁に発生し、長期間にわたる場合は、他のリージョンでもバックアップを事前に設定することが必要になる場合があります。
バックアップが有効になっている各ボールトには、独自の復旧ポイントチェーンのセットがあります。 これらの復旧ポイントからの復元は、そのコンテナーに登録されている VM に対してのみ実行できます。
SQL Server 2022 以前: 完全バックアップと差分バックアップは、プライマリ ノードを持つコンテナーでのみ機能します。 他のボールト内にあるこれらのバックアップは失敗し続けています。 SQL Server 2025 以降では、この動作は [セカンダリのみ] と [セカンダリ優先] の基本設定に変更されます。「SQL Server 2025: 複数リージョン AG バックアップの変更」を参照してください。
ログ バックアップは、新しいコンテナー (つまり、新しいプライマリ ノードが存在するコンテナー) でログ バックアップが実行されるようになり、古いコンテナーに対するログ チェーンが "切断" されるまで、以前のコンテナーで機能し続けます。
注
15 日間というハード制限があり、それを超えると、ログ バックアップは失敗し始めます。
コピーのみの完全バックアップは、すべてのコンテナーで機能します。
各保管庫での保護は、別々のデータソースとして扱われ、それぞれに請求されます。
2 つのボールト間のログ バックアップの競合を回避するために、バックアップの優先順位を[プライマリ]に設定することをお勧めします。 これにより、プライマリ ノードを含むどのボールトでもログバックアップを取得します。
SQL Server 2025: 複数リージョンの AG バックアップの変更
SQL Server 2025 では、完全バックアップと差分バックアップではプライマリ ノードは不要になります。 この変更は、次のことを意味します。
プライマリ ノードの登録は必要ありません 。バックアップ設定が [セカンダリのみ] または [ セカンダリを優先する] の場合は、プライマリ ノードが別のリージョンまたはサブスクリプションにある場合でも、登録されている任意のセカンダリ ノードからバックアップを構成して実行できます。
フェールオーバーの影響の軽減 - 別のリージョンのノードへのフェールオーバー後、バックアップ設定を満たす登録済みノードが使用可能である限り、元のコンテナーでバックアップを続行できます。
ただし、クロスボールト調整に関する根本的な制約は残ります — 複数のボールト間でバックアップを調整することはできません。 リージョン間で異なるコンテナーに AG ノードを登録すると、同時バックアップ スケジュールが競合し、ログ チェーンの中断やバックアップの重複が発生する可能性があります。
コンテナー間の競合を回避するための推奨事項:
- 2 ノード AG: バックアップ優先設定を [セカンダリのみ] または [ プライマリ] に設定します。
- 3 つ以上のノード AG: バックアップ優先設定を プライマリに設定します。
この構成により、常に 1 つのボールトのノードのみがバックアップの対象となります。
上記の AG デプロイのサンプルに基づいて、すべてのノードからのバックアップを有効にする手順を次に示します。 すべての手順でバックアップ設定が満たされていることを前提としています。
手順 1: リージョン 1、サブスクリプション 1 (コンテナー 1) でバックアップを有効にする
プライマリ ノードがリージョンおよびサブスクリプション内にあるので、バックアップを有効にする通常の手順が機能します。
手順 2: リージョン 1、サブスクリプション 2 (コンテナー 2) でバックアップを有効にする
- プライマリ ノードがコンテナー 2 に存在するように、AG を VM3 にフェールオーバーします。
- コンテナー 2 で AG データベースのバックアップを構成します。
- この時点で:
- 登録されているどのノードもこのバックアップを実行できないので、コンテナー 1 での完全または差分バックアップは失敗します。
- ログ バックアップがコンテナー 2 で実行されるようになり、コンテナー 1 に対するログ チェーンが "切断" されるまで、コンテナー 1 でのログ バックアップは成功します。
- 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 データベース ジョブが 1 つのノードでキューに入り、別のノードで実行されるため、バックアップ同期が正しく機能しません。 ノード 2 では、ノード 1 がダウンしているため、ノード 1 からのジョブが同期を開始していないと想定される場合があります。 この問題は、両方のノードが個別にバックアップを作成できるため、ログ チェーンの中断や追加のバックアップにつながる可能性があります。
保護されている AG データベースの数が調整の制限を超えると、同様の問題が発生する可能性があります。 そのような場合、DB1 などのバックアップがノード 1 ではキューに入れられる可能性があるのに対し、ノード 2 では実行されます。
こうした同期の問題を回避するために、次のバックアップ設定を使用することをお勧めします。
- 2 ノードの AG の場合、バックアップの設定を [プライマリ] または [セカンダリのみ] にします。これにより、バックアップは一方のノードでのみ実行され、他方のノードでは常に中止されます。
- 2 ノードを超える AG の場合、バックアップ選好設定を [プライマリ] に設定します。これにより、プライマリ ノードのみがバックアップを実行でき、他のノードではバックアップが中止されるようになります。
AG バックアップの課金
スタンドアロンの SQL インスタンスと同様に、1 つのバックアップ AG インスタンスが 1 つの保護されたインスタンスと見なされます。 1 つのインスタンス内のすべての保護されたデータベースのフロントエンド サイズの合計について課金されます。 次のデプロイについて考えてみましょう。
保護されたインスタンスは次のように計算されます。
| 保護されたインスタンス/課金インスタンス | フロントエンド サイズの計算対象となるデータベース |
|---|---|
| AG1 | DB1、DB2 |
| AG2 | DB4 |
| VM2 | DB3 |
| VM3 | DB6 |
| VM4 | DB5 |
保護されたデータベースを AG 内または 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 を再作成して、バックアップの失敗を回避できます。
SQL Server 2025 AG のバックアップに関する考慮事項
構成後のバックアップ設定の変更
AG バックアップの基本設定を変更しても、必要なノードをコンテナーに登録しない場合、バックアップは失敗します。 たとえば、基本設定を プライマリ から セカンダリのみに 変更しても、セカンダリ ノードが登録されていない場合、ログバックアップと完全バックアップ/差分バックアップは失敗します。 変更を行う前に、常に新しいバックアップ設定を満たすノードがコンテナーに登録されていることを確認してください。
複数リージョンの AG バックアップの調整
異なるリージョン内の複数のコンテナー間で AG ノードを保護する場合、コンテナーは、SQL Serverバージョンに関係なく、それらの間のバックアップを調整できません。 このシナリオでのログ チェーンの中断とバックアップの重複を回避するバックアップ基本設定のガイダンスについては、「SQL Server 2025: 複数リージョン AG バックアップの変更」を参照してください。
スナップショット バックアップのサポート
スナップショット バックアップは、AG のセカンダリ レプリカではサポートされていません 。 バックアップ ポリシーでスナップショット バックアップを有効にした場合、プライマリ ノードの登録は、SQL Serverバージョンに関係なく必須のままです。
次のステップ
具体的には、次の方法を学習します。
関連コンテンツ
- REST API を使用して Azure Backup を使用して Azure VM 内の SQL Server データベースをバックアップします。
- REST API を使用して Azure VM 内の SQL Server データベースを復元します。
- Azure portal、Azure CLI、REST API を使用して、Azure VM 内の SQL Server データベースを管理します。