適用対象:
Azure SQL データベースAzure 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 サービスによって自動的に作成されるデータベースの完全バックアップに依存します。 詳細については、「 Azure SQL Database での自動バックアップ 」または「 Azure SQL Managed Instance での自動バックアップ」を参照してください。
LTR 機能を使用すると、指定された完全な SQL Database と SQL Managed Instance のバックアップを、最大で 10 年間、設定可能なアイテム保持ポリシーを持つ Azure Blob Storage に格納することができます。 その後、LTR バックアップを新しいデータベースとして復元できます。 LTR ポリシーが構成されている場合、自動バックアップは、長期ストレージ用に別の BLOB にコピーされます。これを使用してデータベースを特定の時点に回復することができます。 コピー プロセスは、データベース ワークロードにパフォーマンスに影響しないバックグラウンド ジョブです。 各データベースの LTR ポリシーでは、LTR バックアップの作成頻度を指定することもできます。
注
現時点では、Azure SQL データベース と Azure SQL Managed Instance のバックアップを不変として構成することはできません。 LTR バックアップは変更できませんが、Azure portal、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-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 バックアップのタイミングは、Microsoft によって制御されます。 手動で LTR バックアップを作成またはバックアップの作成タイミングを制御することはできません。 LTR ポリシーを構成した後、使用可能なバックアップの一覧に最初の LTR バックアップが表示されるまでに最大 7 日かかる場合があります。
論理サーバーまたは SQL マネージド インスタンスを削除すると、そのサーバーまたはマネージド インスタンス上のすべてのデータベースも削除されます。 削除された論理サーバーまたは SQL マネージド インスタンスを復元することはできません。 ただし、データベースに対して LTR を構成した場合、LTR バックアップは削除されず、LTR バックアップが作成された時点まで、同じサブスクリプション内の別のサーバーまたはマネージド インスタンスにデータベースを復元するために使用できます。
同様に、データベースを削除した場合、LTR バックアップは削除されず、構成された保有期間にわたって保持されます。 これらのバックアップは、同じサーバーまたは同じサブスクリプション内の別のサーバーに復元できます。
geo レプリケーションと長期のバックアップ リテンション期間
アクティブ geo レプリケーションまたはフェールオーバー グループをビジネス継続性ソリューションとして使用している場合は、最終的なフェールオーバーを準備し、プライマリと同じ LTR ポリシーをセカンダリ データベースまたはインスタンスで構成します。 バックアップはセカンダリから生成されないため、LTR ストレージ コストは増加しません。 バックアップは、フェールオーバーがトリガーされ、プライマリがセカンダリ リージョンに移動したときに LTR バックアップが中断されずに生成されるようにするために、セカンダリがプライマリになった後にのみ作成されます。
元のプライマリ データベースがフェールオーバーの原因となった障害から復旧すると、新しいセカンダリになります。 そのため、新しいセカンダリでバックアップの作成は再開されません。既存の LTR ポリシーは、再びプライマリになるまで有効になりません。
長期のバックアップ リテンション期間の構成
Azure SQL Database には Azure portal を使用し、Azure SQL Managed Instance には PowerShell を使用して、長期のバックアップ リテンション期間を構成できます。 LTR ストレージからデータベースを復元するために、特定のバックアップを、そのタイムスタンプに基づいて選択することができます。 データベースは、元のデータベースと同じサブスクリプションの既存のサーバーまたはマネージド インスタンスに復元できます。
LTR リテンション期間の最後の 7 日間に復元要求が開始されると、LTR バックアップは、リテンション期間の有効期限が切れた場合でも、復元操作が完了した後にのみ削除されます。
Azure SQL Managed Instance では、SQL エージェント ジョブを使用して コピーのみのデータベース バックアップ をスケジュールし、それを独自のストレージ アカウントに移動することによって代替策とすることができます。
- バックアップを 10 年以上保持します。
- データベースの毎日のコピーを 35 日以上保持します。
- 不変ストレージにデータベース バックアップを格納します。
ヒント
LTR バックアップを使用してコンプライアンスまたはその他のミッション クリティカルな要件を満たしている場合は、定期的な復旧訓練を実施して、LTR バックアップを復元できること、および復元の結果が予想されるデータベース状態であることを確認することを検討してください。
次のステップ
関連するコンテンツ
データベース バックアップは、データの不慮の破損または削除から保護するため、ビジネス継続性およびディザスター リカバリー戦略の最も重要な部分です。