Applies to:
Azure SQL DatabaseAzure SQL Managed Instance
この記事では、Azure SQL DatabaseとAzure SQL Managed Instanceの長期保有 (LTR) バックアップの概念的な概要について説明します。 長期保有期間は、Azure SQL Database (Hyperscale サービス レベルを含む) とAzure SQL Managed Instanceのバックアップで最大 10 年間構成できます。
長期保有バックアップ機能の使用を開始するには、次を参照してください。
長期リテンションのしくみ
多くのアプリケーションでは、規制、コンプライアンス、またはその他のビジネス上の理由により、自動バックアップの短期保持期間である 1～35 日を超えてデータベースのバックアップを保持する必要があります。 長期バックアップリテンション期間 (LTR) は、Azure SQL サービスによって自動的に作成されるデータベースの完全バックアップに依存します。 詳細については、「
LTR 機能を使用すると、最大 10 年間の構成可能な保持ポリシーを使用して、指定された完全な SQL Database とSQL Managed Instanceバックアップを冗長Azure Blob Storage に格納できます。 その後、LTR バックアップを新しいデータベースとして復元できます。 LTR ポリシーが構成されている場合、自動バックアップは、長期ストレージ用に別の BLOB にコピーされます。これを使用してデータベースを特定の時点に回復することができます。 コピー プロセスは、データベース ワークロードにパフォーマンスに影響しないバックグラウンド ジョブです。 各データベースの LTR ポリシーでは、LTR バックアップの作成頻度を指定することもできます。
注
現在プレビュー段階にある機能である不変としてAzure SQL Databaseの長期保有バックアップを構成できます。
現在、Azure SQL Managed Instanceのバックアップを immutable として構成することはできません。 LTR バックアップは変更できませんが、Azureポータル、Azure CLI、PowerShell、または REST API を使用して削除できます。 Azure SQL Managed Instanceの回避策として、コピーのみのデータベース バックアップを作成し、変更できないファイルとして独自のAzure Storage アカウントに保持できます。
LTR を有効にするために、ポリシーの定義には、毎週のバックアップ 保持期間 (W)、毎月のバックアップ 保持期間 (M)、毎年のバックアップ 保持期間 (Y)、年度の通算週 (WeekOfYear) の 4 つのパラメーターの組み合わせを使用できます。 W を指定すると、毎週 1 つのバックアップが長期ストレージにコピーされます。 M を指定すると、毎月の最初のバックアップが長期ストレージにコピーされます。 Y を指定すると、WeekOfYear によって指定された週に 1 つのバックアップが長期ストレージにコピーされます。 指定した WeekOfYear がポリシーの構成時点で既に過去である場合、初回の LTR バックアップは次の年に作成されます。 各バックアップは、LTR バックアップの作成時に構成されるポリシー パラメーターに従って、長期ストレージに保持されます。
LTR ポリシーの変更は、将来のバックアップにのみ適用されます。 たとえば、週単位のバックアップリテンション期間 (W)、毎月のバックアップリテンション期間 (M)、毎年のバックアップリテンション期間 (Y) を変更した場合、新しい保持設定は新しいバックアップにのみ適用されます。 既存のバックアップのリテンション期間は変更されません。 LTR ポリシーは、Azure SQL DatabaseおよびAzure SQL Managed Instanceの各データベースに対して構成できます。 保有期間が経過する前に古い LTR バックアップを削除する場合は、 バックアップを手動で削除できます。
注
Azure SQL DatabaseとAzure SQL Managed Instanceの両方で、データベースに対して初めて LTR ポリシーを有効にすると、ポイントインタイム リストア (PITR) からの最新の完全バックアップが長期ストレージにコピーされます。
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 (3,650 日)、 WeekOfYear=20 (5 月 13 日の後の週)
以下の日付は ISO 8601 (YYYY-MM-DD) に記載されています。
| LTR への PITR バックアップ | 有効期限 W | 有効期限 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年4月4日 | 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 バックアップのタイミングは、Microsoft によって制御されます。 手動で LTR バックアップを作成またはバックアップの作成タイミングを制御することはできません。 LTR ポリシーを構成した後、使用可能なバックアップの一覧に最初の LTR バックアップが表示されるまでに最大 7 日かかる場合があります。
論理サーバーまたは SQL マネージド インスタンスを削除すると、そのサーバーまたはマネージド インスタンス上のすべてのデータベースも削除されます。 削除された論理サーバーまたは SQL マネージド インスタンスを復元することはできません。 ただし、データベースに対して LTR を構成した場合、LTR バックアップは削除されず、LTR バックアップが作成された時点まで、同じサブスクリプション内の別のサーバーまたはマネージド インスタンスにデータベースを復元するために使用できます。
同様に、データベースを削除した場合、LTR バックアップは削除されず、構成された保有期間にわたって保持されます。 これらのバックアップは、同じサーバーまたは同じサブスクリプション内の別のサーバーに復元できます。
ジオレプリケーションと長期のバックアップ保持期間
アクティブ geo レプリケーションまたはフェールオーバー グループをビジネス継続性ソリューションとして使用している場合は、最終的なフェールオーバーを準備し、プライマリと同じ LTR ポリシーをセカンダリ データベースまたはインスタンスで構成します。 バックアップはセカンダリから生成されないため、LTR ストレージ コストは増加しません。 バックアップは、フェールオーバーがトリガーされ、プライマリがセカンダリ リージョンに移動したときに LTR バックアップが中断されずに生成されるようにするために、セカンダリがプライマリになった後にのみ作成されます。
元のプライマリ データベースがフェールオーバーの原因となった障害から復旧すると、新しいセカンダリになります。 そのため、新しいセカンダリでバックアップの作成は再開されません。既存の LTR ポリシーは、再びプライマリになるまで有効になりません。
長期バックアップの保持期間を構成する
Azure SQL DatabaseとAzure SQL Managed InstanceのAzure ポータルと PowerShell を使用して、長期的なバックアップ保有期間を構成できます。 LTR ストレージからデータベースを復元するために、特定のバックアップを、そのタイムスタンプに基づいて選択することができます。 データベースは、元のデータベースと 同じサブスクリプションの既存の サーバーまたはマネージド インスタンスに復元できます。 復元機能、制限事項、特徴の完全な一覧については、Azure SQL Managed Instance の復元機能と特徴を参照してください。
LTR リテンション期間の最後の 7 日間に復元要求が開始されると、LTR バックアップは、リテンション期間の有効期限が切れた場合でも、復元操作が完了した後にのみ削除されます。
Azure SQL Managed Instanceでは、SQL エージェント ジョブを使用して、コピー専用データベース バックアップをスケジュールし、代わりに独自のストレージ アカウントに移動できます。
- バックアップを 10 年以上保持します。
- データベースの毎日のコピーを 35 日以上保持します。
- 不変ストレージにデータベース バックアップを格納します。
ヒント
LTR バックアップを使用してコンプライアンスまたはその他のミッション クリティカルな要件を満たしている場合は、定期的な復旧訓練を実施して、LTR バックアップを復元できること、および復元の結果が予想されるデータベース状態であることを確認することを検討してください。
次のステップ
関連するコンテンツ
データベース バックアップは、データの不慮の破損または削除から保護するため、ビジネス継続性およびディザスター リカバリー戦略の最も重要な部分です。
Azure SQL Database Azure SQL Managed Instance - Azure SQL Database の自動バックアップ
- Azure SQL Managed Instance の自動バックアップ