次の方法で共有


可用性グループに対する Azure への SQL Server マネージド バックアップの設定

このトピックでは、AlwaysOn 可用性グループに参加しているデータベース用に Microsoft Azure へのマネージド バックアップSQL Server構成する方法に関するチュートリアルです。

可用性グループの構成

SQL Server Microsoft Azure へのマネージド バックアップは、可用性グループ データベース、レプリカがすべてオンプレミスまたは完全に Azure で構成されているかどうか、またはオンプレミスと 1 つ以上の Azure 仮想マシンの間のハイブリッド実装に対してサポートされます。 ただし、1 つ以上の実装に関して、次のことを考慮する必要が生じる可能性があります。

  • ログ バックアップ頻度: ログ バックアップ頻度に応じて、時間とログの両方が増加します。 たとえば、2 時間という期間で使用されるログ領域が 5 MB に達しない場合は、2 時間ごとにログ バックアップを作成するとします。 この方針を、内部設置型、クラウド、またはハイブリッドというすべての実装に適用します。

  • ネットワーク帯域幅: これは、レプリカが異なる物理的な場所 (ハイブリッド クラウドなど)、またはクラウドのみの構成内の異なる Azure リージョン間に配置されている実装に適用されます。 ネットワーク帯域幅は、セカンダリの待機時間に影響する可能性があります。セカンダリが同期レプリケーションに設定されている場合は、プライマリ ログの増加が引き起こされる可能性があります。 セカンダリ レプリカが同期レプリケーションに設定されている場合は、ネットワーク待機時間が原因でセカンダリは同期を維持できない可能性があり、その結果、セカンダリ レプリカへのフェールオーバー イベントが発生したときにデータが失われる可能性があります。

可用性データベースSQL Server Microsoft Azure へのマネージド バックアップの構成。

アクセス許可:

  • ALTER ANY CREDENTIAL アクセス許可とストアド プロシージャに対するアクセス許可EXECUTEdb_backupoperatorデータベース ロールのメンバーシップsp_delete_backuphistory必要です。

  • smart_admin.fn_get_current_xevent_settings関数に対する SELECT アクセス許可が必要です。

  • smart_admin.sp_get_backup_diagnostics ストアド プロシージャに対するアクセス許可が必要EXECUTEです。 さらに、VIEW SERVER STATE 権限も必要です (この権限を必要とする他のシステム オブジェクトを内部的に呼び出すため)。

  • および smart_admin.sp_backup_master_switch ストアド プロシージャに対するsmart_admin.sp_set_instance_backupアクセス許可が必要EXECUTEです。

Microsoft Azure へのマネージド バックアップを使用して AlwaysOn 可用性グループSQL Server設定する基本的な手順を次に示します。 詳細手順のチュートリアルについては、このトピックの後半で説明します。

  1. 可用性グループを作成したら、優先されるバックアップ レプリカを構成します。 可用性グループのこの設定は、Microsoft Azure へのマネージド バックアップSQL Serverによっても使用され、バックアップに使用するレプリカを決定します。 バックアップ設定を設定する手順については、「可用性レプリカでのバックアップの構成 (SQL Server)」を参照してください。 新しい AlwaysOn 可用性グループを作成する場合は、「AlwaysOn 可用性グループを使用したはじめに (SQL Server)」を参照してください。

  2. セカンダリ レプリカへの読み取り専用接続アクセスを構成します。 読み取り専用アクセスを構成する手順については、「可用性レプリカでのRead-Only アクセスの構成 (SQL Server)」を参照してください。

  3. バックアップ レプリカを指定します。 推奨されるバックアップ レプリカ設定は、Microsoft Azure へのマネージド バックアップSQL Server使用して、バックアップのスケジュール設定に使用するデータベースを決定します。 現在のレプリカが優先バックアップ レプリカであるかどうかを判断するには、 sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) 関数を使用します。

  4. 各レプリカで、スマート admin.sp_set_db_backup ストアド プロシージャを使用して、データベースの Microsoft Azure へのマネージド バックアップ構成SQL Server実行します。

    フェールオーバー後の Microsoft Azure へのマネージド バックアップの動作をSQL Serverする: Microsoft Azure へのマネージド バックアップSQL Serverは、フェールオーバー イベント後も引き続き機能し、バックアップ コピーと回復性を維持します。 フェールオーバー後に特別な操作は必要ありません。

注意点と要件:

AlwaysOn 可用性グループに参加しているデータベースに対して Microsoft Azure へのマネージド バックアップSQL Server構成するには、特定の考慮事項と要件が必要です。 考慮事項と要件の一覧を次に示します。

  • Microsoft Azure へのマネージド バックアップSQL Server構成設定は、同じ可用性グループに参加SQL Serverのすべてのノード上のすべてのデータベースで同じである必要があります。 これを実現するには、プライマリとデータベース レベルのすべてのレプリカに対して同じSQL Serverマネージド バックアップを Microsoft Azure 構成に設定するか、可用性グループに参加しているすべてのノードで同じ既定の SQL Server マネージド バックアップを Microsoft Azure 設定に設定します。 データベース レベルで Microsoft Azure SQL Server Managed Backup を構成すると、データベースに設定を分離し、既定の設定を変更するとインスタンス上の他のすべてのデータベースに影響するため、データベースで Microsoft Azure にマネージド バックアップをSQL Server設定することをお勧めします。

  • バックアップ レプリカを指定します。 推奨されるバックアップ レプリカ設定は、Microsoft Azure へのマネージド バックアップSQL Serverバックアップをスケジュールするために使用されます。 現在のレプリカが優先バックアップ レプリカであるかどうかを判断するには、 sys.fn_hadr_backup_is_preferred_replica (Transact-SQL) 関数を使用します。

  • 優先されるレプリカとしてセカンダリ レプリカが構成されている場合は、少なくとも読み取り専用接続アクセスを持つように構成する必要があります。 セカンダリ データベースへの接続アクセスがない可用性グループはサポートされません。 詳細については、可用性レプリカへの読み取り専用アクセスの構成 (SQL Server) に関するページを参照してください。

  • 可用性グループSQL Server構成した後に Microsoft Azure へのマネージド バックアップを構成する場合、Microsoft Azure へのマネージド バックアップSQL Server、既存のバックアップベースのコピーとストレージ コンテナーへのコピーが試行されます。 Microsoft Azure へのマネージド バックアップSQL Server、既存のバックアップを検索またはアクセスできない場合は、データベースの完全バックアップがスケジュールされます。 この処理は、特に、可用性グループのデータベースのバックアップ操作を最適化するために行われます。

  • 新しい可用性データベースを作成していて、インスタンス レベルの設定をデータベースに適用しない場合は、インスタンス レベルの設定を無効にすることを検討してください

  • 暗号化を使用する場合は、すべてのレプリカで同じ証明書を使用します。 この結果、フェールオーバー イベントが発生した場合や、別のレプリカへの復元を行う場合に、継続的で途切れることのないバックアップ操作が容易になります。

可用性データベースSQL Server Microsoft Azure へのマネージド バックアップを有効にして構成する

このチュートリアルでは、コンピューター Node1 と Node2 上のデータベース (AGTestDB) に対して Microsoft Azure へのマネージド バックアップSQL Server有効にして構成する手順について説明します。その後、Microsoft Azure の正常性状態へのSQL Serverマネージド バックアップの監視を有効にする手順について説明します。

  1. Azure ストレージ アカウントを作成します。 バックアップは Azure Blob Storage サービスに格納されます。 Azure ストレージ アカウントがまだない場合は、最初に作成する必要があります。 詳細については、「 Azure ストレージ アカウントの作成」を参照してください。 ストレージ アカウントの名前、アクセス キー、および URL をメモしておきます。 ストレージ アカウント名およびアクセス キー情報は、SQL 資格情報の作成に使用します。 SQL 資格情報は、バックアップ操作中に Microsoft Azure へのマネージド バックアップSQL Serverによって使用され、ストレージ アカウントに対する認証が行われます。

  2. SQL 資格情報を作成します。 ストレージ アカウントの名前を ID として、ストレージ アクセス キーをパスワードとして使用して、SQL 資格情報を作成します。

  3. SQL Server エージェント サービスが開始され、実行されていることを確認する: SQL Server エージェントを開始します (現在実行されていない場合)。 Microsoft Azure への SQL Server マネージド バックアップ でバックアップ操作を実行するには、SQL Server エージェントがインスタンスで実行されている必要があります。 バックアップ操作を定期的に実行できるように、SQL エージェントの自動的な実行を設定できます。

  4. 保持期間を決定します。 バックアップ ファイルに必要な保持期間を決定します。 保有期間は日数で指定し、その範囲は 1 ~ 30 になります。 保持期間によって、データベースの回復可能性期間が決まります。

  5. バックアップ中に暗号化に使用する証明書または非対称キーを作成します 。最初のノード Node1 に証明書を作成し、 BACKUP CERTIFICATE (Transact-SQL) を使用してファイルにエクスポートします。 Node 2 で、Node 1 からエクスポートしたファイルを使用して証明書を作成します。 ファイルから証明書を作成する方法の詳細については、「 CREATE CERTIFICATE (Transact-SQL)」の例を参照してください。

  6. Node1 上SQL Server AGTestDB 用 Microsoft Azure へのマネージド バックアップを有効にして構成する: SQL Server Management Studioを開始し、可用性データベースがインストールされている Node1 上のインスタンスに接続します。 要件に合わせて、データベース名、ストレージ URL、SQL 資格情報、および保有期間の値を変更した後、クエリ ウィンドウから次のステートメントを実行します。

    Use msdb;  
    GO  
    EXEC smart_admin.sp_set_db_backup   
                    @database_name='AGTestDB'   
                    ,@retention_days=30   
                    ,@credential_name='MyCredential'  
                    ,@encryption_algorithm ='AES_128'  
                    ,@encryptor_type= 'Certificate'  
                    ,@encryptor_name='MyBackupCert'  
                    ,@enable_backup=1;  
    GO  
    

    暗号化用の証明書の作成の詳細については、「暗号化されたバックアップを作成する」の 「バックアップ証明書 の作成」の手順 参照してください。

  7. Node2 で Microsoft Azure for AGTestDB へのマネージド バックアップSQL Server有効にして構成する: SQL Server Management Studioを開始し、可用性データベースがインストールされている Node2 上のインスタンスに接続します。 要件に合わせて、データベース名、ストレージ URL、SQL 資格情報、および保有期間の値を変更した後、クエリ ウィンドウから次のステートメントを実行します。

    Use msdb;  
    GO  
    EXEC smart_admin.sp_set_db_backup   
                    @database_name='AGTestDB'   
                    ,@retention_days=30   
                    ,@credential_name='MyCredential'  
                    ,@encryption_algorithm ='AES_128'  
                    ,@encryptor_type= 'Certificate'  
                    ,@encryptor_name='MyBackupCert'  
                    ,@enable_backup=1;  
    GO  
    

    Microsoft Azure への SQL Server マネージド バックアップ は、指定したデータベースで有効になります。 データベースでのバックアップ操作の実行が開始されるまで最大 15 分かかる場合があります。 バックアップは、優先されるバックアップ レプリカに対して実行されます。

  8. 拡張イベントの既定の構成を確認します。Microsoft Azure へのマネージド バックアップを使用してバックアップをスケジュールするレプリカで次の transact-SQL ステートメントSQL Server実行して、拡張イベントの構成を確認します。 これは、通常、データベースが属している可用性グループの優先されるバックアップ レプリカの設定です。

    SELECT * FROM smart_admin.fn_get_current_xevent_settings(); 
    

    管理、操作チャネル、分析チャネル イベントが既定で有効になっており、無効にできないことがわかります。 手動の介入を必要とするイベントを監視するには、これで十分です。 デバッグ イベントは有効にできますが、これらのチャネルには、Microsoft Azure へのマネージド バックアップSQL Serverが問題を検出して解決するために使用する情報イベントとデバッグ イベントが含まれます。 詳細については、「Azure へのマネージド バックアップSQL Server監視する」を参照してください。

  9. 正常性状態の通知を有効化し、構成する: Microsoft Azure への SQL Server マネージド バックアップMicrosoft Azure への SQL Server マネージド バックアップには、注意を要するエラーまたは警告の電子メール通知を送信するためにエージェント ジョブを作成するストアド プロシージャがあります。 このような通知を受信するには、SQL Server エージェント ジョブを作成するストアド プロシージャの実行を有効にする必要があります。 次の手順では、電子メール通知を有効にして構成するためのプロセスを示します。

    1. データベース メールがインスタンス上でまだ有効になっていない場合は設定します。 詳細については、「 Configure Database Mail」を参照してください。

    2. データベース メールを使用するように SQL Server エージェント通知を構成します。 詳細については、「 Configure SQL Server Agent Mail to Use Database Mail」を参照してください。

    3. 電子メール通知を有効にして、バックアップ エラーおよび警告を受け取る: クエリ ウィンドウから、次の Transact-SQL ステートメントを実行します。

      EXEC msdb.smart_admin.sp_set_parameter  
      @parameter_name = 'SSMBackup2WANotificationEmailIds',  
      @parameter_value = '<email>'  
      

      詳細と完全なサンプル スクリプトについては、「Azure へのマネージド バックアップSQL Server監視する」を参照してください。

  10. Azure ストレージ アカウントでバックアップ ファイルを表示します。SQL Server Management Studioまたは Azure 管理ポータルからストレージ アカウントに接続します。 Microsoft Azure へのマネージド バックアップを使用するように構成したデータベースをホストするSQL ServerのインスタンスSQL Serverコンテナーが表示されます。 データベースに対して Microsoft Azure へのマネージド バックアップSQL Server有効にしてから 15 分以内に、データベースとログ バックアップが表示される場合もあります。

  11. 正常性状態を監視します。 以前に構成した電子メール通知を使用して監視することも、ログに記録されたイベントをアクティブに監視することもできます。 イベントを表示するための Transact-SQL ステートメントのいくつかの例を示します。

    --  view all admin events  
    Use msdb;  
    Go  
    DECLARE @startofweek datetime  
    DECLARE @endofweek datetime  
    SET @startofweek = DATEADD(Day, 1-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP)   
    SET @endofweek = DATEADD(Day, 7-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP)  
    
    DECLARE @eventresult TABLE  
    (event_type nvarchar(512),  
    event varchar (512),  
    timestamp datetime  
    )  
    
    INSERT INTO @eventresult  
    
    EXEC smart_admin.sp_get_backup_diagnostics @begin_time = @startofweek, @end_time = @endofweek  
    
    SELECT * from @eventresult  
    WHERE event_type LIKE '%admin%'  
    
    -- to enable debug events  
    Use msdb;  
    Go  
    EXEC smart_admin.sp_set_parameter 'FileRetentionDebugXevent', 'True'  
    
    --  View all events in the current week  
    Use msdb;  
    Go  
    DECLARE @startofweek datetime  
    DECLARE @endofweek datetime  
    SET @startofweek = DATEADD(Day, 1-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP)   
    SET @endofweek = DATEADD(Day, 7-DATEPART(WEEKDAY, CURRENT_TIMESTAMP), CURRENT_TIMESTAMP)  
    
    EXEC smart_admin.sp_get_backup_diagnostics @begin_time = @startofweek, @end_time = @endofweek;  
    

このセクションで説明した手順は、データベースで初めて Microsoft Azure への SQL Server マネージド バックアップ を構成するための特別な手順です。 同じシステム ストアド プロシージャ smart_admin.sp_set_db_backup を使用して既存の構成を変更し、新しい値を指定できます。 詳細については、「Azure へのマネージド バックアップのSQL Server - 保持とストレージの設定」を参照してください

AlwaysOn 可用性グループの構成からデータベースを削除する際の注意点

AlwaysOn 可用性グループ構成からデータベースが削除され、スタンドアロン データベースになった場合は、 smart_admin.sp_backup_on_demand (Transact-SQL) を使用してバックアップを実行することをお勧めします。 この方法でデータベース バックアップを作成すると、新しいバックアップ チェーンが確立され、データベースが可用性グループの一部であったときにバックアップが格納された可用性コンテナーとは対照的に、ファイルはインスタンス固有のコンテナーに配置されます。

警告

このシナリオのデータベースについては、可用性グループの状態が変更される前のバックアップからの復旧性は保証されません。