Stretch 対応データベースのバックアップ (Stretch Database)
適用対象: 
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を実行します。