長期リテンション - Azure SQL Database と Azure SQL Managed Instance
適用対象: 
Azure SQL データベース Azure SQL Managed Instance
この記事では、Azure SQL データベース と Azure SQL Managed Instance のバックアップの長期保有の概念の概要を説明します。 Azure SQL データベース (Hyperscale サービス レベルを含む) および Azure SQL Managed Instance のバックアップでは、最大 10 年の長期保有を設定できます。
まずは、長期リテンションを構成するには、Azure SQL データベースと Azure SQL Managed Instance の長期バックアップ保持の構成を参照してください。
長期リテンションのしくみ
多くのアプリケーションでは、規制、コンプライアンス、またはその他のビジネス上の理由により、自動バックアップの短期保持期間である 1～35 日を超えてデータベースのバックアップを保持する必要があります。 長期バックアップリテンション期間 (LTR) は、Azure SQL サービスによって自動的に作成されるデータベースの完全バックアップに依存します。 詳細については、Azure SQL データベース または Azure SQL Managed Instance の「自動バックアップ」を参照してください。
LTR 機能を使用すると、指定された完全な SQL Database と SQL Managed Instance のバックアップを、最大で 10 年間、設定可能なアイテム保持ポリシーを持つ Azure Blob Storage に格納することができます。 その後、LTR バックアップを新しいデータベースとして復元できます。 LTR ポリシーが構成されている場合、自動バックアップは、長期ストレージ用に別の BLOB にコピーされます。これを使用してデータベースを特定の時点に回復することができます。 コピーは、データベースのワークロードのパフォーマンスに影響しないバック グラウンド ジョブです。 SQL Database では、各データベースの LTR ポリシーで LTR バックアップを作成する頻度も指定できます。
Note
- 現時点では、Azure SQL データベース と Azure SQL Managed Instance のバックアップを不変として構成することはできません。 LTR バックアップは変更できませんが、Azure portal、Azure CLI、PowerShell、または REST API を使用して削除できます。 詳細については、「LTR バックアップの構成」を参照してください。
- Azure SQL Managed Instance では、SQL Agent ジョブを使用してコピーのみのデータベース バックアップをスケジュールし、独自のストレージ アカウントに保持します。 これは、バックアップを最大 10 年間保持できる LTR 機能の代わりに使用できます。
LTR を有効にするために、ポリシーの定義には、毎週のバックアップ 保持期間 (W)、毎月のバックアップ 保持期間 (M)、毎年のバックアップ 保持期間 (Y)、年度の通算週 (WeekOfYear) の 4 つのパラメーターの組み合わせを使用できます。 W を指定すると、毎週 1 つのバックアップが長期ストレージにコピーされます。 M を指定すると、毎月の最初のバックアップが長期ストレージにコピーされます。 Y を指定すると、WeekOfYear によって指定された週に 1 つのバックアップが長期ストレージにコピーされます。 指定した WeekOfYear がポリシーの構成時点で既に過去である場合、初回の LTR バックアップは次の年に作成されます。 各バックアップは、LTR バックアップの作成時に構成されるポリシー パラメーターに従って、長期ストレージに保持されます。
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 日の後の週)
以下の日付は ISO 8601 (YYYY-MM-DD) に記載されています。
| LTR への PITR バックアップ | 有効期限 W | Expiration M | 有効期限 Y |
|---|---|---|---|
| 2018-03-07 | 2019-03-02 | ||
| 2018-03-14 | 2018-06-06 | ||
| 2018-03-21 | 2018-06-13 | ||
| 2018-03-28 | 2018-06-20 | ||
| 2018-04-04 | 2019-03-30 | ||
| 2018-04-11 | 2018-07-04 | ||
| 2018-04-18 | 2018-07-11 | ||
| 2018-04-25 | 2018-07-18 | ||
| 2018-05-02 | 2019-04-27 | ||
| 2018-05-09 | 2018-08-01 | ||
| 2018-05-16 | 2028-05-13 | ||
| 2018-05-23 | 2018-08-15 | ||
| 2018-05-30 | 2018-08-22 | ||
| 2018-06-06 | 2019-06-01 | ||
| 2018-06-13 | 2018-09-05 | ||
| 2018-06-20 | 2018-09-12 | ||
| 2018-06-27 | 2018-09-19 | ||
| 2018-07-04 | 2019-06-29 | ||
| 2018-07-11 | 2018-10-03 | ||
| 2018-07-18 | 2018-10-10 | ||
| 2018-07-25 | 2018-10-17 | ||
| 2018-08-01 | 2019-07-27 | ||
| 2018-08-08 | 2018-10-31 | ||
| 2018-08-15 | 2018-11-07 | ||
| 2018-08-22 | 2018-11-14 | ||
| 2018-08-29 | 2018-11-21 |
上記のポリシーを変更し、W=0 (週単位のバックアップなし) を設定した場合、サービスは毎月および毎年のバックアップのみを保有します。 LTR ポリシーでは、毎週のバックアップは保存されません。 それに応じて、これらのバックアップの保持に必要なストレージ容量は減ります。
重要
個々 の LTR バックアップのタイミングは、Azure SQL Database によって制御されます。 手動で LTR バックアップを作成またはバックアップの作成タイミングを制御することはできません。 LTR ポリシーを構成した後、最初の LTR バックアップが利用可能なバックアップのリストに表示されるまで、最大 7 日かかる場合があります。
論理サーバーまたはマネージド インスタンスを削除すると、そのサーバーまたはマネージド インスタンス上のすべてのデータベースも削除され、復旧できなくなります。 削除されたサーバーまたはマネージド インスタンスは復元できません。 ただし、データベースまたはマネージド インスタンスに対して LTR を構成していた場合、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 保有期間の最後の 7 日間に復元リクエストが開始されると、Azure では、復元中に LTR バックアップの有効期限が切れないように、すべてのバックアップの有効期限が自動的に 7 日延長されます。
Note
コンプライアンスやその他のミッション クリティカルな要件を満たすために LTR バックアップを使っている場合、LTR バックアップが復元できることと、復元の結果が想定したデータベース状態になることを検証するために、定期的な復元訓練を適用することを検討してください。
関連するコンテンツ
データベース バックアップは、データの不慮の破損または削除から保護するため、ビジネス継続性およびディザスター リカバリー戦略の最も重要な部分です。
- Azure SQL Database のビジネス継続性の概要
- Azure SQL Managed Instance のビジネス継続性の概要
- Azure SQL Database の自動バックアップ
- Azure SQL Managed Instance での自動バックアップ
LTR バックアップの構成と管理に関するチュートリアルについては、以下を参照してください。