長期リテンション - Azure SQL Database と Azure SQL Managed Instance

多くのアプリケーションで、規制、コンプライアンス、またはその他のビジネス上の目的で、Azure SQL Database と Azure SQL Managed Instance の自動バックアップによって提供される 7 ~ 35 日間を超えて、データベースのバックアップを保持する必要があります。 長期保有 (LTR) 機能を使用すると、指定された SQL Database と SQL Managed Instance の完全バックアップを、最大で 10 年間、冗長性を設定して Azure Blob Storage に格納することができます。 その後、LTR バックアップを新しいデータベースとして復元できます。

長期リテンションは Azure SQL Database と Azure SQL Managed Instance に対して有効にできます。 この記事では、長期リテンションの概念の概要を説明します。 長期リテンションを構成するには、Azure SQL Database LTR の構成Azure SQL Managed Instance LTR の構成に関するページを参照してください。

Note

  • Azure SQL Managed Instance で、SQL Agent ジョブを使って、LTR の代替手段として、35 日間を超えるコピーのみのデータベース バックアップをスケジュールします。
  • Hyperscale データベースの長期バックアップ保持期間がプレビュー段階になりました。

長期リテンションのしくみ

バックアップの長期保有 (LTR) では、ポイントインタイム リストア (PITR) を有効にするために自動的に作成される完全なデータベース バックアップが利用されます。 LTR ポリシーが構成されている場合、これらのバックアップは長期保存用に異なるストレージ BLOB にコピーされます。 コピーは、データベースのワークロードのパフォーマンスに影響しないバック グラウンド ジョブです。 SQL Database では、各データベースの LTR ポリシーで LTR バックアップを作成する頻度も指定できます。

LTR を有効にするために、ポリシーの定義には、毎週のバックアップ リテンション期間 (W)、毎月のバックアップ リテンション期間 (M)、毎年のバックアップ リテンション期間 (Y)、年度の通算週 (WeekOfYear) の 4 つのパラメーターの組み合わせを使用できます。 W を指定すると、毎週 1 つのバックアップが長期ストレージにコピーされます。 M を指定すると、毎月の最初のバックアップが長期ストレージにコピーされます。 Y を指定すると、WeekOfYear によって指定された週に 1 つのバックアップが長期ストレージにコピーされます。 指定した WeekOfYear がポリシーの構成時点で既に過去である場合、初回の LTR バックアップは次の年に作成されます。 各バックアップは、LTR バックアップの作成時に構成されるポリシー パラメーターに従って、長期ストレージに保持されます。

Note

LTR ポリシーへの変更内容は、今後のバックアップにのみ適用されます。 たとえば、毎週のバックアップ リテンション期間 (W)、毎月のバックアップ リテンション期間 (M)、または毎年のバックアップ リテンション期間 (Y) が変更された場合、新しいリテンション期間の設定は新しいバックアップにのみ適用されます。 既存のバックアップのリテンション期間は変更されません。 リテンション期間の期限が切れる前に古い LTR バックアップを削除したい場合は、バックアップを手動で削除する必要があります。

LTR ポリシーの例:

  • W=0、M=0、Y=5、WeekOfYear=3

    毎年、第 3 週の完全バックアップが 5 年間保持されます。

  • W=0、M=3、Y=0

    毎月、最初の完全バックアップが 3 か月間保持されます。

  • W=12、M=0、Y=0

    毎週、完全バックアップが 12 週間保持されます。

  • W=6、M=12、Y=10、WeekOfYear=20

    毎週、完全バックアップが 6 週間保持されます。 ただし、各月の最初の完全バックアップについては、12 か月間保持されます。 また、各年の第 20 週に作成された完全バックアップについては、10 年間保持されます。

以下の表は、次のポリシーの長期バックアップの周期と有効期限を示しています。

W=12 weeks (84 日)、M=12 months (365 日)、Y=10 years (3650 日)、WeekOfYear=20 (5 月 13 日の週)

LTR の例

上記のポリシーを変更し、W =0 (週単位のバックアップなし) を設定した場合、Azure は毎月および毎年のバックアップのみを保持します。 LTR ポリシーでは、毎週のバックアップは保存されません。 それに応じて、これらのバックアップの保持に必要なストレージ容量は減ります。

重要

個々の LTR バックアップのタイミングは、Azure によって制御されます。 手動で LTR バックアップを作成またはバックアップの作成タイミングを制御することはできません。 LTR ポリシーを構成した後、最初の LTR バックアップが利用可能なバックアップの一覧に表示されるまで、最大 7 日かかる場合があります。

サーバーまたはマネージド インスタンスを削除すると、そのサーバーまたはマネージド インスタンス上のすべてのデータベースも削除され、復旧できなくなります。 削除されたサーバーまたはマネージド インスタンスは復元できません。 ただし、データベースまたはマネージド インスタンスに対して LTR を構成していた場合、LTR バックアップは削除されず、同じサブスクリプション内の異なるサーバーまたはマネージド インスタンスのデータベースを、LTR バックアップが作成された特定の時点まで復元するために使用できます。

geo レプリケーションと長期のバックアップ リテンション期間

ビジネス継続性のソリューションとしてアクティブ geo レプリケーションやフェールオーバー グループを使用している場合、最終的なフェールオーバーを準備して、セカンダリ データベースまたはインスタンス上に同じ LTR ポリシーを構成する必要があります。 バックアップがセカンダリから生成されないときに、LTR ストレージのコストが増加することはありません。 バックアップは、セカンダリがプライマリになった場合にのみ作成されます。 フェールオーバーがトリガーされ、プライマリがセカンダリ リージョンに移動するときに、LTR バックアップの中断されない生成が保証されます。

Note

元のプライマリ データベースをフェールオーバーの原因となる停止から回復させると、これが新しいセカンダリになります。 したがって、バックアップの作成は再開することなく、既存の LTR ポリシーは、もう一度プライマリになるまで反映されることはありません。

長期のバックアップ リテンション期間の構成

Azure SQL Database には Azure portal を使用し、Azure SQL Managed Instance には PowerShell を使用して、長期のバックアップ リテンション期間を構成できます。 LTR ストレージからデータベースを復元するために、特定のバックアップを、そのタイムスタンプに基づいて選択することができます。 データベースは、元のデータベースと同じサブスクリプションの既存のサーバーまたはマネージド インスタンスに復元できます。

Azure portal または PowerShell を使用して、長期のリテンション期間を構成したり、SQL Database のバックアップからデータベースを復元したりする方法については、「Azure SQL Database の長期的なバックアップ保有期間を管理する」を参照してください。

Azure portal または PowerShell を使用して、長期保有を構成したり、SQL Managed Instance のバックアップからデータベースを復元したりする方法については、「Azure SQL Managed Instance の長期的なバックアップ保有期間を管理する」を参照してください。

注意

コンプライアンスやその他のミッションクリティカルな要件を満たすために LTR バックアップを使っている場合、LTR バックアップが復元できることと、復元の結果が想定したデータベース状態になることを検証するために、定期的な復元訓練を実施することを検討してください。

次のステップ

データベース バックアップは、データの不慮の破損または削除から保護するため、ビジネス継続性およびディザスター リカバリー戦略の最も重要な部分です。

  • その他の SQL Database ビジネス継続性ソリューションの概要については、ビジネス継続性の概要に関する記事を参照してください。
  • サービスによって生成された自動バックアップについては、自動バックアップに関する記事を参照してください。