Azure SQL Database の自動バックアップ

  • [アーティクル]

適用対象: Azure SQL データベース

この記事では、Azure SQL Database の自動バックアップ機能について説明します。

バックアップの設定を変更する場合は、設定の変更に関するページを参照してください。 バックアップを復元する場合は、自動データベース バックアップを使用した復旧に関するページを参照してください。

データベースのバックアップとは

データベース バックアップは、データの破損や削除からの保護に役立つため、事業継続とディザスター リカバリー戦略の最も重要な部分です。 これらのバックアップにより、構成された保有期間内の特定の時点にデータベースを復元できます。 データ保護規則により、バックアップを長期間 (最長 10 年間) 利用できることが求められている場合は、単一データベースとプールされたデータベースの両方に対して長期保有 (LTR) を構成できます。

Hyperscale 以外のサービス レベルの場合、Azure SQL Database では SQL Server エンジン テクノロジを使用してデータをバックアップおよび復元します。 Hyperscale データベースでは、ストレージ スナップショットに基づいてバックアップと復元が使用されます。 従来の SQL Server バックアップ テクノロジでは、大規模なデータベースのバックアップと復元時間が長くなります。 スナップショットを使用する場合、データベース サイズに関係なく、Hyperscale によってインスタント バックアップと高速復元機能が提供されます。 詳細については、Hyperscale バックアップに関するページを参照してください。

バックアップ頻度

Azure SQL Database では以下が作成されます。

トランザクション ログ バックアップの正確な頻度は、コンピューティング サイズとデータベース アクティビティの量に基づきます。 データベースを復元するとき、復元する必要がある完全バックアップ、差分バックアップ、トランザクション ログ バックアップはどれであるかがサービスによって判定されます。

Hyperscale アーキテクチャでは、完全、差分、ログ バックアップは必要ありません。 詳細については、Hyperscale バックアップに関するページを参照してください。

バックアップ ストレージの冗長性

ストレージ冗長性メカニズムでは、予定および予定外イベントから保護されるように、データの複数のコピーが格納されます。 このようなイベントには、一時的なハードウェアの障害、ネットワークの停止や停電、大規模な自然災害が含まれる場合があります。

既定で、Azure SQL データベースの新しいデータベースは、ペアリングされたリージョンにレプリケートされる geo 冗長ストレージ BLOB にバックアップが格納されます。 geo 冗長は、プライマリ リージョンのバックアップ ストレージに影響を与える障害から保護するのに役立ちます。 また、リージョンで障害が発生した場合に、別のリージョンのデータベースを復元することもできます。

Azure portal には、一部の構成設定を事前に設定するのに役立つワークロード環境 オプションが用意されています。 これらの設定は、オーバーライドできます。 このオプションは、[SQL Database の作成] ポータルページにのみ適用されます。

  • 開発ワークロード環境を選択すると、ローカル冗長ストレージを使用するようにバックアップストレージ冗長オプションが設定されます。 ローカル冗長ストレージではコストが削減され、ゾーンまたは geo レプリケーション ストレージの冗長性を必要としない運用前環境に適しています。
  • 生産ワークロード環境を選択すると、バックアップストレージの冗長性は規定で geo 冗長ストレージに設定されます。
  • ワークロード環境オプションでは、コンピューティングの初期設定も変更されますが、これはオーバーライドできます。 それ以外の場合、ワークロード環境 オプションは、ライセンスやその他のデータベース構成設定には影響しません。

データベースがデプロイされているのと同じリージョン内にバックアップが確実に保持されるようにするために、バックアップ ストレージの冗長性を既定の geo 冗長ストレージから、リージョン内のデータを保持する他の種類のストレージに変更できます。 構成されたバックアップ ストレージの冗長性は、短期保有 (STR) バックアップと LTR バックアップの両方に適用されます。 ストレージの冗長性について詳しくは、「データの冗長性」を参照してください。

データベースの作成時にバックアップ ストレージの冗長性を構成でき、後で更新することもできます。 既存のデータベースに対する変更は、それ以降のバックアップにのみ適用されます。 既存のデータベースのバックアップ ストレージの冗長性を更新した後、変更が適用されるまでに最大 48 時間かかることがあります。

次のいずれかのバックアップのストレージ冗長性を選ぶことができます。

  • ローカル冗長ストレージ (LRS): プライマリ リージョンの 1 つの物理的な場所内で、バックアップを同期的に 3 回コピーします。 LRS は最もコストの低いストレージ オプションですが、リージョンの障害に対する回復性や高いデータ持続性の保証を必要とするアプリケーションにはお勧めしません。

    ローカル冗長ストレージ (LRS) オプションを示すダイアグラム。

  • ゾーン冗長ストレージ (ZRS): プライマリ リージョンの 3 つの Azure 可用性ゾーン間でバックアップを同期的にコピーします。 現在、特定のリージョンでのみ使用できます。

    ゾーン冗長ストレージ (ZRS) オプションを示す図。

  • geo 冗長ストレージ (GRS): LRS を使用して、プライマリ リージョンの 1 つの物理的な場所内で、バックアップを同期的に 3 回コピーします。 その後、ペア セカンダリ リージョンの 1 つの物理的な場所にデータを非同期的に 3 回コピーします。

    結果は次のとおりです。

    • プライマリ リージョン内の 3 つの同期コピー。
    • プライマリ リージョンからセカンダリ リージョンに非同期的にコピーされた、ペア リージョン内の 3 つの同期コピー。

    geo 冗長ストレージ (GRS) オプションを示す図。

警告

  • geo リストアは、ローカル冗長またはゾーン冗長のストレージを使用するようにデータベースを更新するとすぐに無効になります。
  • ストレージ冗長性の図には、複数の可用性ゾーン (マルチ AZ) があるリージョンがすべて示されています。 しかし、1 つの可用性ゾーンのみを提供し、ZRS をサポートしていないリージョンがいくつかあります。
  • Hyperscale データベース用のバックアップ ストレージの冗長性は、作成時にのみ設定できます。 リソースのプロビジョニング後にこの設定を変更することはできません。 ダウンタイムを最小限に抑えて既存の Hyperscale データベースに対するバックアップ ストレージの冗長性設定を更新するには、アクティブ geo レプリケーションを使用します。 または、データベース コピーを使用することもできます。 詳しくは、「Hyperscale のバックアップとストレージの冗長性」をご覧ください。

バックアップの用途

次のシナリオでは、自動的に作成されたバックアップを使用できます。

  • 保有期間内の特定の時点に既存のデータベースを復元します。その際に、Azure portal、Azure PowerShell、Azure CLI、または REST API を使用します。 この操作では、元のデータベースと同じサーバー上に新しいデータベースを作成しますが、元のデータベースが上書きされないように、別の名前を使用します。

    復元が終了した後、必要に応じて元のデータベースを削除し、復元されたデータベースの名前を元のデータベース名に変更できます。 または、元のデータベースを削除するのではなく、名前を変更してから、復元されたデータベースの名前を元のデータベース名に変更することもできます。

  • 削除の時点など、保有期間内の特定の時点に削除されたデータベースを復元します。 削除されたデータベースは、元のデータベースを作成したのと同じサーバーにのみ復元できます。 データベースを削除する前に、データが失われないようにサービスによって最後のトランザクション ログ バックアップが取得されます。

  • 別の地理的リージョンにデータベースを復元する。 geo リストアを使用すると、プライマリ リージョンのデータベースやバックアップにアクセスできないときにリージョンの障害から復旧できます。 任意の Azure リージョンの既存のサーバーに新しいデータベースが作成されます。

    重要

    geo リストアは、geo 冗長バックアップ ストレージを使用して構成されたデータベースでのみ利用できます。 現在、データベースに geo レプリケートされたバックアップを使用していない場合は、バックアップ ストレージの冗長性を構成することでこれを変更できます。

  • データベースに LTR ポリシーが構成されている場合は、単一データベースまたはプールされたデータベースの特定の長期バックアップからデータベースを復元します。 LTR を使用すると、Azure portal、Azure CLI、または Azure PowerShell を使って、コンプライアンスの要求を満たすため、または以前のバージョンのアプリケーションを実行するために、以前のバージョンのデータベースを復元できます。 詳細については、「長期保存」をご覧ください。

セカンダリ レプリカでの自動バックアップ

自動バックアップは、Business Critical サービス レベルのセカンダリ レプリカから取得されるようになりました。 データは各ノードの SQL Server プロセス間でレプリケートされるため、バックアップ サービスは読み取り不可能なセカンダリ レプリカからバックアップを取得します。 この設計により、プライマリ レプリカはメイン ワークロード用となり、読み取り可能なセカンダリ レプリカは読み取り専用ワークロード用になります。 Business Critical サービス レベルの自動バックアップは、ほとんどの場合、セカンダリ レプリカから取得されます。 セカンダリ レプリカでの自動バックアップが失敗した場合、バックアップ サービスはプライマリ レプリカからバックアップを取得します。

セカンダリ レプリカでの自動バックアップ:

  • 既定では有効になっています。
  • サービス レベルの価格以外に追加コストはかかりません。
  • Business Critical サービス レベルのパフォーマンスと予測可能性が向上します。

Note

  • インスタンスの機能を無効にするには、Microsoft サポート チケットを作成します。

機能と特徴を復元する

この表は、ポイントインタイム リストア (PITR)、geo リストア、長期保有の機能と特徴をまとめたものです。

バックアップ プロパティ PITR geo リストア LTR
SQL バックアップの種類 完全、差分、ログ。 PITR バックアップの geo レプリケートされた最新コピー。 完全バックアップのみ。
目標復旧時点 (RPO) コンピューティング サイズとデータベース アクティビティの量に基づいて、10 分。 geo レプリケーションに基づいて最大 1 時間。 1 1 週間 (またはユーザーのポリシー)。
目標復旧時間 (RTO) 復元に要する時間は通常、12 時間未満ですが、サイズとアクティビティによってはさらに時間が長くなる場合もあります。 復元に関する記事を参照してください。 復元に要する時間は通常、12 時間未満ですが、サイズとアクティビティによってはさらに時間が長くなる場合もあります。 復元に関する記事を参照してください。 復元に要する時間は通常、12 時間未満ですが、サイズとアクティビティによってはさらに時間が長くなる場合もあります。 復元に関する記事を参照してください。
保持 既定では 7 日間ですが、1 日から 35 日の範囲で構成できます (Basic データベースを除き、1 日から 7 日の間で構成できます)。 ソースと同じく、既定で有効になっています。2 既定では有効になっていません。 保有期間は最大 10 年です。
Azure ストレージ 既定では geo 冗長です。 必要に応じて、ゾーン冗長またはローカル冗長ストレージを構成できます。 PITR バックアップ ストレージの冗長性が geo 冗長に設定されている場合に使用できます。 PITR バックアップ ストレージがゾーン冗長またはローカル冗長の場合は使用できません。 既定では geo 冗長です。 ゾーン冗長またはローカル冗長ストレージを構成できます。
バックアップを不変として設定する サポート対象外 サポート対象外 サポート対象外
同じリージョンでの新しいデータベースの復元 サポート対象 サポート対象 サポート対象
別のリージョンでの新しいデータベースの復元 サポート対象外 任意の Azure リージョンでサポートされています 任意の Azure リージョンでサポートされています
別のサブスクリプションでの新しいデータベースの復元 サポート対象外 サポート対象外3 サポート対象外3
Azure portal を使用した復元 はい イエス はい
PowerShell を使用した復元 はい イエス はい
Azure CLI を使用した復元 はい イエス はい

1 大規模なデータベースを必要とし、ビジネス継続性を保証する必要があるビジネス上不可欠なアプリケーションの場合は、フェールオーバー グループを使用します。
2 すべての PITR バックアップは、既定で geo 冗長ストレージに格納されるため、geo リストアは既定で有効になっています。
3 回避策は、新しいサーバーに復元し、Resource Move を使用してサーバーを別のサブスクリプションに移動するか、サブスクリプション間のデータベース コピーを使用することです。

バックアップからデータベースを復元する

復元を行う場合は、バックアップからのデータベースの復元に関するページを参照してください。 次の例を使用して、バックアップの構成と復元の操作を調べることができます。

操作 Azure portal Azure CLI Azure PowerShell
バックアップ保有期間を変更する SQL Database
SQL Managed Instance		 SQL Database
SQL Managed Instance		 SQL Database
SQL Managed Instance
長期的なバックアップ保有期間を変更する SQL Database
SQL Managed Instance		 SQL Database
SQL Managed Instance		 SQL Database
SQL Managed Instance
特定の時点からデータベースを復元する SQL Database
SQL Managed Instance		 SQL Database
SQL Managed Instance		 SQL Database
SQL Managed Instance
削除されたデータベースの復元 SQL Database
SQL Managed Instance		 SQL Database
SQL Managed Instance		 SQL Database
SQL Managed Instance

データベースのエクスポート

Azure サービスによって作成された自動バックアップは、直接ダウンロードまたはアクセスすることはできません。 これらは、Azure を介した復元操作にのみ使用できます。

Azure SQL データベースをエクスポートする代替手段もあります。 アーカイブのため、または別のプラットフォームに移行するためにデータベースをエクスポートする必要がある際は、データベース スキーマとデータを BACPAC ファイルにエクスポートできます。 BACPAC ファイルは、データベースのメタデータとデータを含む BACPAC の拡張子を持つ ZIP ファイルです。 BACPAC ファイルは、Azure の BLOB ストレージまたはオンプレミスの場所にあるローカル ストレージに格納でき、後で Azure SQL Database、Azure SQL Managed Instance、または SQL Server インスタンスにインポートすることができます。

プライベート リンクを使用して Azure SQL データベースをインポートまたはエクスポートする、または Azure サービスにサーバーへのアクセスを許可せずに Azure SQL データベースをインポートまたはエクスポートすることもできます。

バックアップのスケジュール設定

初回の完全バックアップは、新しいデータベースの作成または復元の直後にスケジュールされます。 通常このバックアップは 30 分以内に終了しますが、データベースが大きい場合はそれ以上かかることがあります。 たとえば、復元されたデータベースまたはデータベースのコピーでは、初期バックアップに時間がかかる場合があり、通常は新しいデータベースより大きくなります。

初回の完全バックアップ以降のすべてのバックアップは、自動的にスケジュールおよび管理されます。 データベースのバックアップの正確なタイミングは、全体的なシステムのワークロードのバランスを図りながら SQL Database サービスによって決定されます。 バックアップ ジョブのスケジュールを変更したり、無効にしたりすることはできません。

重要

  • 新しいデータベース、復元されたデータベース、またはコピーされたデータベースの場合、特定の時点への復元機能は、最初の完全バックアップの後で最初のトランザクション ログ バックアップが作成されたときに使用できるようになります。
  • Hyperscale データベースは、初期バックアップに時間がかかる他のデータベースとは異なり、作成直後に保護されます。 コピーまたは復元によって大量のデータを使用して Hyperscale データベースが作成された場合でもすぐに保護されます。 詳細については、Hyperscale の自動バックアップに関するページを参照してください。

バックアップ ストレージ消費量

SQL Server のバックアップと復元のテクノロジでは、特定の時点にデータベースを復元するには、中断のないバックアップ チェーンが必要です。 このチェーンは 1 回の完全バックアップ、1 回の差分バックアップ (任意)、1 回または複数回のトランザクション ログ バックアップで構成されます。

Azure SQL Database では、毎週 1 回の完全バックアップがスケジュールされます。 保有期間全体で PITR を提供にするには、構成されている保有期間より最大で 1 週間長い期間の追加の完全、差分、およびトランザクション ログ バックアップをシステムで格納する必要があります。

つまり、保有期間中の任意の時点において、保有期間の最も古い時点より古い完全バックアップが存在する必要があります。 また、その完全バックアップから次の完全バックアップまでの差分とトランザクション ログ バックアップの中断されていないチェーンが存在する必要があります。

Hyperscale データベースでは、別のバックアップ スケジュール メカニズムが使用されます。 詳細については、Hyperscale バックアップのスケジュール設定に関するページを参照してください。

PITR 機能を提供するために必要なくなったバックアップは、自動的に削除されます。 差分バックアップとログ バックアップでは先行する完全バックアップが復元可能である必要なため、3 つのバックアップの種類すべてが毎週まとめて消去されます。

TDE で暗号化されたデータベースを含むすべてのデータベースでは、バックアップ ストレージの圧縮とコストを減らすためにすべての完全および差分バックアップが圧縮されます。 バックアップの平均圧縮率は 3 から 4 倍です。 しかし、データの性質や、データベースでデータ圧縮が使用されているかどうかにより、低くなったり高くなったりする可能性があります。

重要

TDE で暗号化されたデータベースの場合、ログ バックアップ ファイルはパフォーマンス上の理由から圧縮されません。 TDE で暗号化されていないデータベースのログ バックアップは圧縮されます。

Azure SQL Database では、バックアップ ストレージの合計が累積値として計算されます。 この値は 1 時間ごとに Azure 課金パイプラインに報告されます。 この時間あたりの使用量がパイプラインによって集計されて、毎月末に消費量が計算されます。 データベースの削除後は、バックアップが古くなって削除されると共に消費量が減少します。 すべてのバックアップが削除されて、PITR が不可能になると、課金は停止します。

重要

データベースが削除された場合でも、データベースのバックアップは PITR を提供するために保持されます。 データベースを削除して再作成すると、ストレージとコンピューティング コストが節約される場合がありますが、バックアップ ストレージのコストが増加する可能性があります。 その理由は、削除されるたびに、削除された各データベースのバックアップがサービスによって保持されるためです。

消費量の監視

Azure SQL Database の仮想コア データベースの場合、各種バックアップ (完全、差分、ログ) で消費されるストレージは、データベース監視ペイン上で別個のメトリックとして報告されます。 次のスクリーンショットには、単一データベースのバックアップ ストレージ消費量の監視方法が示されています。

Azure portal でデータベース バックアップ消費量を監視するための選択を示すスクリーンショット。

Hyperscale の消費量を監視する方法については、「Hyperscale バックアップの消費を監視する」を参照してください。

バックアップ ストレージ消費量を微調整する

データベースの最大データ サイズまでのバックアップ ストレージの使用量については、課金されません。 超過のバックアップ ストレージ消費量は、個々のデータベースのワークロードと最大サイズに依存します。 バックアップ ストレージ消費量を減らすには、次の調整手法のいくつかを検討してください。

  • 必要最小限までバックアップ保有期間を短縮します。
  • インデックスの再構築などの大規模な書き込み操作を、必要以上に頻繁に行わないようにします。
  • 大規模なデータ読み込み操作の場合、クラスター化された列ストア インデックスを使用して、関連するベスト プラクティスに従うことを検討します。 また、非クラスター化インデックスの数を減らすことを検討します。
  • 汎用サービス レベルでは、プロビジョニングされたデータ ストレージの方が、バックアップ ストレージの価格よりも安価です。 超過のバックアップ ストレージのコストが継続的に増加している場合は、データ ストレージを増やしてバックアップ ストレージを節約することを検討してください。
  • 一時的な結果やデータの保存には、アプリケーションのロジックでの永続的テーブルではなく tempdb を使用します。
  • 可能な限り (Dev/Test 環境など) ローカル冗長バックアップ ストレージを使用します。

バックアップ保持期間

Azure SQL Database では、バックアップの短期保有と長期保有 (LTR) の両方が提供されます。 短期保有では、データベースの保有期間内に PITR を使用できます。 長期保有では、さまざまなコンプライアンス要件に応じてバックアップが提供されます。

短期保有

新しいデータベース、復元されたデータベース、コピーされたデータベースのすべてについて、Azure SQL Database では、既定で過去 7 日間の PITR が可能な十分なバックアップが保持されます。 データベースに対して定義された保有期間内の任意の時点に確実にデータベースを復元できるようにするために、サービスでは定期的な完全、差分、およびログ バックアップが作成されます。

差分バックアップは、12 時間に 1 回または 24 時間に 1 回実行するように構成できます。 24 時間の差分バックアップ頻度では、12 時間の頻度と比較して、データベースの復元に必要な時間が長くなる可能性があります。 仮想コア モデルでは、差分バックアップの既定の頻度は 12 時間に 1 回です。 DTU モデルでは、既定の頻度は 24 時間に 1 回です。

データベースの作成時に STR のバックアップ ストレージの冗長性オプションを指定し、後で変更できます。 データベースの作成後にバックアップ冗長性オプションを変更した場合、新しいバックアップでは新しい冗長性オプションが使用されます。 前の STR 冗長性オプションで作成されたバックアップ コピーは移動もコピーもされません。 保有期間の有効期限 (1 日から 35 日に指定可能) が切れるまで、元のストレージ アカウントに残されます。

1 ～ 7 日の範囲で構成可能な Basic データベースを除き、1 日から 35 日の範囲で、アクティブなデータベースごとにバックアップ保持期間を変更できます。 「バックアップ ストレージ消費量」で説明されているように、PITR を有効にするために格納されているバックアップは、保有期間より古い場合があります。 短期保有期間の最大値である 35 日より長くバックアップを保持する必要がある場合は、長期保有を有効にすることができます。

データベースを削除した場合、システムでは、オンライン データベースと同じ方法で、特定の保有期間のバックアップが保持されます。 削除されたデータベースのバックアップ保有期間を変更することはできません。

重要

サーバーを削除すると、そのサーバー上のデータベースもすべて削除され、復旧できなくなります。 削除されたサーバーを復元することはできません。 しかし、データベースの長期保有期間を構成した場合、LTR バックアップは削除されません。 その後、これらのバックアップを使用して、LTR バックアップが作成された時点まで、同じサブスクリプション内の別のサーバー上のデータベースを復元できます。 詳細については、長期バックアップの復元に関する記述を参照してください。

長期保存

SQL Database では、Azure Blob Storage で最大 10 年間、長期保有 (LTR) の完全バックアップを構成できます。 LTR ポリシーを構成すると、週に 1 回、完全バックアップが自動的に別のストレージ コンテナーにコピーされます。

各種のコンプライアンス要件を満たすために、毎週、毎月、毎年の完全バックアップに対してさまざまな保有期間を選択できます。 頻度はポリシーによって異なります。 たとえば、W=0, M=1 を設定すると、毎月 LTR コピーが作成されます。 LTR の詳細については、長期保有に関するページを参照してください。

既存のデータベースのバックアップ ストレージの冗長性を更新すると、変更は今後作成される後続のバックアップにのみ適用され、既存のバックアップには適用されません。 データベースのすべての既存の LTR バックアップは、既存のストレージ BLOB に引き続き存在します。 新しいバックアップは、構成されたバックアップ ストレージの冗長性に基づいてレプリケートされます。

ストレージの使用量は、LTR バックアップについて選択した頻度と保持期間によって異なります。 LTR ストレージのコストは、LTR 料金計算ツールを使用して見積もることができます。

Hyperscale データベースを LTR バックアップから復元する場合、読み取りスケール プロパティは無効になります。 復元されたデータベースの読み取りスケールを有効にするには、データベースが作成された後にデータベースを更新します。 LTR バックアップから復元する場合は、ターゲットのサービス レベル目標を指定する必要があります。

長期保有は、他のサービス レベルから作成または移行された Hyperscale データベースに対して有効にできます。 まだサポートされていない Hyperscale データベースに対して LTR を有効にしようとすると、次のエラーが表示されます。「このデータベースに長期バックアップ保持を有効化時にエラーが発生しました。 長期的なバックアップ保持期間を有効にするには、Microsoft サポートにお問い合わせください。」この場合は、Microsoft サポートに連絡し、解決するためのサポート チケットを作成します。

バックアップ ストレージのコスト

バックアップ ストレージの価格は、購入モデル (DTU または仮想コア)、選択したバックアップ ストレージ冗長性オプション、およびリージョンによって異なります。 バックアップ ストレージは、すべてのバックアップで同じ割合で、1 か月あたりに消費されたギガバイトに基づいて課金されます。

バックアップ ストレージの冗長性は、バックアップ コストに次のように影響します。

  • Locally redundant price = published price
  • Zone-redundant price = published price x 1.25
  • Geo-redundant price = published price x 2

価格設定については、Azure SQL Database の価格に関するページをご覧ください。

注意

Azure 請求書では、バックアップ ストレージの全体の消費量ではなく、バックアップ ストレージの超過分の消費量のみが表示されます。 たとえば、仮に 4 TB のデータ ストレージをプロビジョニングした場合、4 TB の無料のバックアップ ストレージ領域が得られます。 合計 5.8 TB のバックアップ ストレージ領域を使用する場合、Azure 請求書には 1.8 TB のみが表示されます。これは、使用したバックアップ ストレージの超過分に対してのみ課金されるためです。

DTU モデル

DTU モデルのデータベースとエラスティック プールについては、既定の保持期間の 7 日以上に対して PITR バックアップ ストレージの追加料金は発生しません。 PITR バックアップ ストレージの価格は、データベースまたはプールの価格の一部です。

重要

DTU モデルでのデータベースとエラスティック プールは、LTR バックアップによって消費された実際のストレージに基づき、LTR バックアップ ストレージに対して課金されます。

仮想コア モデル

Azure SQL Database では、課金対象の合計バックアップ ストレージは、すべてのバックアップ ファイルの累積値として計算されます。 この値は 1 時間ごとに Azure 課金パイプラインに報告されます。 パイプラインでは、この時間あたりの使用量が集計されて、毎月末にバックアップ ストレージの消費量が算出されます。

データベースが削除されると、古いバックアップが期限切れになって削除されるに従い、バックアップ ストレージの使用量は徐々に減少します。 差分バックアップとログ バックアップでは先行する完全バックアップが復元可能である必要なため、3 つのバックアップの種類すべてが毎週まとめて消去されます。 すべてのバックアップが削除された後、課金は停止します。

Hyperscale データベースのバックアップ ストレージ コストの計算方法は異なります。 詳細については、「Hyperscale バックアップ ストレージのコスト」を参照してください。

単一データベースの場合は、データベースの最大データ ストレージ サイズの 100% に等しいバックアップ ストレージ容量が、追加料金なしで提供されます。 課金対象のバックアップ ストレージ合計使用量の計算には、次の式が使用されます。

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

エラスティック プールの場合は、プール ストレージ サイズの最大データ ストレージの 100% に等しいバックアップ ストレージ容量が、追加料金なしで提供されます。 プールされたデータベースの場合、課金対象のバックアップ ストレージの合計サイズはプール レベルで集計され、次のように計算されます。

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

課金対象のバックアップ ストレージの合計 (存在する場合) は、使用したバックアップ ストレージの冗長性の割合に応じて、1 か月あたりのギガバイト単位で課金されます。 このバックアップ ストレージ消費量は、個々のデータベース、エラスティック プール、マネージド インスタンスのワークロードとサイズに依存します。 差分バックアップとログ バックアップのサイズはデータの変更量に比例するため、大幅に変更されたデータベースでは、これらのバックアップが大きくなります。 したがって、そのようなデータベースではバックアップ料金が高くなります。

簡単な例として、データベースのバックアップ ストレージが累積で 744 GB になり、データベースは完全にアイドル状態であるため、この量は 1 か月を通して変わらないものとします。 この累積ストレージ消費量を 1 時間あたりの使用量に変換するには、744.0 (1 か月 31 日 * 1 日 24 時間) で割ります。 SQL Database では、データベースで 1 時間あたり 1 GB の PITR バックアップが一定の割合で消費されたことが、Azure 課金パイプラインに報告されます。 Azure の課金では、この消費量を集計し、1 か月全体で 744 GB という使用量が示されます。 コストは、リージョンでの 1 か月あたりのギガバイトの割合に基づきます。

次に別の例を示します。 同じアイドル状態のデータベースで、保有期間が月の途中で 7 日から 14 日間に増やされたとします。 この増加により、バックアップ ストレージの合計は 1,488 GB に倍増します。 SQL Database では、1 時間から 372 時間まで (月の前半) の使用量が 1 GB と報告されます。 373 時間から 744 時間まで (月の後半) の使用量は 2 GB と報告されます。 この使用量が集計されて最終的な請求は、1 か月あたり 1,116 GB になります。

実際のバックアップの課金シナリオはさらに複雑です。 データベース内の変更の割合はワークロードに依存し、時間の経過と共に変化するので、各差分およびログ バックアップのサイズも変化します。 バックアップ ストレージの時間単位の消費量はそれに応じて変動します。

各差分バックアップには、前回の完全バックアップ以降にデータベースで行われたすべての変更も含まれます。 そのため、すべての差分バックアップの合計サイズは、1 週間の間に徐々に増加します。 その後、完全、差分、およびログ バックアップの古いセットが期限切れになった後、急激に減少します。

たとえば、インデックスの再構築などの大量の書き込みアクティビティが、完全バックアップが完了した直後に実行されるとします。 その後、インデックスの再構築によって行われる変更が以下に含まれます。

  • 再構築の間に作成されるトランザクション ログ バックアップ。
  • 次の差分バックアップ。
  • 次の完全バックアップが実行されるまでに作成されるすべての差分バックアップ。

大規模なデータベースにおける最後のシナリオでは、そうしないと差分バックアップが過剰に大きくなる場合は、サービスの最適化によって差分バックアップではなく完全バックアップが作成されます。 これにより、次の完全バックアップまで、すべての差分バックアップのサイズが小さくなります。

「消費量の監視」で説明されているように、各バックアップの種類 (完全、差分、トランザクション ログ) の合計バックアップ ストレージ消費量を、時間を追って監視できます。

コストを監視する

バックアップ ストレージのコストを把握するには、Azure portal の [コストの管理と請求] に移動します。 [コスト管理] を選択してから、[コスト分析] を選択します。 [スコープ] で必要なサブスクリプションを選択してから、以下のように目的の期間とサービスが得られるようにフィルター処理します。

  1. [サービス名] のフィルターを追加します。

  2. ドロップダウン リストで、単一データベースまたはエラスティック データベース プールの [SQL Database] を選択します。

  3. [測定サブカテゴリ] の別のフィルターを追加します。

  4. PITR バックアップのコストを監視するには、ドロップダウン リストで、単一データベースまたはエラスティック データベース プールの [単一/エラスティック プール PITR バックアップ ストレージ] を選択します。 測定値は、バックアップ ストレージの消費量が存在する場合にのみ表示されます。

    LTR バックアップのコストを監視するには、ドロップダウン リストで、単一データベースまたはエラスティック データベース プールの [LTR バックアップ ストレージ] を選択します。 測定値は、バックアップ ストレージの消費量が存在する場合にのみ表示されます。

[ストレージ] と [コンピューティング] のサブカテゴリも必要に応じて使用できますが、これらはバックアップ ストレージのコストに関連付けられていません。

バックアップ ストレージ コストの分析を示すスクリーンショット。

重要

測定値は、現在使用中のカウンターについてのみ表示されます。 カウンターが利用できない場合、そのカテゴリが現在使用されていないと考えられます。 たとえば、ストレージを消費していないリソースについては、ストレージ カウンターは表示されません。 PITR や LTR バックアップ ストレージの消費量がない場合、これらの測定値は表示されません。

詳細については、Azure SQL Database のコスト管理に関するページを参照してください。

暗号化バックアップ

データベースが TDE で暗号化されている場合、LTR バックアップを含むバックアップは保存中に自動的に暗号化されます。 Azure SQL のすべての新しいデータベースでは、既定で TDE が有効に構成されます。 TDE の詳細については、「SQL Database での Transparent Data Encryption」を参照してください。

バックアップの整合性

Azure SQL のエンジニアリング チームは、自動データベース バックアップに対する復元の自動テストを継続的に行っています。 ポイントインタイム リストア時に、データベースは DBCC CHECKDB の整合性チェックも受けます。

整合性チェック中に問題が見つかると、エンジニアリング チームにアラートが示されます。 詳細については、SQL Database でのデータ整合性に関するページを参照してください。

すべてのデータベース バックアップは、バックアップの整合性を高めるために、CHECKSUM オプションを使用して実行されます。

コンプライアンス

DTU ベースのサービス レベルから仮想コア ベースのサービス レベルにデータベースを移行した場合、アプリケーションのデータ回復ポリシーに違反しないように、PITR 保有期間が維持されます。 既定の保有期間がコンプライアンス要件を満たしていない場合は、PITR 保有期間を変更できます。 詳細については、「PITR バックアップ保有期間を変更する」を参照してください。

注意

この「自動バックアップ設定を変更する」記事は、デバイスまたはサービスから個人データを削除する手順について説明しており、GDPR の下で義務を果たすために使用できます。 GDPR に関する一般情報については、Microsoft Trust Center の GDPR に関するセクションおよび Service Trust Portal の GDPR に関するセクションをご覧ください。

Azure Policy を使用してバックアップ ストレージの冗長性を適用する

すべてのデータを 1 つの Azure リージョンに保持する必要があるデータ所在地の要件がある場合は、Azure Policy を使用して、SQL Database に対してゾーン冗長またはローカル冗長のバックアップを適用することができます。

Azure Policy は、Azure リソースにルールを適用するポリシーの作成、割り当て、管理に使用できるサービスです。 Azure Policy は、これらのリソースが会社の標準やサービス レベル アグリーメントに準拠した状態を維持するのに役立ちます。 詳細については、Azure Policy の概要に関するページを参照してください。

バックアップ ストレージの冗長性の組み込みポリシー

組織レベルでデータ所在地の要件を適用するために、Azure portal または Azure PowerShell を使用してサブスクリプションにポリシーを割り当てることができます。

たとえば、"Azure SQL DB は GRS バックアップの使用を避ける必要があります" というポリシーを有効にした場合、デフォルトのストレージをグローバル冗長ストレージとして使用してデータベースを作成することはできません。また、ユーザーは、"データベースの作成または更新中にバックアップ ストレージ アカウントの種類を 'Standard_RAGRS' に構成できませんでした" というエラー メッセージが表示され GRS を使用できなくなります。

SQL Database の組み込みポリシー定義の完全な一覧については、ポリシー リファレンスを参照してください。

重要

T-SQL を使用してデータベースを作成する場合、Azure ポリシーは適用されません。 T-SQL を使用してデータベースを作成するときにデータ所在地を指定するには、CREATE DATABASE ステートメントの BACKUP_STORAGE_REDUNDANCY パラメーターに対する入力として LOCAL または ZONE を使用します。

関連するコンテンツ