Azure Cosmos DB のポイントインタイム リストアを使用した継続的バックアップ

適用対象: NoSQL MongoDB Gremlin Table

Azure Cosmos DB のポイントインタイム リストア機能は、次のような複数のシナリオで役立ちます。

• コンテナー内で誤って行われた書き込みまたは削除の操作から復旧する。
• 削除されたアカウント、データベース、またはコンテナーを復元する。
• 特定の復元ポイントで (バックアップが存在していた) 任意のリージョンに復元する。

Azure Cosmos DB では、データのバックアップがバックグラウンドで実行され、プロビジョニング済みのスループット (RU) を余計に消費することも、データベースのパフォーマンスや可用性に影響することもありません。 継続的バックアップは、アカウントが存在するすべてのリージョンで実行されます。 たとえば、アカウントは米国西部に書き込みリージョンを持ち、米国東部と米国東部 2 に読み取りリージョンを持つことができます。 その後、これらのレプリカ リージョンは、それぞれのリージョン内のリモート Azure Storage アカウントにバックアップできます。 既定の場合、各リージョンではバックアップがローカル冗長ストレージ アカウントに格納されます。 リージョンで可用性ゾーンが有効になっている場合、バックアップはゾーン冗長ストレージ アカウントに格納されます。

米国西部に書き込みリージョンがあり、米国東部と米国東部 2 に読み取りリージョンがあるコンテナーがバックアップされる方法を示す図。 コンテナーは、書き込みと読み取りのそれぞれのリージョン内にあるリモート Azure Blob Storage アカウントにバックアップされます。

復元に使用できる時間枠 (保持期間とも呼ばれます) は、30 日と 7 日の 2 つのオプションのうち低い方の値です。

選択されるオプションは、継続的バックアップで選択したレベルによって異なります。 復元の時点は、リソースが作成された時点までの、保持期間内の任意のタイムスタンプにすることができます。 厳密な整合性モードでは、書き込みリージョンで作成されるバックアップは、読み取りリージョンと比べてさらに新しいものです。 読み取りリージョンは、ネットワークや他の一時的な問題が原因で遅延する可能性があります。 復元の実行中に、特定のリージョン内の指定されたリソースの最新の復元可能なタイムスタンプを取得できます。 復元可能な最新のタイムスタンプを参照すると、リソースのバックアップが指定されたタイムスタンプまでであること、そのリージョンで復元できることを確認するのに役立ちます。

現在、特定の時点の Azure Cosmos DB アカウント (NoSQL または MongoDB 用 API、Table 用 API、Gremlin 用 API) の内容を別のアカウントに復元できます。 この復元操作は、Azure portal、Azure CLI (Azure CLI)、Azure PowerShell、または Azure Resource Manager テンプレートを使用して実行できます。

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

既定では、Azure Cosmos DB は、連続モードのバックアップ データをローカル冗長ストレージ BLOB に格納します。 ゾーン冗長が構成されているリージョンでは、バックアップはゾーン冗長ストレージ BLOB に格納されます。 継続的バックアップ モードでは、バックアップ ストレージの冗長性を更新することはできません。

復元する各種の方法

継続的バックアップ モードでは、削除されたコンテナーとデータベースを復元する 2 つの方法がサポートされています。 こちらに記載されているように新しいアカウントに復元するか、こちらで説明されているように既存のアカウントに復元することができます。 これら 2 つのモードのどちらを選ぶかは、シナリオによって異なります。 ほとんどの場合、削除されたコンテナーとデータベースを既存のアカウントに復元することをお勧めします。 こうすることで、新しいアカウントに復元する場合に必要となるデータ転送のコストを回避できます。 誤ってデータが変更されたシナリオでは、新しいアカウントへの復元が推奨されるオプションになる可能性があります。

マルチ リージョン書き込みアカウントの復元 (プレビュー)

ハブ リージョンで実行されるすべての書き込みはすぐに確認され、100 秒以内に非同期でバックアップされます。 サテライト リージョン (非競合解決リージョン) で実行された変更は、確認のためにハブ リージョンに送信されます。 ハブ リージョンは、競合解決が必要かどうかを確認し、競合を解決した後に競合解決タイムスタンプを割り当て、サテライト リージョンに送り返します。 サテライト リージョンは、ハブ リージョンから確認を受信した後にのみエンティティをバックアップします。
要約すると、復元プロセスでは、競合解決タイムスタンプで確認されたエンティティのみがハブ リージョンから復元されます。

Note

マルチ書き込みリージョン アカウントの詳細については、こちらを参照してください。ハブ リージョンは、ポータルの最初のリージョンです。

マルチ リージョン書き込みアカウントの復元 (プレビュー) で復元されないものは何ですか?

復元タイムスタンプによってまだ確認されていない変更は復元されません。 カスタムの競合解決ポリシーを持つコレクションは、タイムスタンプに基づいて最終書き込み者優先にリセットされます。

例: 米国東部と米国西部の 2 つのリージョンがあり、そのうち米国東部がハブ リージョンであるマルチ書き込みリージョン アカウントを想定して、次の一連のイベントを考えてみましょう。

このシナリオでは、復元タイムスタンプが T3 の場合、entity1 のみが復元されます。 entity2 は、T3 によるハブ リージョンでは確認されていません。 復元タイムスタンプが > T4 の場合のみ、entity2 は復元されます。 T1: クライアントはドキュメント Doc1 を米国東部に書き込みます。 (米国東部がハブ リージョンであるため、書き込みはすぐに確認されます)
T2: クライアントはドキュメント Doc2 を米国西部に書き込みます。 T3: 確認のために米国西部から米国東部に Doc2 が送信されます。 T4: 米国東部は Doc2 を受信し、ドキュメントを確認し、Doc2 を米国西部に送り返します。 T5: 米国西部は確認済みの Doc2 を受信します。

このシナリオでは、指定された復元タイムスタンプが T3 の場合、Doc1 のみが復元されます。 Doc2 は T3 によるハブでは確認されていません。 復元タイムスタンプが > T4 の場合にのみ、doc2 が復元されます。

Note

ハブ リージョンでの復元は、現在パブリック プレビュー段階でサポートされています。

新しいアカウントに復元される内容

安定した状態では、ソース アカウント (データベース、コンテナー、アイテムを含む) で実行されるすべての変更が 100 秒以内に非同期的にバックアップされます。 Azure Storage　バックアップ メディアがダウンしているか使用できない場合は、メディアが使用可能になるまで変更はローカル環境に保存されます。 その後、復元できる操作の忠実性が失われるのを防ぐため、それらの変更はフラッシュされます。

プロビジョニングされたスループット コンテナー、共有スループット データベース、またはアカウント全体を任意に組み合わせて復元できます。 復元操作では、すべてのデータとそのインデックス プロパティが新しいアカウントに復元されます。 復元プロセスでは、アカウント、データベース、またはコンテナーで復元されるすべてのデータが、指定された復元時点まで整合していることが保証されます。 復元の期間は、復元する必要があるデータの量によって異なります。 新しく復元されたデータベース アカウントの整合性設定は、ソース データベース アカウントの整合性設定と同じになります。

Note

継続的バックアップ モードでは、バックアップは Azure Cosmos DB アカウントを使用できるすべてのリージョンで実行されます。 リージョン アカウントごとに作成されたバックアップは、既定ではローカル冗長であり、アカウントでそのリージョンに対して可用性ゾーン機能が有効になっている場合はゾーン冗長です。 復元操作では、常に新しいアカウントにデータが復元されます。

復元されないもの

ポイントインタイム リストア後に、次の構成は復元されません。

• 共有スループット データベースの下にあるコンテナーのサブセットは復元できません。 データベース全体をまとめて復元することはできます。
• ファイアウォール、仮想ネットワーク VNET、データ プレーン ロールベースのアクセス制御 RBAC、またはプライベート エンドポイントの設定。
• ソース アカウントのすべてのリージョン。
• ストアド プロシージャ、トリガー、UDF。
• ロールベースのアクセス制御の割り当て。

これらの構成は、復元の完了後に復元されたアカウントに追加できます。

ライブ アカウントの復元可能なタイムスタンプ

削除されていない Azure Cosmos DB のライブ アカウントを復元するには、コンテナーの復元可能な最新のタイムスタンプを常に特定するのがベスト プラクティスです。 その後、このタイムスタンプを使用して、アカウントを最新バージョンに復元できます。

復元シナリオ

ポイント インタイム リストア機能は、次のシナリオをサポートします。 シナリオ [1] ～ [3] は、復元のタイムスタンプが事前にわかっている場合に復元をトリガーする方法を示します。 ただし、偶発的に発生した削除や破損の正確な時刻がわからないというシナリオもあり得ます。 シナリオ [4] と [5] は、復元可能なデータベースまたはコンテナーで新しいイベント フィード API を使用して、復元のタイムスタンプを "検出" する方法を示します。

1. 削除されたアカウントを復元する - 削除された復元可能なすべてのアカウントは、 [復元] ウィンドウから表示できます。 たとえば、タイムスタンプ T3 で "アカウント A" が削除されたとします。 この場合、T3 の直前のタイムスタンプ、場所、ターゲット アカウント名、リソース グループ、ターゲット アカウント名を指定するだけで、Azure portal、PowerShell、または CLI から復元できます。

   

2. 特定のリージョンのアカウントのデータを復元する - たとえば、タイムスタンプ T3 で "アカウント A" が "米国東部" と "米国西部" の 2 つのリージョンに存在するとします。 "米国西部" にアカウント A のコピーが必要な場合、ターゲットの場所として米国西部を指定して、Azure portal、PowerShell、または CLI からポイントインタイム リストアを行うことができます。

3. 既知の復元タイムスタンプを使用してコンテナー内で誤って行われた書き込みまたは削除の操作から復旧する - たとえば、"データベース 1" 内の "コンテナー 1" の内容が、タイムスタンプ T3 で誤って変更されたことがわかっているとします。 タイムスタンプ T3 で Azure portal、PowerShell、または CLI から別のアカウントへのポイントインタイム リストアを実行して、コンテナーの必要な状態を復旧することができます。

4. データベースが誤って削除される前の特定の時点にアカウントを復元する - Azure portalで、イベント フィード ウィンドウを使用して、データベースがいつ削除されたかを確認し、復元時刻を見つけることができます。 同様に、Azure CLI と PowerShell を使用して、データベース イベント フィードを列挙することでデータベースの削除イベントを検出し、必要なパラメーターを指定して復元コマンドをトリガーできます。

5. コンテナーのプロパティを誤って削除または変更する前の特定時点にアカウントを復元する。 - Azure portal で、イベント フィード ウィンドウを使用して、コンテナーがいつ作成、変更、または削除されたかを確認し、復元時刻を見つけることができます。 同様に、Azure CLI と PowerShell を使用して、コンテナー イベント フィードを列挙することですべてのコンテナー イベントを検出し、必要なパラメーターを指定して復元コマンドをトリガーできます。

アクセス許可

Azure Cosmos DB を使用すると、継続的バックアップ アカウントの復元のアクセス許可を切り分けて、特定のロールまたはプリンシパルに制限することができます。 詳細については、アクセス許可に関する記事を参照してください。

価格

30 日間の継続バックアップを備えた Azure Cosmos DB アカウントには、"バックアップを保存する" ための追加の月額料金がかかります。 継続的バックの 30 日間と 7 日間の両方のレベルでは、"データを復元" するための料金が発生します。 復元コストは、復元操作が開始されるたびに加算されます。 継続的バックアップを行うようにアカウントを構成していてもデータを復元しない場合は、バックアップ ストレージのコストのみが請求書に含まれます。

次の例は、米国西部にデプロイされている Azure Cosmos DB アカウントの価格に基づいています。 価格と計算は、お客様が使用しているリージョンによって異なる場合があります。最新の価格情報については、「Azure Cosmos DB の価格」ページをご覧ください。

• 30 日間の継続的バックアップ ポリシーが有効になっているすべてのアカウントでは、バックアップ ストレージに対して月額料金が発生し、次のように計算されます。

  $0.20/GB * アカウントのデータ サイズ (GB) * リージョンの数

• すべての復元 API の呼び出しで、1 回の課金が発生します。 この料金は復元されるデータ量の関数です。

  $0.15/GB * データ サイズ (GB)。

たとえば、2 つのリージョンに 1 TB のデータがある場合は、次のようになります。

• バックアップ ストレージのコストは、1 か月あたり (1000 * 0.20 * 2) = $400 として計算されます。

• 復元コストは、復元あたり (1000 * 0.15) = $150 として計算されます。

ヒント

Azure Cosmos DB アカウントの現在のデータ使用量の測定の詳細については、Azure Monitor for Azure Cosmos DB 分析情報の探索に関するページをご覧ください。 継続的な 7 日間のレベルでは、データのバックアップに対する料金は発生しません。

継続的な 30 日間のレベルと継続的な 7 日間のレベル

• 一方のレベルの保持期間は 30 日間であり、他方のレベルは 7 日間です。
• バックアップ ストレージには 30 日間のリテンション期間レベルが課金されます。 7 日間のリテンション期間レベルは課金されません。
• 復元は、どちらのレベルでも常に課金されます

カスタマー マネージド キー

「カスタマー マネージド キーは継続的バックアップにどのように影響しますか?」を参照し、次のことを理解してください。

• 継続的バックアップとともにカスタマー マネージド キーを使う場合に、Azure Cosmos DB アカウントを構成する方法。
• カスタマー マネージド キーは復元にどのように影響しますか?

現在の制限

現在、ポイントインタイム リストア機能には、次の制限があります。

• 継続的バックアップでは、SQL、MongoDB、Gremlin および Table 用の Azure Cosmos DB API がサポートされます。 Cassandra 用 API は、現在サポートされていません。

• 現在、Azure Synapse Link は継続的バックアップのデータベース アカウントで有効にすることができます。 ただし、逆の状況はまだサポートされておらず、Synapse Link 対応データベース アカウントで継続的バックアップを有効にすることはできません。 また、分析ストアはバックアップに含まれていません。 バックアップと分析ストアの詳細については、分析ストアのバックアップに関する記事を参照してください。

• 復元されるアカウントは、ソース アカウントが存在するものと同じリージョンに作成されます。 ソース アカウントが存在していないリージョンにアカウントを復元することはできません。

• 復元ウィンドウは、連続 30 日間のレベルにおいては 30 日間のみ、連続 7 日間のレベルにおいては 7 日間のみです。 これらのレベルは切り替えることができますが、実際の数量 (7 または 30) は変更できません。 また、30 日間のレベルから 7 日間のレベルに切り替える場合は、7 日間を超える日についてデータが失われる可能性があります。

• バックアップは、自動的には geo ディザスターから保護されません。 アカウントとバックアップの回復性のために、別のリージョンを明示的に追加する必要があります。

• 復元の進行中に、ID およびアクセス管理 (IAM) ポリシーを変更したり削除したりしないでください。 これらのポリシーは、任意の VNET、ファイアウォール構成を変更するためのアクセス許可をアカウントに付与します。

• 継続的バックアップを使う Azure Cosmos DB for MongoDB アカウントでは、既存のコレクションに対する一意のインデックスの作成はサポートされていません。 このようなアカウントでは、コレクションと共に一意のインデックスを作成する必要があります。これを行うには、コレクションの作成拡張機能コマンドを使います。

• ポイントインタイム リストア機能では、常に新しい Azure Cosmos DB アカウントに復元されます。 既存のアカウントへの復元は、現在サポートされていません。 インプレースでの復元に関するフィードバックをお送りいただく場合は、アカウント担当者を通じて Azure Cosmos DB チームにご連絡ください。

• 復元後は、特定のコレクションについて整合インデックスが再作成される可能性があります。 再作成操作の状況は、IndexTransformationProgress プロパティを使用して確認できます。

• 復元プロセスでは、既定で TTL 構成を含むコンテナーのすべてのプロパティが復元されます。復元中に TTL を無効にするパラメーターを渡すことができます。 そのため、そのように構成してある場合、復元されたデータが直ちに削除される可能性があります。 この状況を回避するには、復元のタイムスタンプを TTL プロパティがコンテナーに追加された時点より前にする必要があります。

• 継続的バックアップ モードのアカウントを作成するときに、MongoDB 用 API の一意なインデックスを追加したり更新したりすることはできません。 また、アカウントを定期的から継続的なモードに移行する場合も、それらを変更できません。

• 継続的モードの復元では、復元ポイントの時点で有効なスループット設定を復元できない場合があります。

次のステップ

• Azure portal、PowerShell、CLI、または Azure Resource Manager を使用して継続的バックアップを有効にします。
• SQL および MongoDB アカウントの最新の復元可能なタイプスタンプを取得します。
• Azure portal、PowerShell、CLI、または Azure Resource Manager を使用して継続的バックアップ アカウントを復元します。
• 定期的なバックアップから継続的バックアップにアカウントを移行します。
• 継続的バックアップ モードでデータを復元するために必要なアクセス許可を管理します。
• 継続的バックアップ モードのリソース モデル