Azure SQL Database の LTR (長期リテンション) バックアップ (長期保有バックアップ) について、情報をまとめておきたいと思います。
Azure SQL Database を対象としていますが、Azure SQL Managed Instance も考え方としては同様となります。
Contents
公式ドキュメント
公式のドキュメントとしては以下となります。
- 長期リテンション – Azure SQL Database と Azure SQL Managed Instance
- Azure SQL Database の長期的なバックアップ保有期間を管理する
- Azure SQL Database の自動バックアップ
LTR の動作を確認する際にはこれらのドキュメントを確認することになります。
基本動作
LTR の基本動作については 長期リテンションのしくみ に記載されています。
LTR 機能を使用すると、指定された完全な SQL Database と SQL Managed Instance のバックアップを、最大で 10 年間、設定可能なアイテム保持ポリシーを持つ Azure Blob Storage に格納することができます。 その後、LTR バックアップを新しいデータベースとして復元できます。 LTR ポリシーが構成されている場合、自動バックアップは、長期ストレージ用に別の BLOB にコピーされます。これを使用してデータベースを特定の時点に回復することができます。 コピーは、データベースのワークロードのパフォーマンスに影響しないバック グラウンド ジョブです。 SQL Database では、各データベースの LTR ポリシーで LTR バックアップを作成する頻度も指定できます
LTR は通常取得されている、PITR 用の自動バックアップで取得されている、完全バックアップを長期保持用の Azure Blob Storage に保存することで、長期保有が行われます。
そのため、元になるバックアップは 自動バックアップ で取得されている完全バックアップとなります。
自動バックアップのバックアップ頻度は次のようになっています。
- 毎週の完全バックアップ。
- 12 時間または 24 時間ごとの差分バックアップ。
- 約 10 分ごとのトランザクション ログ バックアップ。
完全バックアップは週に 1 回の頻度で取得されているため、LTR のバックアップについても毎週取得するように設定を行っていても最小の間隔としては 7 日間隔となります。
この動作については、長期リテンションのしくみ に記載されています。
個々 の LTR バックアップのタイミングは、Azure SQL Database によって制御されます。 手動で LTR バックアップを作成またはバックアップの作成タイミングを制御することはできません。 LTR ポリシーを構成した後、最初の LTR バックアップが利用可能なバックアップのリストに表示されるまで、最大 7 日かかる場合があります。
最大 7 日間かかる場合があるというのは、自動バックアップの完全バックアップの間隔に依存したものとなります。
自動バックアップで完全バックアップが取得されているタイミング
自動バックアップにより取得されているバックアップは Azure SQL DB Backup History – View backups of your Azure SQL Database でアナウンスされた sys.dm_database_backups から確認することができます。
この DMV から取得した情報が以下となりますが、7 日間隔で取得されていることが確認できます。
このバックアップが、LTR として Azure Blob ストレージに保存されることになります。
完全バックアップを取得するタイミングですが、ユーザーが制御することはできず、完全バックアップをどのタイミングで取得するかを指定することはできません。
そのため、LTR についても「xx 日時点のデータをリストアできるようにバックアップを保持しておく」ということを制御することはできません。
LTR でバックアップが取得されているタイミング
PITR の自動バックアップについては DMV から情報を確認できました。
LTR については DMV では確認することはできず、バックアップを表示してバックアップから復元する の方法を使用して取得されているバックアップを確認する必要があります。
この方法を使用することで、バックアップが取得されたタイミングと保有期間を確認することができます。
LTR のバックアップ保有期間について
LTR のバックアップ保有期間は LTR バックアップが取得されたタイミングの設定に依存しており、LTR が取得された後に保有期間を変更しても既に取得されている LTR バックアップの保有期間は変更されません。
これについては 長期リテンションのしくみ に記載されています。
LTR ポリシーへの変更内容は、今後のバックアップにのみ適用されます。 たとえば、毎週のバックアップ リテンション期間 (W)、毎月のバックアップ リテンション期間 (M)、または毎年のバックアップ リテンション期間 (Y) が変更された場合、新しいリテンション期間の設定は新しいバックアップにのみ適用されます。 既存のバックアップのリテンション期間は変更されません。 リテンション期間の期限が切れる前に古い LTR バックアップを削除したい場合は、バックアップを手動で削除する必要があります。
保有期間を短縮 / 延長しても既に取得されている LTR バックアップに対しては反映されません。
LTR のバックアップコストが大きくなったため、保有期間を短縮するということは実運用でも発生する可能性がありますが、保有期間を短縮しても既に取得されているバックアップに対しては、設定は反映されませんので、保有期間より前に LTR を削除したい場合には手動で削除を行う必要があります。
削除された論理サーバー / データベースに対しての LTR の保持
Azure SQL Database では削除されたデータベースをバックアップから復元する操作がサポートされています。
これは LTR も同様となり、削除したデータベースについても LTR の保有期間であれば、削除されたデータベースの復元操作で LTR を選択することができます。
論理サーバーを削除してしまった場合も 長期リテンションのしくみ に記載されているように、LTR は保有期間内は削除されず、論理サーバーを削除しても使用することができます。
論理サーバーまたはマネージド インスタンスを削除すると、そのサーバーまたはマネージド インスタンス上のすべてのデータベースも削除され、復旧できなくなります。 削除されたサーバーまたはマネージド インスタンスは復元できません。 ただし、データベースまたはマネージド インスタンスに対して LTR を構成していた場合、LTR バックアップは削除されず、同じサブスクリプション内の異なるサーバーまたはマネージド インスタンスのデータベースを、LTR バックアップが作成された特定の時点まで復元するために使用できます。
論理サーバーを削除してしまった場合、Azure Portal から削除されたデータベースのインタフェースを使用してリストアを行うことができないため、LTR バックアップから復元する を CLI / PowerShell を用いてリストアする必要があります。
また、データベース / 論理サーバーを削除しても LTR は保持期間中は残りますので、不要となった LTR については明示的に削除を行わないとコストが発生していることは意識しておく必要があります。
Get-AzSqlDatabaseLongTermRetentionBackup でリージョン単位で取得されている LTR と各バックアップの保有期間を確認することができますので LTR を使用している場合は、一度バックアップの状況を確認してみるとよいのではないでしょうか。
Restore a deleted logical server in Azure SQL Database (preview) で公開されていますが、今後削除した論理サーバーをリストアできるようにする機能の実装も進んでいますので、削除した論理サーバーの LTR の復元を Azure Portal からも実施できるようになるかと。
バックアップファイルのサイズについて
バックアップ ストレージ消費量 に記載されている通り、自動バックアップで取得されている完全バックアップはバックアップ圧縮が行われています。(TDE が有効な DB ではログバックアップについては圧縮が行われていません)
TDE で暗号化されたデータベースを含むすべてのデータベースでは、バックアップ ストレージの圧縮とコストを減らすためにすべての完全および差分バックアップが圧縮されます。 バックアップの平均圧縮率は 3 から 4 倍です。 しかし、データの性質や、データベースでデータ圧縮が使用されているかどうかにより、低くなったり高くなったりする可能性があります。
このバックアップファイルが LTR により長期保存されるため、LTR のバックアップについても圧縮された状態となります。
バックアップファイルがどの程度圧縮されているかについては、vCore モデルであれば、Azure SQL データベース監視データ参照 で公開されているメトリックによって確認することができます。(DTU モデルではバックアップファイルのサイズを確認することができません)
バックアップ圧縮の効率については、格納されているデータの内容に依存するため、どの程度圧縮がされるかはデータ次第にはなりますが、単純なデータが格納されている場合には、圧縮効率は高くなる傾向があります。
圧縮の効率が高いデータ構造となっている場合には、バックアップファイルのサイズが小さくなり、それに伴い LTR のコストも抑えられることになります。
Hyperscale の LTR について
Hyperscale でも LTR を取得することが可能です。
Hyperscale の場合、バックアップはスナップショットベースでバックアップが取得されていますが、このスナップショットバックアップが LTR として保存されるような仕様となっているようです。
Hyperscale の LTR については、Hyperscale の LTR リリース時のアナウンスとなる Long-term backup retention(LTR) on Azure SQL Hyperscale service tier is now in preview で仕様が公開されています。
Hyperscale で LTR を使用する場合にはこの情報を参考にすると動作を把握することができるかと。
Serverless の LTR について
Serverless の利用形態でも LTR は使用することができるのですが、自動一時停止 との併用が不可能となっています。
Serverless を使用する目的として自動一時停止を使用することによるコンピューティングのコスト削減がありますが、LTR を取り続ける必要がある場合は、一時停止を無効にする必要があります。
Serverless でワンショットの LTR を取得する必要がある場合は、自動一時停止を無効にした状態で LTR が取得されるまで放置しておき、LTR が取得されたら自動一時停止を有効にするということで、自動一時停止と LTR を併用することは可能です。
特定のタイミングのデータベースを LTR として保持しておきたい場合
要件によっては年末や年度末のデータの状態を LTR として長期保有しておきたいケースがあります。
前述のとおり、LTR のベースとなっている PITR の完全バックアップはバックアップ取得タイミングを制御することができないため、自動バックアップをそのまま使用しただけでは「特定のタイミングのデータベースの状態」を長期間保持しておくことはできません。
特定タイミングのデータベースの状態を LTR で長期間保持しておきたい場合、少し手間がかかりますが次のような方法で実現できます。
- PITR を使用して、データベースを特定の時間の状態でリストアをする
- リストアしたデータベースに必要な保持期間の LTR を設定し、LTR が取得されるまでデータベースを維持する
- LTR が取得されるまでは最大で 7 日間かかる可能性がある
- LTR が取得されたらデータベースを削除する
- データベースを削除しても LTR は保持期間内は残った状態となり、LTR の削除は行われない
PITR を必要なタイミングの時間でリストアし、それを LTR で取得するという方法で、特定の状態のデータベースを LTR で長期保持することができます。