次の方法で共有

Recovery Services コンテナーから複数の SQL Server VM をバックアップする

  • [アーティクル]

SQL Server データベースは、低い回復ポイントの目標値 (RPO) と長期のリテンション期間を必要とする重要なワークロードです。 Azure Backup を使用して、Azure 仮想マシン (VM) 上で稼働している SQL Server データベースをバックアップできます。

この記事では、Azure VM 上で稼働している SQL Server データベースを Azure Backup Recovery Services コンテナーにバックアップする方法について説明します。

Note

サポートされている構成とシナリオの詳細については、SQL バックアップのサポート マトリックスに関する記事を参照してください。

前提条件

SQL Server データベースをバックアップする前に、次の基準を確認してください。

  1. SQL Server インスタンスをホストする VM として、同じリージョンおよびサブスクリプションの Recovery Services コンテナーを特定または作成する。

  2. VM がネットワーク接続を備えていることを確認する。

  3. VM に Azure 仮想マシン エージェントがインストールされていることを確認します。

  4. VM に .NET 4.6.2 バージョン以降がインストールされていることを確認します。

    注意事項

    .NET Framework 4.6.1 以降を実行している SQL VM のバックアップのサポートは、これらのバージョンが正式にサポートされていないため、間もなく非推奨になります。 バックアップエラーが発生しないように、.NET Framework をバージョン 4.6.2 以降にアップグレードすることをお勧めします。

  5. SQL Server データベースが、Azure Backup のためのデータベースの命名に関するガイドラインに従っていることを確認する。

  6. SQL Server VM 名とリソース グループ名とを組み合わせた長さが、Azure Resource Manager VM の場合は 84 文字、クラシック VM の場合は 77 文字を超えないようにしてください。 この制限は、一部の文字がサービスによって予約されていることに起因します。

  7. データベースに対して有効になっているバックアップ ソリューションが他にないことをチェックする。 データベースをバックアップする前に、他のすべての SQL Server バックアップを無効にします。

  8. SQL Server 2008 R2 または SQL Server 2012 を使用している場合は、こちらに記載されているバックアップのタイム ゾーンの問題が発生する場合があります。 上記のタイム ゾーンに関連する問題を回避するために、最新の累積的な更新プログラムを適用していることを確認してください。 Azure VM の SQL Server インスタンスに更新プログラムの適用が不可能な場合は、仮想マシン上のタイム ゾーンの夏時間 (DST) を無効にします。

Note

Azure VM に対してだけでなく、VM 上で稼働している SQL Server データベースに対しても、競合を発生させることなく Azure Backup を有効にすることができます。

ネットワーク接続を確立する

すべての操作において、SQL Server VM には Azure Backup サービス、Azure Storage、および Microsoft Entra ID への接続が必要です。 これは、プライベート エンドポイントを使用するか、必要なパブリック IP アドレスまたは FQDN へのアクセスを許可することによって実現できます。 必要な Azure サービスへの適切な接続を許可しないと、データベースの検出、バックアップの構成、バックアップの実行、データの復元などの操作の失敗につながる可能性があります。

次の表に、接続の確立に使用できるさまざまな選択肢を示します。

オプション 長所 短所
プライベート エンドポイント 仮想ネットワーク内のプライベート IP 経由でのバックアップを可能にする

ネットワークとコンテナーの側で詳細な制御を提供する		 標準のプライベート エンドポイント コストが発生する
NSG サービス タグ 範囲の変更が自動的にマージされるため管理しやすい

追加のコストが発生しない		 NSG でのみ使用可能

サービス全体へのアクセスを提供する
Azure Firewall の FQDN タグ 必要な FQDN が自動的に管理されるため管理しやすい Azure Firewall でのみ使用可能
サービスの FQDN/IP へのアクセスを許可する 追加のコストが発生しない。

すべてのネットワーク セキュリティ アプライアンスとファイアウォールで動作する。

Storage と Microsoft Entra ID にはサービス エンドポイントを使用することもできます。 ただし、Microsoft Azure Backupの場合は、対応する IPs/FQDNs へのアクセスを割り当てる必要があります。		 広範な IP または FQDN のセットにアクセスする必要がある場合があります。
HTTP プロキシを使用する VM に対するインターネット アクセスを単一の場所で実現 プロキシ ソフトウェアで VM を実行するための追加のコストが発生する

次のセクションでは、これらのオプションの使用について詳しく説明します。

注意

Azure Backup 接続テスト スクリプト を使用して、Windows 環境でのネットワーク接続の問題を自己診断できます。

プライベート エンドポイント

プライベート エンドポイントを使用すると、仮想ネットワーク内のサーバーから Recovery Services コンテナーに安全に接続できます。 プライベート エンドポイントでは、お使いのコンテナーの VNET アドレス空間からの IP アドレスが使用されます。 仮想ネットワーク内のリソースとコンテナー間のネットワーク トラフィックは、仮想ネットワークと Microsoft のバックボーン ネットワーク上のプライベート リンクを経由します。 これにより、パブリック インターネットへの露出が排除されます。 こちらから、Azure Backup のプライベート エンドポイントの詳細を参照してください。

NSG タグ

ネットワーク セキュリティ グループ (NSG) を使用する場合は、*AzureBackup* サービス タグを使用して、Azure Backup への発信アクセスを許可します。 Azure Backup タグに加えて、Microsoft Entra ID (AzureActiveDirectory) および Azure Storage (Storage) に対して同様の NSG 規則を作成することによって、認証とデータ転送のための接続を許可する必要もあります。 次の手順では、Azure Backup タグの規則を作成するプロセスについて説明します。

  1. [すべてのサービス] で、 [ネットワーク セキュリティ グループ] に移動して、ネットワーク セキュリティ グループを選択します。

  2. [設定] で [送信セキュリティ規則] を選択します。

  3. [追加] を選択します。 セキュリティ規則の設定の説明に従って、新しい規則を作成するために必要なすべての詳細を入力します。 オプション [宛先] が [サービス タグ] に、 [宛先サービス タグ] が [AzureBackup] に設定されていることを確認します。

  4. [追加] を選択して、新しく作成した送信セキュリティ規則を保存します。

Azure Storage と Microsoft Entra ID に対する NSG 送信セキュリティ規則も、同様に作成できます。

Azure Firewall タグ

Azure Firewall を使用している場合は、AzureBackup Azure Firewall FQDN タグを使用してアプリケーション規則を作成します。 これにより、Azure Backup へのすべての発信アクセスが許可されます。

Note

Azure Backup は現在、Azure Firewall で TLS 検査が有効になっている アプリケーション規則をサポートしていません。

サービスの IP 範囲へのアクセスを許可する

サービスの IP へのアクセスを許可することを選択した場合は、[こちら]から利用可能な IP 範囲の JSON ファイルを参照してください。 Azure Backup、Azure Storage、Microsoft Entra ID に対応する IP へのアクセスを許可する必要があります。

サービスの FQDN へのアクセスを許可する

次の FQDN を使用することで、サーバーから必要なサービスへのアクセスを許可することもできます。

サービス アクセスするドメイン名 ポート
Azure Backup *.backup.windowsazure.com 443
Azure Storage *.blob.core.windows.net

*.queue.core.windows.net

*.blob.storage.azure.net		 443
Azure AD *.login.microsoft.com

この記事に従って、セクション 56 および 59 の FQDN へのアクセスを許可します		 443

該当する場合

内部ロード バランサーの背後にあるサーバーの接続を許可する

内部ロード バランサーの使用時には、内部ロード バランサーの背後にある仮想マシンからの送信接続を許可し、バックアップを実行する必要があります。 それを行うために、内部と外部の標準ロード バランサーを組み合わせて利用することで、送信接続を作成できます。 内部ロード バランサーのバックエンド プール内に VM の "エグレス専用" セットアップを作成する構成について、詳細を確認してください。

トラフィックをルーティングするために HTTP プロキシ サーバーを使用する

Azure VM 上の SQL Server データベースをバックアップする場合、VM 上のバックアップ拡張機能によって HTTPS API が使用され、管理コマンドが Azure Backup に送信されてデータが Azure Storage に送信されます。 また、バックアップ拡張機能では、認証に Microsoft Entra ID を使用します。 HTTP プロキシ経由でこれらの 3 つのサービスのバックアップ拡張機能のトラフィックをルーティングします。 必要なサービスへのアクセスを許可するには、上記で説明した IP と FQDN の一覧を使用します。 認証済みプロキシ サーバーはサポートされません。

Note

VM 内の localhost 通信のプロキシを無効にします。 プロキシは、SQL VM からの送信方向の通信に使用されます。

Azure Backup のためのデータベースの命名に関するガイドライン

  • データベースの名前に次の要素を使用しないでください。

    • 末尾および先頭のスペース
    • 末尾の感嘆符 (!)
    • 終わり角かっこ (])
    • セミコロン (;)
    • スラッシュ (/)
    • パーセント (%)

  • SQL バックアップ構成では、データベース名の一重引用符がサポートされていないため、デプロイ エラーが発生します。 一重引用符で囲まれたデータベースがある場合は、データベースの名前を変更するか、ネイティブ バックアップのアプローチを採用することをお勧めします。

  • サポートされていない文字のエイリアス処理は用意されていますが、これらは使用しないことをお勧めします。 詳細については、「 Table サービス データ モデルについて」を参照してください。

  • 同じ SQL インスタンス上の大文字と小文字が異なる複数のデータベースはサポートされません。

  • 保護の構成後は、SQL データベースの大文字と小文字の区別の変更はサポートされません。

Note

名前に {、'}、[、]、,、=、-、(、)、.、+、&、;、'、または / などの特殊文字が含まれるデータベースに対する保護の構成操作はサポートされていません。 データベース名を変更するか、これらのデータベースを適切に保護できる自動保護を有効にできます。

Recovery Services コンテナーを作成する

Recovery Services コンテナーは、時間の経過と共に作成される復旧ポイントを格納する管理エンティティであり、バックアップ関連の操作を実行するためのインターフェイスが用意されています。 たとえば、オンデマンドのバックアップの作成、復元の実行、バックアップ ポリシーの作成などの操作です。

Recovery Services コンテナーを作成するには、次の手順に従います。

  1. Azure portal にサインインします。

  2. 「バックアップ センター」を検索し、[バックアップ センター] ダッシュボードに移動します。

    [バックアップ センター] を検索し、選択する場所を示すスクリーンショット。

  3. [概要] ペインで、[コンテナー] を選択します。

    Recovery Services コンテナーを作成するためのボタンのスクリーンショット。

  4. [Recovery Services コンテナー]>[続行] の順に選択します。

    コンテナーの種類として Recovery Services を選択する場所を示すスクリーンショット。

  5. [Recovery Services コンテナー] ペインで、次の値を入力します。

    • [サブスクリプション] : 使用するサブスクリプションを選択します。 1 つのサブスクリプションのみのメンバーの場合は、その名前が表示されます。 どのサブスクリプションを使用すればよいかがわからない場合は、既定のサブスクリプションを使用してください。 職場または学校アカウントが複数の Azure サブスクリプションに関連付けられている場合に限り、複数の選択肢が存在します。

    • [リソース グループ] :既存のリソース グループを使用するか、新しいリソース グループを作成します。 サブスクリプションの使用可能なリソース グループの一覧を表示するには、[既存のものを使用] を選択してから、ドロップダウン リストでリソースを選択します。 新しいリソース グループを作成するには、[新規作成] を選択し、名前を入力します。 リソース グループの詳細については、「Azure Resource Manager の概要」を参照してください。

    • [コンテナー名]: コンテナーを識別するフレンドリ名を入力します。 名前は Azure サブスクリプションに対して一意である必要があります。 2 文字以上で、50 文字以下の名前を指定します。 名前の先頭にはアルファベットを使用する必要があります。また、名前に使用できるのはアルファベット、数字、ハイフンのみです。

    • [リージョン]: コンテナーの地理的リージョンを選択します。 データ ソースを保護するためのコンテナーを作成するには、コンテナーがデータ ソースと同じリージョン内にある "必要があります"。

      重要

      データ ソースの場所が不明な場合は、ウィンドウを閉じます。 ポータルの自分のリソースの一覧に移動します。 複数のリージョンにデータ ソースがある場合は、リージョンごとに Recovery Services コンテナーを作成します。 最初の場所にコンテナーを作成してから、別の場所にコンテナーを作成します。 バックアップ データを格納するためにストレージ アカウントを指定する必要はありません。 Recovery Services コンテナーと Azure Backup で自動的に処理されます。

    Recovery Services コンテナーを構成するためのフィールドを示すスクリーンショット。

  6. 値を指定したら、 [確認と作成] を選択します。

  7. Recovery Services コンテナーの作成を完了するには、[作成] を選択します。

    Recovery Services コンテナーの作成に時間がかかることがあります。 右上の [通知] 領域で、状態の通知を監視します。 作成されたコンテナーは、Recovery Services コンテナーのリストに表示されます。 コンテナーが表示されない場合は、[最新の情報に更新] を選択します。

    バックアップ コンテナーの一覧を更新するボタンを示しているスクリーンショット。

注意

Azure Backup は、作成された復旧ポイントがバックアップ ポリシーに従って、有効期限切れ前に削除されないようにできる不変コンテナーをサポートするようになりました。 また、不変性を元に戻せないようにして、ランサムウェア攻撃や悪意のあるアクターなど、さまざまな脅威からバックアップ データを最大限に保護することができます。 詳細については、こちらを参照してください。

SQL Server データベースを検出する

VM 上で稼働しているデータベースを検出する方法:

  1. Azure portal で、 [バックアップ センター] に移動し、 [バックアップ] をクリックします。

  2. [データソースの種類] として [Azure VM の SQL] を選択し、作成した Recovery Services コンテナーを選択して、 [続行] をクリックします。

    [バックアップ] を選択して VM で実行されているデータベースを表示することを示すスクリーンショット。

  3. [バックアップの目標]>[VM 内のデータベースを検出] で、 [検出の開始] を選択して、サブスクリプション内にある保護されていない VM を検索します。 サブスクリプション内にある保護されていない VM の数によっては、この検索に少し時間がかかる場合があります。

    • 保護されていない VM は検出後、名前およびリソース グループ別に一覧に表示されます。

    • VM が予想どおりに一覧表示されない場合、それが既にコンテナーにバックアップされていないかを確認してください。

    • 名前の同じ複数の VM が、異なるリソース グループに含まれる可能性があります。

      VM 内にある DB の検索中はバックアップが保留される

  4. VM の一覧で、SQL Server データベースを稼働している VM を選択し、>[DB の検出] を選択します。

  5. [通知] でデータベース検出を追跡します。 この操作に必要な時間は、VM のデータベースの数によって異なります。 選択したデータベースが検出されたら、成功のメッセージが表示されます。

    デプロイの成功メッセージ

  6. Azure Backup によって、VM 上のすべての SQL Server データベースが検出されます。 検出中、バックグラウンドで以下の要素が発生します。

    • Azure Backup によって、ワークロード バックアップ用のコンテナーに VM が登録されます。 登録された VM 上のすべてのデータベースは、このコンテナーのみに対してバックアップできます。

    • Azure Backup によって、AzureBackupWindowsWorkload 拡張機能が VM にインストールされます。 エージェントは SQL データベースにインストールされません。

    • Azure Backup によって、サービス アカウント NT Service\AzureWLBackupPluginSvc が VM 上に作成されます。

      • すべてのバックアップおよび復元操作に、サービス アカウントを使用します。
      • NT Service\AzureWLBackupPluginSvc には、SQL sysadmin 権限が必要です。 Marketplace で作成されたすべての SQL Server VM には、SqlIaaSExtension が元からインストールされています。 AzureBackupWindowsWorkload 拡張機能は SQLIaaSExtension を使用して自動的に必要な権限を取得します。

    • VM を Marketplace から作成しなかった場合や、SQL 2008 および 2008 R2 を実行している場合、VM に SqlIaaSExtension がインストールされないことあり、検出操作はエラー メッセージ UserErrorSQLNoSysAdminMembership を示して失敗します。 この問題を修正するには、「VM のアクセス許可を設定する」の手順に従います。

      VM とデータベースを選択する

バックアップの構成

  1. [バックアップの目標]>[手順 2: バックアップの構成] で、 [バックアップの構成] を選択します。

    [バックアップの構成] を選択する

  2. 登録されている可用性グループおよびスタンドアロン SQL Server インスタンスをすべて表示するには、 [リソースの追加] を選択します。

    [リソースの追加] の選択

  3. [バックアップする項目を選択] 画面で、行の左側にある矢印を選択して、そのインスタンスまたは Always On 可用性グループ内の保護されていないデータベースの全一覧を展開します。

    バックアップする項目を選択

  4. 保護したいデータベースをすべて選択してから、 [OK] を選択します。

    データベースの保護

    バックアップの負荷を最適化するために、Azure Backup では、1 つのバックアップ ジョブにおけるデータベースの最大数が 50 個に設定されています。

    • 50 個を超えるデータベースを保護するには、複数のバックアップを構成します。

    • インスタンス全体または AlwaysOn 可用性グループを有効にするには、[AUTOPROTECT](自動保護) ドロップダウン リストで [オン] を選択し、[OK] を選択します。

      Note

      自動保護機能では、既存のすべてのデータベースの保護が一度に有効になるだけでなく、そのインスタンスまたは可用性グループに追加されたすべての新しいデータベースも自動的に保護されます。

  5. [バックアップ ポリシー] を定義します。 次のいずれかの手順を行います。

    • 既定のポリシーを HourlyLogBackup として選択します。

    • SQL 用に以前に作成された既存のバックアップ ポリシーを選択する。

    • RPO とリテンション期間の範囲に基づいて新しいポリシーを定義する。

      [バックアップ ポリシー] を選択する

  6. [バックアップの有効化] を選択して、 [保護を構成] 操作を送信し、ポータルの [通知] 領域で構成の進行状況を追跡します。

    構成の進行状況の追跡

バックアップ ポリシーの作成

バックアップ ポリシーでは、バックアップが取得されるタイミングと、それらが保持される期間を定義します。

  • ポリシーはコンテナー レベルで作成されます。
  • 複数のコンテナーでは同じバックアップ ポリシーを使用できますが、各コンテナーにバックアップ ポリシーを適用する必要があります。
  • バックアップ ポリシーの作成時には、日次での完全バックアップが既定値になっています。
  • 差分バックアップを追加することは可能ですが、週次で実行するように完全バックアップを構成する場合だけです。
  • さまざまな種類のバックアップ ポリシーについて学習してください。

バックアップ ポリシーを作成するには:

  1. [バックアップ センター] に移動し、 [ポリシー] をクリックします。

  2. [データソースの種類] として [Azure VM の SQL Server] を選択し、ポリシーを作成するコンテナーを選択して、 [続行] をクリックします。

    新しいバックアップ ポリシーのポリシーの種類の選択を示すスクリーンショット。

  3. [ポリシー名] に新しいポリシーの名前を入力します。

    ポリシー名の入力を示すスクリーンショット。

  4. 既定の設定を変更するには、 [完全バックアップ] に対応する [編集] リンクを選択します。

    • [バックアップ頻度] を選択します。 [毎日] または [毎週] を選択します。
    • [毎日] を選択する場合は、バックアップ ジョブが開始されるときに、時刻とタイム ゾーンを選択します。 日次の完全バックアップを選択する場合は、差分バックアップを作成できません。

    新しいバックアップ ポリシーのフィールドを示すスクリーンショット。

  5. [リテンション期間] では、すべてのオプションが既定で選択されています。 使用しないリテンション期間の制限を解除してから、使用する間隔を設定します。

    • バックアップのすべての種類 (完全、差分、ログ) の最小リテンション期間は 7 日間です。
    • 復旧ポイントは、そのリテンション期間の範囲に基づいて、リテンション期間に対してタグ付けされます。 たとえば、日次での完全バックアップを選択した場合、日ごとにトリガーされる完全バックアップは 1 回だけです。
    • 特定の曜日のバックアップがタグ付けされ、週次でのリテンション期間の範囲と週次でのリテンション期間の設定に基づいて保持されます。
    • 月次および年次のリテンション期間の範囲でも、同様の動作になります。

    保有期間の範囲の設定を示すスクリーンショット。

  6. [OK] を選択して、完全バックアップの設定を受け入れます。

  7. 既定の設定を変更するには、 [差分バックアップ] に対応する [編集] リンクを選択します。

    • 差分バックアップのポリシーで、 [有効] を選択して頻度とリテンション期間の制御を開きます。
    • 差分バックアップは 1 日に 1 回のみトリガーできます。 完全バックアップと同じ日に差分バックアップをトリガーすることはできません。
    • 差分バックアップは、最大 180 日間保持できます。
    • 差分バックアップの保有期間は、完全バックアップの保有期間よりも長くすることはできません (差分バックアップは復旧時に完全バックアップに依存しているため)。
    • マスター データベースでは、差分バックアップはサポートされていません。

    差分バックアップ ポリシーを示すスクリーンショット。

  8. 既定の設定を変更するには、 [ログ バックアップ] に対応する [編集] リンクを選択します

    • [ログ バックアップ] で、 [有効] を選択して、頻度とリテンション期間の制御を設定します。
    • ログ バックアップは、15 分ごとの頻度で実行でき、最大 35 日間保持することが可能です。
    • データベースが単純復旧モデルである場合、そのデータベースのログ バックアップ スケジュールは一時停止されるため、ログ バックアップはトリガーされません。
    • データベースの復旧モデルが [完全] から [単純] に変更された場合、復旧モデルが変更されてから 24 時間以内にログ バックアップが一時停止されます。 同様に、復旧モデルが [単純] から変更された場合、データベースでログ バックアップがサポートされるようになったので、復旧モデルの変更から 24 時間以内にログ バックアップ スケジュールが有効になります。

    バックアップ ポリシーを示すスクリーンショット。

  9. [バックアップ ポリシー] メニューで、 [SQL バックアップの圧縮] を有効にするかどうかを選択します。 既定では、このオプションは無効になっています。 有効にすると、圧縮されたバックアップストリームが SQL Server によって VDI に送信されます。 Azure Backup は、このコントロールの値に応じて、COMPRESSION / NO_COMPRESSION 句を使用して、インスタンス レベルの既定値をオーバーライドします。

  10. バックアップ ポリシーに対する編集が完了したら、 [OK] を選択します。

Note

各ログ バックアップは、復旧チェーンを形成するために、以前の完全バックアップにチェーンされています。 この完全バックアップは、前回のログ バックアップのリテンション期間が終了するまで保持されます。 これは、完全バックアップのリテンション期間を追加して、すべてのログが確実に復旧されるようにすることを意味します。 週単位の完全、日単位の差分、2 時間ごとのログの各バックアップを実行していると仮定します。 これらのすべてが 30 日間保持されます。 ただし、週単位の完全バックアップは、次の完全バックアップが利用可能になった後でのみ、すなわち 30 + 7 日後に、実際にクリーンアップまたは削除することができます。 たとえば、週単位の完全バックアップが 11 月 16 日に行われたとします。 保持ポリシーに従って、12 月 16 日まで保持されます。 この完全バックアップに対する前回のログ バックアップは、11 月 22 日に予定されている次の完全バックアップの前に行われます。 このログが 12 月 22 日までに利用可能になるまでは、11 月 16 日の完全バックアップは削除されません。 そのため、11 月 16 日の完全バックアップは、12 月 22 日までは保持されます。

自動保護を有効にする

自動保護を有効にして、すべての既存および将来のデータベースを、スタンドアロンの SQL Server インスタンスに、または Always On 可用性グループに自動的にバックアップすることができます。

  • 自動保護のために一度に選択できるデータベースの数に制限はありません。 通常、検出は 8 時間ごとに実行されます。 新しく検出されたデータベースの自動保護は、32 時間以内にトリガーされます。 ただし、 [DB の再検出] オプションを選択することによって検出を手動で実行した場合は、新しいデータベースを直ちに検出して保護できます。
  • 新しく検出されたデータベースに対する自動保護操作が失敗した場合は、3 回再試行されます。 3 回の再試行すべてが失敗した場合、データベースは保護されません。
  • 自動保護を有効化するときに、インスタンス内のデータベースを選んで保護したり保護から除外したりすることはできません。
  • 保護されているデータベースが既にインスタンスに含まれる場合は、自動保護を有効にした後でも、それぞれのポリシーに従って保護されたままです。 後から追加された、保護されていないすべてのデータベースには、自動保護の有効化の時点で定義し、 [バックアップの構成] で一覧に表示される 1 つのポリシーのみが適用されます。 ただし、自動保護データベースに関連付けたポリシーは後から変更できます。
  • 新しく 検出されたデータベース の保護の構成操作が失敗した場合、アラートは発生しません。 ただし、失敗したバックアップ ジョブは、 [バックアップ ジョブ] ページに表示されます。

自動保護を有効にするには:

  1. [Items to backup](バックアップする項目) で、自動保護を有効にしたいインスタンスを選択します。

  2. [AUTOPROTECT](自動保護) の下のドロップダウン リストを選択し、 [ON](オン) を選択してから [OK] を選択します。

    可用性グループで自動保護を有効にする

  3. バックアップはすべてのデータベースに対して一括で構成され、 [バックアップ ジョブ] で追跡できます。

自動保護を無効にする必要がある場合、 [バックアップの構成] のインスタンス名を選択してから、インスタンスについて [自動保護を無効にする] を選択します。 すべてのデータベースは引き続きバックアップされますが、今後のデータベースは自動的に保護されなくなります。

そのインスタンスの自動保護を無効にする

次のステップ

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