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

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

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

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

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

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

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

バックアップ頻度

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

• 毎週の完全バックアップ。
• 12 時間または 24 時間ごとの差分バックアップ。
• 約 10 分ごとのトランザクション ログ バックアップ。

トランザクションログバックアップの正確な頻度は、計算量やデータベース活動量によって異なります。 データベースを復元すると、Azure SQL Databaseはどの完全なバックアップ、差分ログ、トランザクションログのバックアップを復元するかを決定します。

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

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

ストレージ冗長性の仕組みは複数のデータを保存するため、計画的・予期せぬ出来事から保護されます。 このようなイベントには、一時的なハードウェアの障害、ネットワークの停止や停電、大規模な自然災害が含まれる場合があります。

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

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

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

バックアップがデータベースが展開されている同じリージョン内に留まるために、バックアップストレージの冗長性をデフォルトの地理的冗長ストレージから、データをリージョン内に保持する他のストレージに変更してください。 構成されたバックアップ ストレージの冗長性は、短期保有 (STR) バックアップと LTR バックアップの両方に適用されます。 ストレージの冗長性について詳しくは、「データの冗長性」を参照してください。

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

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

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

  

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

  

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

  結果は次のとおりです。

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

  

• Geo-Zone 冗長ストレージ (GZRS): geo ゾーン冗長ストレージ (GZRS) は、可用性ゾーン (ZRS) 全体の冗長性によって提供される高可用性と、geo レプリケーション (GRS) によって提供されるリージョンの停止からの保護を組み合わせたものになります。 GZRSでは、Azureはプライマリリージョン内の3つのAzure可用性ゾーン間でバックアップを同期的にコピーし、ペアリングされたセカンダリリージョン内の1つの物理的な場所には非同期で3回コピーします。

  最大限の一貫性、持続性、高可用性、優れたパフォーマンス、ディザスター リカバリーのための回復性を必要とするアプリケーションに対しては、GZRS を使用することをお勧めします。

  結果は次のとおりです。

  • プライマリリージョン内のアベイラビリティゾーン間で同期された3つのコピー。

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

    次の図は、GZRS または RA-GZRS を使用した、データのレプリケーション方法を示しています。

  

バックアップの用途

以下のシナリオで自動作成されたバックアップを使用します:

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

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

• 削除の時点など、保有期間内の特定の時点に削除されたデータベースを復元します。 元のデータベースを作成した同じサーバー上でのみ、削除されたデータベースを復元できます。 データベースを削除する前に、Azure SQL Databaseは最終的なトランザクションログバックアップを取り、データの損失を防ぎます。

• 別の地理的リージョンにデータベースを復元する。 ジオリストアは、主要な地域のデータベースやバックアップにアクセスできない地域障害からの復旧を支援します。 任意の Azure リージョンの既存のサーバーに新しいデータベースが作成されます。

  重要

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

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

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

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

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

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

機能と特徴を復元する

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

回復時間の詳細については、RTO と RPOを参照してください。

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

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

データベースの復元に関する詳細は「 バックアップからデータベースを復元する」をご覧ください。 バックアップ設定や復元操作を探るには、以下の例をご利用ください。

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

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

Azure SQL Databaseをエクスポートするには、他の代替案を検討してください。

• アーカイブや他のプラットフォームへの移行のためにデータベースをエクスポートする必要がある場合は、データベースのスキーマとデータをBACPACファイルにエクスポートしてください。 BACPAC ファイルは、データベースのメタデータとデータを含む BACPAC の拡張子を持つ ZIP ファイルです。 BACPACファイルはAzure Blobストレージに保存するか、オンプレミスのローカルストレージに保存できます。 後で、Azure SQL Database、Azure SQL Managed Instance、またはSQL Serverインスタンスにインポートすることも可能です。
• プライベート リンクを使用して Azure SQL データベースをインポートまたはエクスポートする、または Azure サービスにサーバーへのアクセスを許可せずに Azure SQL データベースをインポートまたはエクスポートすることもできます。

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

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

最初の完全バックアップの後、Azureは自動的にすべてのバックアップをスケジュールし管理します。 SQLデータベースサービスは、システム全体のワークロードをバランス調整することで、すべてのデータベースバックアップの正確なタイミングを決定します。 バックアップ ジョブのスケジュールを変更したり、無効にしたりすることはできません。

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

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

Azure SQL Database では、毎週 1 回の完全バックアップがスケジュールされます。 保持期間全体でPITRを提供するためには、Azureは設定された保持期間より最大1週間長く、追加のフル、差分、トランザクションログバックアップを保存しなければなりません。

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

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

Azureは、PITR機能を提供するために不要になったバックアップを自動的に削除します。 差分バックアップとログ バックアップは、以前の完全バックアップがなければ復元できないため、Azure では 3 種類すべてのバックアップを週単位のセットとしてまとめて削除します。

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

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

消費量の監視

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

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

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

データベースの最大データサイズまでのバックアップストレージ使用量については料金がかかりません。 バックアップストレージの消費を削減するために、以下のチューニング技術を検討してみてください:

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

バックアップ保持期間

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

短期保有

新規、復元、コピーされたすべてのデータベースに対して、Azure SQL Databaseは過去7日以内のPITRをデフォルトで許可する十分なバックアップを保持しています。 Azure SQL Databaseは、データベースが保持期間内の任意の時点に復元可能であることを保証するために、定期的にフルバックアップ、差分バックアップ、ログバックアップを受け付けます。

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

データベースを作成する際にSTRのバックアップストレージ冗長オプションを指定し、後で変更できます。 既存のデータベースでバックアップ冗長オプションを変更すると、新しいバックアップもその冗長オプションを使用します。 Azureは、以前の短期冗長オプションで作成されたバックアップコピーを移動したりコピーしたりしません。 Azure は、それらを保持期間が満了するまで元のストレージ アカウントに残します。保持期間は 1 日から 35 日までです。

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

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

長期保存

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

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

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

ストレージの使用量は、LTR バックアップについて選択した頻度と保持期間によって異なります。 LTRの価格計算機を使ってLTRストレージのコストを見積もってください。

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

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

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

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

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

DTU モデル

DTUモデルでは、データベースやエラスティックプールの場合、デフォルトで7日以上保持するPITRバックアップストレージに追加料金はありません。 PITRバックアップストレージの価格はデータベースまたはプール価格の一部です。

DTU モデルでは、データベースおよびエラスティック プールの LTR バックアップ ストレージについて、LTR バックアップが実際に消費したストレージ量に基づいて料金を支払います。

仮想コア モデル

Azure SQL Databaseは、すべてのバックアップファイル全体の合計値として請求可能なバックアップストレージを計算します。 Azureは毎時間この値を請求パイプラインに送信します。 パイプラインはこの時間あたりの使用量を集計し、毎月末のバックアップストレージ消費量を算出します。

データベースを削除すると、古いバックアップが古くなって削除されるにつれて、バックアップストレージの使用量は徐々に減少します。 差分バックアップとログ バックアップは、以前の完全バックアップがなければ復元できないため、Azure では 3 種類すべてのバックアップを週単位のセットとしてまとめて削除します。 すべてのバックアップが削除された後、課金は停止します。

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

単一のデータベースでは、追加料金なしでデータベースの最大データ容量に等しいバックアップストレージ容量が提供されます。 以下の式は、請求可能なバックアップストレージの総使用量を計算しています:

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

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

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

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

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

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

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

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

たとえば、インデックスの再構築などの大量の書き込みアクティビティが、完全バックアップが完了した直後に実行されるとします。 インデックス再構築で加えられる修正は以下の通りです:

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

最後のケースでは、より大きなデータベースの場合、Azureでの最適化により差分バックアップではなく完全なバックアップが作成されます。そうでなければ差分バックアップが過剰に大きくなる場合に備えます。 この最適化により、次の完全なバックアップまでの差分バックアップのサイズが削減されます。

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

コストを監視する

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

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

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

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

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

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

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

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

暗号化バックアップ

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

バックアップの整合性

Azure SQL Databaseは、必要に応じて組み込み技術を用いて特定の種類のデータ破損を自動的に処理し、データ損失はありません。 Azure SQL Databaseでは、SQL データベース エンジンがサービス管理バックアップおよび各復元操作中にページ検証を行います。 整合性チェック中に問題が見つかると、エンジニアリング チームにアラートが示されます。

追加の保護層として、バックアップ復元のテストや完全性チェックを行うことができます。 詳細については、Azure SQL Databaseのデータ整合性をご覧ください。

すべてのデータベースバックアップは、追加のバックアップ整合性を提供するために CHECKSUM オプションを使用します。

バックアップの保護

Microsoft所有のAzureサブスクリプションは、安全な内部Azure Storageアカウントを使ってAzure SQL Databaseのバックアップを管理します。 これらのバックアップは外部からアクセスできないため、強力なデータ隔離と保護を提供します。 Microsoft内では、これらのバックアップへのアクセス、作成、コピー、復元が可能なのはバックエンドサービスだけです。 開発者を含む Microsoft のエンジニアは、永続的なアクセス権を持っていません。 公開を最小限に抑え、セキュリティを最大限に高めるために、Microsoft は、特定の顧客の問題のトラブルシューティングに絶対に必要な場合にのみ、厳密な監査制御の下で Just-In-Time (JIT) アクセスを取得できます。

保存期間が終了すると、バックアップは自動的に削除されます。

バックアップ保持期間を通じたコンプライアンス

デフォルトの保持期間がコンプライアンス要件を満たしていない場合は、PITRの保持期間を変更してください。 詳細については、「PITR バックアップ保有期間を変更する」を参照してください。

DTUベースのサービス層からvCoreベースのサービス層にデータベースを移行すると、移行によってPITRの保持が維持され、アプリケーションのデータ復旧ポリシーが損なわれないようにします。

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

もしデータレジデンシー要件ですべてのデータを単一のAzureリージョンに保持する必要がある場合は、Azure Policyを使ってSQLデータベースのゾーン冗長またはローカル冗長バックアップを強制できます。

Azure Policy は、Azure リソースにルールを適用するポリシーの作成、割り当て、管理に使用できるサービスです。 Azure Policyは、これらのリソースを企業の標準やサービスレベル契約に準拠させるのに役立ちます。 詳細については、Azure Policy の概要に関するページを参照してください。

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

組織レベルでデータレジデンシー要件を強制するには、AzureポータルまたはAzure PowerShellを使ってサブスクリプションにポリシーを割り当てます。

例えば、「Azure SQL DBはGRSバックアップの使用を避けるべき」というポリシーを有効にすると、ユーザーはデフォルトのストレージをグローバル冗長ストレージとしてデータベース作成できません。 このポリシーはユーザーのGRS使用を妨げ、「バックアップストレージアカウントタイプを'Standard_RAGRS'に設定する際にデータベース作成または更新中に失敗しました」というエラーメッセージを返します。

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

関連するコンテンツ

• その他の SQL Database ビジネス継続性ソリューションについては、ビジネス継続性の概要に関するページを参照してください。
• バックアップの設定を変更する場合は、設定の変更に関するページを参照してください。
• バックアップを復元する場合は、バックアップを使用した復旧または PowerShell を使用した特定の時点へのデータベースの復元に関するページを参照してください。
• Azure Blob Storage に長期保有される自動バックアップを構成、管理、復元する方法については、長期バックアップ保有期間の管理に関するページを参照してください。
• Azure SQL Managed Instance については、「SQL Managed Instance の自動バックアップ」を参照してください。