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

  • [アーティクル]

適用対象: NoSQL MongoDB Gremlin Table

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

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

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

Diagram illustrating how a container is backed up across multiple regions.

復元に使用できる時間枠 (保持期間とも呼ばれます) は、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　バックアップ メディアがダウンしているか使用できない場合は、メディアが使用可能になるまで変更はローカル環境に保存されます。 その後、復元できる操作の忠実性が失われるのを防ぐため、それらの変更はフラッシュされます。

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

Note

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

復元されないもの

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

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

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

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

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

復元シナリオ

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

Life-cycle events with timestamps for a restorable account.

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

    Life-cycle events with timestamps for a restorable database and container.

  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 プロパティがコンテナーに追加された時点より前にする必要があります。

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

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

次のステップ