Stretch 対応データベースのバックアップ (Stretch Database)

[アーティクル]
06/02/2023

適用対象: SQL Server 2016 (13.x) 以降 - Windows のみ

重要

拡張データベースは、SQL Server 2022 (16.x) および Azure SQL Database では非推奨になります。この機能は、データベースエンジンの将来のバージョンで削除される予定です。新規の開発作業ではこの機能を使用しないようにし、現在この機能を使用しているアプリケーションは修正することを検討してください。

データベースのバックアップは、さまざまな種類の障害、エラー、災害から回復するのに役立ちます。

Stretch 対応の SQL Server データベースをバックアップする必要があります。
Microsoft Azure では、Stretch Database が SQL Server から Azure に移行したリモートデータを自動的にバックアップします。

バックアップは、完全な高可用性とビジネス継続性ソリューションの一部にすぎません。高可用性についての詳細は、「高可用性ソリューション」を参照してください。

SQL Server データのバックアップ

Stretch 対応の SQL Server データベースをバックアップするには、現在使用している SQL Server のバックアップ方法を引き続き使用できます。詳細については、「 SQL Server データベースのバックアップと復元」を参照してください。

Stretch 対応の SQL Server データベースのバックアップには、ローカルデータと、バックアップを実行した時点での移行対象データのみが含まれています (対象データとは、まだ移動されていないが、テーブルの移行設定に基づいて Azure に移行される予定のデータです)。これは浅いバックアップと呼ばれ、既に Azure に移行されたデータは含まれません。

リモートの Azure データのバックアップ

Microsoft Azure では、Stretch Database が SQL Server から Azure に移行したリモートデータを自動的にバックアップします。

Azure は自動バックアップによりデータ消失のリスクを軽減

Azure の SQL Server Stretch Database サービスは、少なくとも 8 時間ごとの自動ストレージのスナップショットにより、リモートデータベースを保護します。復元ポイントを幅広く提供するため、各スナップショットを 7 日間保持します。

Azure は地理冗長によりデータ損失のリスクを軽減

Azure のデータベースバックアップは、地理冗長の Azure Storage (RA-GRS) に格納されるため、既定で地理冗長になっています。地理冗長ストレージは、プライマリリージョンから数百マイル離れたセカンダリリージョンにデータをレプリケートします。プライマリリージョンとセカンダリリージョンの両方で、データは別々のフォールトドメインとアップグレードドメイン間でそれぞれ 3 回レプリケートされます。これにより、いずれかの Azure リージョンが利用不能状態になるような局所的な停電や災害が発生した場合でも、データの持続性が保証されます。

Stretch Database は、移行済みの行を一時的に保持することで、Azure データのデータ損失リスクを軽減

Stretch Database は SQL Server から Azure に対象となる行を移行した後、これらの行をステージングテーブルに 8 時間以上保持します。 Azure データベースのバックアップを復元する場合、Stretch Database はステージングテーブルに保存されている行を使用して、SQL Server と Azure データベースを調整します。

Azure データのバックアップを復元した後に、ストアドプロシージャ sys.sp_rda_reauthorize_db を実行して、Stretch 対応の SQL Server データベースをリモートの Azure データベースに再接続する必要があります。 sys.sp_rda_reauthorize_dbを実行すると、Stretch Database は SQL Server と Azure データベースを自動的に調整します。

Stretch Database がステージングテーブルに移行したデータを一時的に保持する時間を増やすには、ストアドプロシージャ sys.sp_rda_set_rpo_duration を実行し、8 より大きい値を時間に指定します。保持するデータの量を決定するには、次の要因を検討します。

Azure の自動バックアップの頻度 (少なくとも 8 時間ごと)。
問題が発生してから、それを認識してバックアップを復元することを決定するまでに必要な時間。
Azure の復元操作の期間。

Note

Stretch Database がステージングテーブルに一時的に保持するデータの量を増やすと、SQL Server 上で必要な領域の量も増加します。

Stretch Database がステージングテーブルに一時的に保持している時間を確認するには、ストアドプロシージャ sys.sp_rda_get_rpo_durationを実行します。