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

適用対象: NoSQL MongoDB グレムリン 表

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

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

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

復元に使用できる時間枠 (リテンション期間とも呼ばれます) は、30 日と 7 日間の 2 つのオプションの小さい値です。

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

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

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

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

復元する各種の方法

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

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

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

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

復元されないもの

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

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

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

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

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

復元シナリオ

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

• シナリオ 1 - 削除されたアカウントを復元する: 復元できるすべての削除済みアカウントが [ 復元 ] ウィンドウに表示されます。 たとえば、タイムスタンプ T3 で "アカウント A" が削除されたとします。 この場合、T3 の直前のタイムスタンプ、場所、ターゲット アカウント名、リソース グループ、およびターゲット アカウント名は、 Azure portal、 PowerShell、または CLI から復元するのに十分です。

  

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

• シナリオ 3 - 既知の復元タイムスタンプを持つコンテナー内の誤った書き込みまたは削除操作から復旧する: たとえば、データベース 1 内のコンテナー 1 の内容がタイムスタンプ T3 で誤って変更されたことがわかっている場合。 Azure portal、PowerShell、または CLI からタイムスタンプ T3 の別のアカウントに特定の時点の復元を実行して、コンテナーの目的の状態を回復できます。

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

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

アクセス許可

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

複数リージョンにわたる書き込みアカウントの復元を理解することについて

ハブ リージョンで実行された書き込みはすぐに確認され、100 秒以内に非同期的にバックアップされます。 複数書き込みアカウントでは、サテライト リージョンで実行されたすべての変更が確認のためにハブリージョンに送信されます。 ハブリージョンは 、競合解決 が必要かどうかを確認し、競合を解決した後に 競合解決タイムスタンプ を割り当てて、ドキュメントをサテライトリージョンに送り返します。 サテライトリージョンは、確認がハブから受信された後にのみドキュメントをバックアップします。 つまり、復元プロセスでは、復元時点までにハブ リージョンによって確認されたドキュメントのみが復元されます。

複数リージョンの書き込みアカウントの復元はどうなりますか?

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

複数書き込みが有効なアカウントのタイムスタンプについて詳しくは、「 タイムスタンプについて」をご覧ください。

シナリオの例: 米国東部と米国西部の 2 つのリージョンを持つ複数書き込みリージョン アカウントのうち、米国東部がハブ リージョンである場合は、次の一連のイベントを検討してください。

• T1: クライアントがドキュメント Doc1 を米国東部に書き込みます (米国東部はハブ リージョンであるため、書き込みは直ちに確認されます)

• T2: クライアントがドキュメント Doc2 を米国西部に書き込む

• T3: 確認のために米国西部が Doc2 を米国東部に送信する

• T4: 米国東部が Doc2 を受け取り、ドキュメントを確認し、Doc2 を米国西部に送り返す

• T5: 米国西部が確認済み Doc2 を受け取った

このシナリオでは、指定された復元タイムスタンプがソースとしてのハブ リージョンの T3 である場合、Doc1 のみが復元されます。 Doc2 は T3 によるハブでは確認されていません。 復元タイムスタンプが T4 を超える場合にのみ、doc2 は復元されます。これは、サテライトでの T4 時点では doc2 がまだ確認されていないために、doc1 のみが含まているためです。

価格

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 のデータがある場合は、次のようになります。

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

• 復元コストは、復元ごとに 1000 * 0.15 = $150 として計算されます

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

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

Time to Live

• 既定の復元プロセスでは、TTL 構成を含むコンテナーのすべてのプロパティが既定で復元されます。 TTL を無効にせずに復元を行うと、データが削除される可能性があります。 削除を防ぐには、復元の実行中に 、PowerShell (-DisableTtl $true) または cli (--disable-ttl True) で TTL を無効にするパラメーターを渡します。

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

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

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

現在の制限

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

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

• 継続的バックアップ モードを使用するデータベース アカウントの Azure Synapse Link が一般提供されています。 Synapse Link 対応アカウントの連続バックアップ モードとは逆の状況は、パブリック プレビュー段階です。 現時点では、コンテナーで Synapse Link を無効にしている顧客は、継続的バックアップに移行できません。 また、分析ストアはバックアップに含まれていません。 詳細については、 分析ストアのバックアップに関するページを参照してください。

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

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

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

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

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

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

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

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

次のステップ

• Azure portal、PowerShell、CLI、または Azure Resource Manager を使用して継続的バックアップを有効にする
• Azure portal、PowerShell、CLI、または Azure Resource Manager を使用して継続的バックアップ アカウントを復元する
• 継続的バックアップ アカウントの最新の復元可能タイムスタンプを取得する
• アカウントを定期的なバックアップから継続的バックアップに移行する
• Azure Cosmos DB アカウントを復元するためのアクセス許可を管理する
• Azure Cosmos DB ポイントインタイム リストアのリソース モデル
• Azure Cosmos DB での複数リージョンの書き込みについて
• Cosmos DB のタイムスタンプについて
• Azure Cosmos DB を使用したグローバル データ分散 - 仕組みの詳細