Azure SQL Managed Instance での自動バックアップ
適用対象:
Azure SQL Managed Instance
この記事では、Azure SQL Managed Instance の自動バックアップ機能について説明します。
バックアップの設定を変更する場合は、設定の変更に関するページを参照してください。 バックアップを復元する場合は、自動データベース バックアップを使用した復旧に関するページを参照してください。
自動データベース Backup とは
データベース Backup は、データの破損や削除からの保護に役立つため、事業継続とディザスター リカバリー戦略の最も重要な部分です。 Azure SQL Managed Instance では、完全に管理、および自動化された SQL Server データベース エンジンの Backup が提供されます。 これらの Backup により、構成された 最大 35 日間までの保持期間内の特定の時点にデータベースを復元できます。 ただし、データ保護規則により、バックアップを長期間 (最長 10 年間) 利用できることが求められている場合は、データベースごとに長期保有 (LTR) ポリシーを構成できます。
バックアップ頻度
Azure SQL Managed Instance では以下が作成されます。
- 毎週の完全バックアップ。
- 12 時間ごとの差分バックアップ
- 10 分ごとの トランザクション ログ バックアップ。
トランザクション ログ バックアップの頻度は、コンピューティング サイズとデータベース アクティビティの量によって決まります。 トランザクション ログは約 10 分ごとに取得されますが、変更することができます。 データベースを復元するとき、それぞれの順番で復元する必要がある完全バックアップ、差分バックアップ、トランザクション ログ バックアップはどれであるかがサービスによって判定されます。
バックアップ ストレージの冗長性
Azure SQL Managed Instance では既定で、ペアになっているリージョンにレプリケートされる geo 冗長ストレージ BLOB にデータが格納されます。 geo 冗長は、プライマリ リージョンのバックアップ ストレージに影響を与える障害から保護するのに役立ちます。 また、障害発生時にインスタンスを別のリージョンに復元することもできます。
ストレージ冗長性メカニズムでは、予定および予定外イベントから保護されるように、データの複数のコピーが格納されます。 このようなイベントには、一時的なハードウェアの障害、ネットワークの停止や停電、大規模な自然災害が含まれる場合があります。
データベースがデプロイされているのと同じリージョン内にバックアップが確実に保持されるようにするために、バックアップ ストレージの冗長性を既定の geo 冗長ストレージから、リージョン内のデータを保持する他の種類のストレージに変更できます。 ストレージの冗長性について詳しくは、「データの冗長性」を参照してください。
インスタンスの作成時にバックアップ ストレージの冗長性を構成でき、後でインスタンス レベルで更新することができます。 既存のインスタンスに対する変更は、それ以降のバックアップにのみ適用されます。 既存のインスタンスのバックアップ ストレージの冗長性を更新した後、変更が適用されるまでに最大 24 時間かかることがあります。 バックアップ ストレージの冗長性に加えられた変更は、短期バックアップにのみ適用されます。 長期保有ポリシーでは、ポリシーの作成時に短期バックアップの冗長性オプションが継承されます。 冗長性オプションは、短期バックアップの冗長性オプションが後で変更された場合でも、長期バックアップに対して保持されます。
注意
バックアップの冗長性を変更すると、アップグレード手順が発生しますが、これによってフェールオーバーが開始されることに注意してください。
次のいずれかのバックアップのストレージ冗長性を選ぶことができます。
ローカル冗長ストレージ (LRS): プライマリ リージョンの 1 つの物理的な場所内で、バックアップを同期的に 3 回コピーします。 LRS は最もコストのかからないレプリケーション オプションですが、高可用性または持続性を必要とするアプリケーションには推奨されません。
ゾーン冗長ストレージ (ZRS): プライマリ リージョンの 3 つの Azure 可用性ゾーン間でバックアップを同期的にコピーします。 現在、特定のリージョンで使用できます。
geo 冗長ストレージ (GRS): LRS を使用して、プライマリ リージョンの 1 つの物理的な場所内で、バックアップを同期的に 3 回コピーします。 その後、ペア セカンダリ リージョンの 1 つの物理的な場所にデータを非同期的に 3 回コピーします。
結果は次のとおりです。
- SINGLE の可用性ゾーンのプライマリ リージョン内の 3 つの同期コピー。
- プライマリ リージョンからセカンダリ リージョンに非同期的にコピーされた、SINGLE の可用性ゾーン内でペア リージョン内の 3 つの同期コピー。
geo ゾーン冗長ストレージ (GZRS): 可用性ゾーン間での冗長性によって提供される高可用性と、geo レプリケーションによって提供されるリージョン障害からの保護が結合されます。 GZRS アカウント内のデータは、プライマリ リージョンの 3 つの Azure 可用性ゾーン間でコピーされます。 また、データは、リージョンの災害から保護するためにセカンダリ地理的リージョンにもレプリケートされます。 そのリージョンには、プライマリ リージョンからセカンダリ リージョンに非同期的にコピーされた、SINGLE の可用性ゾーン内に 3 つの同期コピーもあります。
警告
- geo リストアは、ローカル冗長またはゾーン冗長のストレージを使用するようにデータベースを更新するとすぐに無効になります。
- ストレージ冗長性の図には、複数の可用性ゾーン (マルチ AZ) があるリージョンがすべて示されています。 しかし、SINGLE の可用性ゾーンのみを提供し、ZRS や GZRS をサポートしていないリージョンがいくつかあります。
バックアップの用途
これらのバックアップを使用して、以下を行うことができます。
保有期間内の過去の特定の時点に既存のデータベースを復元する。その際に、Azure portal、Azure PowerShell、Azure CLI、または REST API を使用します。 この操作により、元のデータベースと同じインスタンス、または同じサブスクリプションとリージョン内の別のインスタンスに新しいデータベースが作成されます。 元のデータベースが上書きされないように別の名前が使用されます。 Azure portal を使用して、ソース インスタンスとは異なるサブスクリプションのインスタンスに、ポイントインタイム データベース バックアップを復元することもできます。
復元が終了した後に、元のデータベースを削除できます。 または、元のデータベースの名前を変更することも、復元されたデータベースの名前を元のデータベース名に変更することもできます。
削除の時点など、保有期間内の特定の時点に削除されたデータベースを復元する。 削除されたデータベースは、バックアップが作成されたのと同じマネージド インスタンス、同じサブスクリプション内の別のインスタンス、またはソース インスタンスとは異なるサブスクリプションに復元できます。 データベースを削除する前に、データが失われないようにサービスによって最後のトランザクション ログ バックアップが取得されます。
別の地理的リージョンにデータベースを復元する。 geo リストアを使用すると、プライマリ リージョンのデータベースまたはバックアップにアクセスできないときでも、地理的な災害から復旧できます。 任意の Azure リージョンの既存のマネージド インスタンスに、新しいデータベースが作成されます。
重要
geo リストアは、geo 冗長バックアップ ストレージを使用して構成されたデータベースでのみ利用できます。 現在、データベースに geo レプリケートされたバックアップを使用していない場合は、バックアップ ストレージの冗長性を構成することでこれを変更できます。
データベースに LTR ポリシーが構成されている場合は、データベースの長期バックアップからデータベースを復元します。 LTR を使用すると、Azure portal、Azure CLI、または Azure PowerShell を使って、コンプライアンスの要求を満たすため、または以前のバージョンのアプリケーションを実行するために、以前のバージョンのデータベースを復元できます。 その他の情報については、「長期保有の概要」ページをレビューしてください。
機能と特徴を復元する
この表は、ポイントインタイム リストア (PITR)、geo リストア、長期保有の機能と特徴をまとめたものです。
| バックアップ プロパティ | PITR | geo リストア | LTR |
|---|---|---|---|
| SQL バックアップの種類 | 完全バックアップ、差分バックアップ、およびトランザクション ログ バックアップ。 | PITR バックアップのレプリケートされたコピー。 | 完全バックアップのみ。 |
| 目標復旧時点 (RPO) | コンピューティング サイズとデータベース アクティビティの量に基づいて、 約 10 分。 | geo レプリケーションに基づいて最大 1 時間。 1 | 1 週間 (またはユーザーのポリシー)。 |
| 目標復旧時間 (RTO) | 復元に要する時間は通常、12 時間未満ですが、サイズとアクティビティによってはさらに時間が長くなる場合もあります。 復元に関する記事を参照してください。 | 復元に要する時間は通常、12 時間未満ですが、サイズとアクティビティによってはさらに時間が長くなる場合もあります。 復元に関する記事を参照してください。 | 復元に要する時間は通常、12 時間未満ですが、サイズとアクティビティによってはさらに時間が長くなる場合もあります。 復元に関する記事を参照してください。 |
| 保持 | 1 日から 35 日。 | ソースと同じく、既定で有効になっています。 2 | 既定では有効になっていません。 保有期間は最大 10 年です。 |
| Azure Storage | 既定では geo 冗長です。 必要に応じて、ゾーン冗長またはローカル冗長ストレージを構成できます。 | PITR バックアップ ストレージの冗長性が geo 冗長に設定されている場合に使用できます。 PITR バックアップ ストレージがゾーン冗長またはローカル冗長の場合は使用できません。 | 既定では geo 冗長です。 ゾーン冗長またはローカル冗長ストレージを構成できます。 |
| バックアップを不変として 構成する | サポート対象外 | サポートされていません | サポートされていません |
| 同じリージョンでの新しいデータベースの復元 | サポートされています | サポートされています | サポートされています |
| 別のリージョンでの新しいデータベースの復元 | サポートされていません | 任意の Azure リージョンでサポートされています | 任意の Azure リージョンでサポートされています |
| 別のサブスクリプションでの新しいデータベースの復元 | サポートされています | サポートされていません。3 | サポートされていません。3 |
| Azure portal を使用した復元 | はい | イエス | はい |
| PowerShell を使用した復元 | はい | イエス | はい |
| Azure CLI を使用した復元 | はい | イエス | はい |
1 大規模なデータベースを必要とし、ビジネス継続性を保証する必要があるビジネス-クリティカルなアプリケーションの場合は、フェールオーバー グループを参照してください。
2 すべての PITR Backup は、既定では geo 冗長ストレージに格納されるため、geo リストアは既定では有効になっていることを意味します。
3 回避策は、新しいサーバーに復元し、Resource Move を使用してサーバーを別のサブスクリプションに移動することです。
バックアップからデータベースを復元する
復元を行う場合は、バックアップからのデータベースの復元に関するページを参照してください。 次の例を使用して、バックアップの構成と復元の操作を試すことができます。
| 操作 | Azure portal | Azure CLI | Azure PowerShell |
|---|---|---|---|
| バックアップ保有期間を変更する | SQL データベース / SQL Managed Instance | SQL データベース / SQL Managed Instance | SQL データベース / SQL Managed Instance |
| 長期的なバックアップ保有期間を変更する | SQL データベース / SQL Managed Instance | SQL データベース / SQL Managed Instance | SQL データベース / SQL Managed Instance |
| 特定の時点からデータベースを復元する | SQL データベース / SQL Managed Instance | SQL データベース / SQL Managed Instance | SQL データベース / SQL Managed Instance |
| 削除されたデータベースの復元 | SQL データベース / SQL Managed Instance | SQL データベース / SQL Managed Instance | SQL データベース / SQL Managed Instance |
| Azure Blob Storage からデータベースを復元する | SQL Managed Instance |
自動バックアップスケジュール
Azure SQL Managed Instance で、完全、差分、トランザクション ログのバックアップを作成すると、バックアップが自動的に管理されます。 このプロセスは内部スケジュールに基づいて管理されます。
初回バックアップ
新しいデータベース: 初回の完全バックアップは、新しいデータベースの作成または復元の直後、あるいはバックアップの冗長性が変更された後にスケジュールされます。 通常、このバックアップは 30 分以内に完了しますが、大規模なデータベースの場合はさらに時間がかかる場合があります。
復元されたデータベース: 復元されたデータベースの初回のバックアップの期間は、データベース のサイズによって異なります。 復元されたデータベースまたはデータベース コピーは、多くの場合、サイズが大きいため、初回バックアップに必要な時間が長くなります。
スケジュール済みの完全バックアップ
- 週単位のスケジュール: システムにより、インスタンス全体で、週単位の完全バックアップ ウィンドウが設定されます。
- 完全バックアップ ウィンドウ: これは、完全バックアップ実行にかかる特定の期間です。 システムは、このウィンドウ内に完全バックアップを完了することを目的としていますが、必要に応じて、バックアップが完了するまで、スケジュールされた期間を超えてバックアップを続行する可能性があります。
- アダプティブ スケジューリング: バックアップ アルゴリズムが CPU 使用率と I/O スループットをインジケーターとして使用して、週に約 1 回、ワークロードに対するバックアップ 期間の影響を評価します。 前週のワークロードに応じて完全バックアップ期間が調整される可能性があります。
- ユーザー構成: ユーザーは、バックアップ スケジュールを変更または無効にできないことに注意することが重要です。
重要
新しいデータベース、復元されたデータベース、またはコピーされたデータベースの場合、ポイントインタイム リストア (PITR) 機能は、最初の完全バックアップの後で最初のトランザクション ログ バックアップが作成されたときに使用できるようになります。
バックアップ ストレージ消費量
SQL Server のバックアップと復元のテクノロジでは、特定の時点にデータベースを復元するには、中断のないバックアップ チェーンが必要です。 このチェーンは 1 回の完全バックアップ、1 回の差分バックアップ (任意)、1 回または複数回のトランザクション ログ バックアップで構成されます。
Azure SQL Managed Instance のバックアップ スケジュールには、毎週 1 回の完全バックアップが含まれます。 保有期間全体で PITR を提供にするには、構成されている保有期間より最大で 1 週間長い期間の追加の完全、差分、およびトランザクション ログ バックアップをシステムで格納する必要があります。
つまり、保有期間中の任意の時点において、保有期間の最も古い時点より古い完全バックアップが存在する必要があります。 また、その完全バックアップから次の完全バックアップまでの差分とトランザクション ログ バックアップの中断されていないチェーンが存在する必要があります。
PITR 機能を提供するために必要なくなったバックアップは、自動的に削除されます。 差分バックアップとログ バックアップでは先行する完全バックアップが復元可能である必要なため、3 つのバックアップの種類すべてが毎週まとめて消去されます。
TDE で暗号化されたデータベースを含むすべてのデータベースでは、バックアップ ストレージの圧縮とコストを減らすためにすべての完全および差分バックアップが圧縮されます。 バックアップの平均圧縮率は 3 から 4 倍です。 しかし、データの性質や、データベースでデータ圧縮が使用されているかどうかにより、大幅に低くなったり高くなったりする可能性があります。
重要
TDE で暗号化されたデータベースの場合、ログ バックアップ ファイルはパフォーマンス上の理由から圧縮されません。 TDE で暗号化されていないデータベースのログ バックアップは圧縮されます。
Azure SQL Managed Instance では、使用されたバックアップ ストレージの合計が累積値として計算されます。 この値は 1 時間ごとに Azure 課金パイプラインに報告されます。 この時間あたりの使用量がパイプラインによって集計されて、毎月末に消費量が計算されます。 データベースの削除後は、バックアップが古くなって削除されると共に消費量が減少します。 すべてのバックアップが削除されて、PITR が不可能になると、課金は停止します。
重要
削除されたデータベースのバックアップはポイントインタイム リストア (PITR) のために保持されます。これは、データベースが削除された場合でもバックアップが保持されるため、ストレージ コストが増加する可能性があります。 コストを削減するために、保持期間を 0 日に設定できますが、これは削除されたデータベースに対してのみです。 通常のデータベースでは、最小保持期間は 1 日です。
バックアップ ストレージ消費量を微調整する
データベースの最大データ サイズまでのバックアップ ストレージの使用量については、課金されません。 超過のバックアップ ストレージ消費量は、個々のデータベースのワークロードと最大サイズに依存します。 バックアップ ストレージ消費量を減らすには、次の調整手法のいくつかを検討してください。
- 必要最小限までデータベースのバックアップ保持期間を短縮します。
- インデックスの再構築などの大規模な書き込み操作を、必要以上に頻繁に行わないようにします。
- 大規模なデータ読み込み操作の場合、クラスター化された列ストア インデックスを使用して、関連するベスト プラクティスに従うことを検討します。 また、非クラスター化インデックスの数を減らすことを検討します。
- 汎用サービス レベルでは、プロビジョニングされたデータ ストレージの方が、バックアップ ストレージの価格よりも安価です。 超過のバックアップ ストレージのコストが継続的に増加している場合は、データ ストレージを増やしてバックアップ ストレージを節約することを検討してください。
- 一時的な結果やデータの保存には、アプリケーションのロジックでの永続的テーブルではなく
tempdbを使用します。 - 可能な限り (Dev/Test 環境など) ローカル冗長バックアップ ストレージを使用します。
バックアップ保持期間
Azure SQL Managed Instance では、バックアップの短期および長期保有の両方が提供されます。 短期保有では、データベースの保有期間内に PITR を使用できます。 長期保有では、さまざまなコンプライアンス要件に応じてバックアップが提供されます。
短期保有
新しいデータベース、復元されたデータベース、コピーされたデータベースのすべてについて、Azure SQL Managed Instance では、既定で過去 7 日間の PITR が可能な十分なバックアップが保持されます。 この構成は、1 ～ 35 日の範囲で変更 できます。 データベースまたはマネージド インスタンスに対して定義された保有期間内の任意の時点に確実にデータベースを復元できるようにするために、サービスでは定期的な完全、差分、およびログ バックアップが作成されます。
インスタンスの作成時に STR のバックアップ ストレージの冗長性オプションを指定し、後で変更できます。 インスタンスの作成後にバックアップ冗長性オプションを変更した場合、新しいバックアップでは新しい冗長性オプションが使用されます。 前の STR 冗長性オプションで作成されたバックアップ コピーは移動もコピーもされません。 保持期間の有効期限が切れるまで、元のストレージ アカウントに残されます。 「バックアップ ストレージ消費量」で説明されているように、PITR を有効にするために格納されているバックアップは、正確なデータ復元を保証する保持期間より古い場合があります。
データベースを削除した場合、システムでは、オンライン データベースと同じ方法で、特定の保有期間のバックアップが保持されます。 しかし、削除されたデータベースの場合、1 日から 35 日の保有期間を 0 日から 35 日に更新して、手動でバックアップを削除できます。 短期保有期間の最大値である 35 日より長くバックアップを保持する必要がある場合は、長期保有を有効にすることができます。
重要
マネージド インスタンスを削除すると、そのマネージド インスタンス上のすべてのデータベースも削除され、復旧できなくなります。 削除されたマネージド インスタンスは復元できません。 しかし、マネージド インスタンスの長期保有期間を構成した場合、LTR バックアップは削除されません。 その後、これらのバックアップを使用して、LTR バックアップが作成された時点まで、同じサブスクリプション内の別のマネージド インスタンスにデータベースを復元できます。 詳細については、長期バックアップの復元に関する記述を参照してください。
長期保有 (LTR)
SQL Managed Instance では、Azure Blob Storage で最大 10 年間まで、LTR の完全バックアップを構成できます。 LTR ポリシーを構成すると、完全バックアップが自動的に別のストレージ コンテナーにコピーされます。
各種のコンプライアンス要件を満たすために、毎週、毎月、毎年の完全バックアップに対してさまざまな保有期間を選択できます。 頻度はポリシーによって異なります。 たとえば、W=0, M=1, Y=0 を設定すると、毎月 LTR コピーが作成されます。 LTR の詳細については、長期保有に関するページを参照してください。
Azure SQL Managed Instance の LTR バックアップ ストレージ冗長性は、LTR ポリシーが定義された時点で STR によって使用されるバックアップ ストレージ冗長性から継承されます。 STR バックアップ ストレージの冗長性が今後変更された場合でも、それを変更することはできません。
ストレージの使用量は、LTR バックアップについて選択した頻度と保持期間によって異なります。 LTR ストレージのコストは、LTR 料金計算ツールを使用して見積もることができます。
バックアップ ストレージのコスト
Azure SQL Managed Instance では、課金対象の合計バックアップ ストレージは、すべてのバックアップ ファイルの累積値として計算されます。 この値は 1 時間ごとに Azure 課金パイプラインに報告されます。 パイプラインでは、この時間あたりの使用量が集計されて、毎月末にバックアップ ストレージの消費量が算出されます。
データベースが削除されると、古いバックアップが期限切れになって削除されるに従い、バックアップ ストレージの使用量は徐々に減少します。 差分バックアップとログ バックアップでは先行する完全バックアップが復元可能である必要なため、3 つのバックアップの種類すべてが毎週まとめて消去されます。 すべてのバックアップが削除された後、課金は停止します。
バックアップ ストレージの価格は異なります。 選択したバックアップ ストレージの冗長性オプションとリージョンによって異なります。 バックアップ ストレージは、すべてのバックアップで同じ割合で、1 か月あたりに消費されたギガバイトに基づいて課金されます。
バックアップ ストレージの冗長性は、バックアップ コストに次のように影響します。
Locally redundant price = published priceZone-redundant price = published price x 1.25Geo-redundant price = published price x 2Geo-zone-redundant price = published price x 3.4
価格については、Azure SQL Managed Instance の価格ページを参照してください。
Note
Azure 請求書では、バックアップ ストレージの全体の消費量ではなく、バックアップ ストレージの超過分の消費量のみが表示されます。 たとえば、仮に 4 TB のデータ ストレージをプロビジョニングした場合、4 TB の無料のバックアップ ストレージ領域が得られます。 合計 5.8 TB のバックアップ ストレージ領域を使用する場合、Azure 請求書には 1.8 TB のみが表示されます。これは、使用したバックアップ ストレージの超過分に対してのみ課金されるためです。
マネージド インスタンスの場合、課金対象のバックアップ ストレージの合計サイズはインスタンス レベルで集計され、次のように計算されます。
Total billable backup storage size = (total size of full backups + total size of differential backups + total size of log backups) – maximum instance data storage
課金対象のバックアップ ストレージの合計 (存在する場合) は、使用したバックアップ ストレージの冗長性の割合に応じて、リージョンごとに 1 か月あたりのギガバイト単位で課金されます。 バックアップ ストレージの消費量は、個々のデータベースとマネージド インスタンスのワークロードとサイズに依存します。 差分バックアップとログ バックアップのサイズはデータの変更量に比例するため、大幅に変更されたデータベースでは、これらのバックアップが大きくなります。 したがって、そのようなデータベースではバックアップ料金が高くなります。
簡単な例として、データベースのバックアップ ストレージが累積で 744 GB になり、データベースは完全にアイドル状態であるため、この量は 1 か月を通して変わらないものとします。 この累積ストレージ消費量を 1 時間あたりの使用量に変換するには、744.0 (1 か月 31 日 * 1 日 24 時間) で割ります。 SQL Managed Instance では、データベースで 1 時間あたり 1 GB の PITR バックアップが一定の割合で消費されたことが、Azure 課金パイプラインに報告されます。 Azure の課金では、この消費量を集計し、1 か月全体で 744 GB という使用量が示されます。 コストは、リージョンでの 1 か月あたりのギガバイトの割合に基づきます。
次に別の例を示します。 同じアイドル状態のデータベースで、保有期間が月の途中で 7 日から 14 日間に増やされたとします。 この増加により、バックアップ ストレージの合計は 1,488 GB に倍増します。 SQL Managed Instance では、1 時間から 372 時間まで (月の前半) の使用量が 1 GB と報告されます。 373 時間から 744 時間まで (月の後半) の使用量は 2 GB と報告されます。 この使用量が集計されて最終的な請求は、1 か月あたり 1,116 GB になります。 保有コストはすぐには増加しません。 バックアップは 14 日間の最大保有期間に達するまで増加するため、毎日徐々に増加します。
実際のバックアップの課金シナリオはさらに複雑です。 データベース内の変更の割合はワークロードに依存し、時間の経過と共に変化するので、各差分およびログ バックアップのサイズも変化します。 バックアップ ストレージの時間単位の消費量はそれに応じて変動します。
各差分バックアップには、前回の完全バックアップ以降にデータベースで行われたすべての変更も含まれます。 そのため、すべての差分バックアップの合計サイズは、1 週間の間に徐々に増加します。 その後、完全、差分、およびログ バックアップの古いセットが期限切れになった後、急激に減少します。
たとえば、インデックスの再構築などの大量の書き込みアクティビティが、完全バックアップが完了した直後に実行されるとします。 その後、インデックスの再構築によって行われる変更が以下に含まれます。
- 再構築の間に作成されるトランザクション ログ バックアップ。
- 次の差分バックアップ。
- 次の完全バックアップが実行されるまでに作成されるすべての差分バックアップ。
すべての差分バックアップのサイズを減らすために、750 GB を超え、データベース サイズの 75% に等しくなる過度に大きな差分バックアップは、最後の完全バックアップが 24 時間以上前に行われた場合、完全バックアップに昇格されます。
コストを監視する
バックアップ ストレージのコストを把握するには、Azure portal の [コストの管理と請求] に移動します。 [コスト管理] を選択してから、[コスト分析] を選択します。 [スコープ] で必要なサブスクリプションを選択してから、以下のように目的の期間とサービスが得られるようにフィルター処理します。
[サービス名] のフィルターを追加します。
ドロップダウン リストで、マネージド インスタンスの [SQL マネージド インスタンス] を選択します。
[測定サブカテゴリ] の別のフィルターを追加します。
PITR バックアップ コストを監視するには、ドロップダウン リストで [マネージド インスタンスの PITR バックアップ ストレージ] を選択します。 測定値は、バックアップ ストレージの消費量が存在する場合にのみ表示されます。
LTR バックアップのコストを監視するには、ドロップダウン リストで、[SQL マネージド インスタンス - LTR バックアップ ストレージ] を選択します。 測定値は、バックアップ ストレージの消費量が存在する場合にのみ表示されます。
[ストレージ] と [コンピューティング] のサブカテゴリも必要に応じて使用できますが、これらはバックアップ ストレージのコストに関連付けられていません。
重要
測定値は、現在使用中のカウンターについてのみ表示されます。 カウンターが利用できない場合、そのカテゴリが現在使用されていないと考えられます。 たとえば、マネージド インスタンスをデプロイしていないお客様に対するマネージド インスタンス カウンターは存在しません。 同様に、ストレージを消費していないリソースについては、ストレージ カウンターは表示されません。 PITR や LTR バックアップ ストレージの消費量がない場合、これらの測定値は表示されません。
暗号化バックアップ
データベースが TDE で暗号化されている場合、LTR バックアップを含むバックアップは保存中に自動的に暗号化されます。 Azure SQL のすべての新しいデータベースでは、既定で TDE が有効に構成されます。 TDE の詳細については、SQL Managed Instance での Transparent Data Encryption に関するページを参照してください。
バックアップの整合性
すべてのデータベース バックアップは、バックアップの整合性を高めるために、CHECKSUM オプションを使用して実行されます。 Azure SQL エンジニアリング チームによる自動データベース バックアップの自動テストは、現在、Azure SQL Managed Instance では利用できません。 実際のワークロードについては、SQL Managed Instance のデータベースに対してテスト バックアップの復元と DBCC CHECKDB をスケジュールします。
システムではバックアップの整合性を検証しませんが、バックアップ サービスに問題がある場合にマイクロソフトに警告するバックアップの保護が引き続き組み込まれています。 さらに、バックアップで問題が発生した場合 (完全バックアップが行われなかった、バックアップ サービスが停止している、ログ バックアップが SLA から外れている、バックアップ ハードウェアまたはソフトウェアが破損している場合など) もサポートされます。
Azure Policy を使用してバックアップ ストレージの冗長性を適用する
すべてのデータを 1 つの Azure リージョンに保持する必要があるデータ所在地の要件がある場合は、Azure Policy を使用して、SQL Managed Instance に対してゾーン冗長またはローカル冗長のバックアップを適用することができます。
Azure Policy は、Azure リソースにルールを適用するポリシーの作成、割り当て、管理に使用できるサービスです。 Azure Policy は、これらのリソースが会社の標準やサービス レベル アグリーメントに準拠した状態を維持するのに役立ちます。 詳細については、Azure Policy の概要に関するページを参照してください。
バックアップ ストレージの冗長性の組み込みポリシー
組織レベルでデータ所在地の要件を適用するために、Azure portal または Azure PowerShell を使用してサブスクリプションにポリシーを割り当てることができます。 たとえば、サブスクリプションまたはリソース グループ レベルで次の組み込みポリシーを割り当てた場合、サブスクリプション内のユーザーは、Azure portal または Azure PowerShell を介して geo 冗長バックアップ ストレージを使用してマネージド インスタンスを作成することはできません: SQL マネージド インスタンスでは GRS バックアップ冗長の使用を避ける。
SQL Managed Instance の組み込みポリシー定義の完全な一覧については、ポリシー リファレンスを参照してください。
重要
T-SQL を使用してデータベースを作成する場合、Azure ポリシーは適用されません。 T-SQL を使用してデータベースを作成するときにデータ所在地を適用するには、CREATE DATABASE ステートメントの BACKUP_STORAGE_REDUNDANCY パラメーターに対する入力として LOCAL または ZONE を使用します。
コンプライアンス
既定の保有期間がコンプライアンス要件を満たしていない場合は、PITR 保有期間を変更できます。 詳細については、「PITR バックアップ保有期間を変更する」を参照してください。
Note
この「自動バックアップ設定を変更する」記事は、デバイスまたはサービスから個人データを削除する手順について説明しており、GDPR の下で義務を果たすために使用できます。 GDPR に関する一般情報については、Microsoft Trust Center の GDPR に関するセクションおよび Service Trust Portal の GDPR に関するセクションをご覧ください。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示