次の方法で共有

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

  • [アーティクル]

適用対象: NoSQL MongoDB Gremlin Table

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 CLI)、Azure PowerShell、または Azure Resource Manager テンプレートを使用して実行できます。

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

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

復元する各種の方法

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

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

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

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

注意

継続的バックアップ モードでは、バックアップは 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 日間のリテンション期間レベルは課金されません。
  • 復元は、どちらのレベルでも常に課金されます

Time to Live

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

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

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

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

現在の制限

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

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

  • Multi region write アカウントはサポートされていません。

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

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

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

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

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

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

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

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

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

次のステップ