本記事では、Azure Cosmos DB における定期的バックアップからのデータ復元について、具体的な手順を説明いたします。
はじめに
本記事では、Azure Cosmos DB（以下、Cosmos DB）の定期的バックアップからのデータ復元手順を、実際の事例をもとにご紹介します。定期的バックアップからのデータ復元ではユーザー側の操作だけでは完結せず、サポートリクエストによりMicrosoftに復元作業を実施してもらう必要がありましたので、その手順を含めて具体的に説明します。
今回の復元対象となった Cosmos DB アカウントの設定や発生事象については、以下の通りです。
対象の Cosmos DB アカウントのバックアップ設定
- バックアップポリシー：定期的バックアップモード (Periodic)
- バックアップ期間：240分 (4時間)
- バックアップ保有期間：8時間
この設定は Cosmos DB アカウントを新規作成した際のデフォルト設定です。
バックアップポリシーモードのもう一つの選択肢として、継続的バックアップモード (Continuous) が存在します。両者の違いについては、次回の記事で詳しく紹介します。
上記設定では、4時間間隔でバックアップが実行され、過去8時間分つまり2つ分のバックアップが常に保有され、その2つのポイントに復元可能な状態です。図示すると、以下のイメージです。
発生事象
今回の対象 Cosmos DB アカウントには、1つのデータベースがあり、その中に1つのコンテナーだけがある構成でした。コンテナー内のデータの一部を誤って削除してしまったことが発生事象です。
このデータを復元をするために、以降の手順で復元作業を進めていきました。
※ 今回の事象は、コンテナー内の一部データの削除でしたが、誤ってアカウント/データベース/コンテナーを削除した場合でも復元手順としては大きく変わらず、新しい Cosmos DB アカウントが作成されて、そこにデータが復元されます。
具体的な手順
定期的バックアップモードでバックアップ保有期間を短く設定している場合は、データ復元できるかどうかは時間との勝負になります。データ破損から復元作業までの時間がバックアップ保有期間を超えると、データ復元ができない可能性があります。
バックアップ保有期間が8時間であってもバックアップが8時間以上残っている可能性があり、厳密にバックアップ保有期間を超えるとデータ復元が不可能になる、というわけではないようです。
いずれにせよ、データ破損に気づいた時点で復元が間に合うかどうかはわかりませんが、とりあえず以下の手順を迅速に進めた方がよいです。
まずバックアップ保有期間を延長する
復元手順として、以下の公式ドキュメントを参考にしました。
バックアップからのデータ復元を要求する - Azure Cosmos DB | Microsoft Learn
このドキュメントには以下の記載があるので、まずバックアップ保有期間を7日以上に延ばしましょう。
誤ってデータを削除した場合またはデータが破損した場合は、Azure Cosmos DB チームがバックアップからのデータの復元をサポートできるように、8 時間以内に Azure サポートに連絡してください。 データを復元するためのサポート リクエストを作成する前に、アカウントのバックアップ保有期間を 7 日以上に増やしてください。 このイベントの 8 時間以内に保有期間を延長することをお勧めします。 この方法で、Azure Cosmos DB サポート チームがアカウントを復元するのに十分な時間が確保されます。
具体的には以下の設定を変更します。
この設定変更をすることで取得済みの既存バックアップの保有期間も延長されるのか疑問に感じました。
以下の記述から察するに、既存バックアップの保有期間が新しい設定の保有期間に延長されるというわけではないようです。ですが、保有期間設定を7日以上に延長することで新しいバックアップが既存への上書きではなく新規作成になるため、既存のバックアップが上書きされて復元できなくなる状況を避けられるようです。
これによって、少しの時間の余裕が生み出せるということのようです。
コンテナー内の 1 つ以上の項目を誤って削除または変更した場合 (データの破損のケース)、どの時点まで復元するかを指定する必要があります。 データが破損している場合は、時間が重要です。 コンテナーはライブ状態であるため、バックアップはまだ実行中です。したがって、保有期間 (既定では 8 時間) より長く待つと、バックアップが上書きされます。 バックアップが上書きされないようにするには、アカウントのバックアップ保有を少なくとも 7 日間に増やします。 データの破損から 8 時間以内に、データの保有を延長することをお勧めします。
サポートリクエストに連絡する
あとは、通常の問い合わせの際と同じように、「ヘルプとサポート」からサポートリクエストの新規作成を行います。
以下のように適切に問題の種類を選択して、サポートリクエストの作成に進みます。
問題の詳細として、以下の項目に情報を記入していきます。
問題が発生し始めたのは何時ですか?
データの削除または破損をした時刻がわかっていれば記入しましょう。
今回のケースでは、Cosmos DB のメトリックの Document Count の変化を確認して、ドキュメントを削除した時刻を特定しました。
サポート リクエストの理由は何ですか?
選択肢として3つありますが、それぞれ以下の使い分けと考えられます。
- 削除されたデータの復元：アカウント、データベース、コンテナーを削除した場合
- 破損したデータの復元：コンテナー内のドキュメントを削除または変更した場合
- 非復元要求：依頼内容がデータ復元ではなく、それに関連する問い合わせなどの場合
「削除」と「破損」の違いは以下のドキュメントに記載されていました。
今回のケースは「破損したデータの復元」に該当しますので、これを選択します。「削除されたデータの復元」でも以降の手順は変わりません。
復元するデータベース アカウントの名前
今回データを削除または破損した Cosmos DB アカウントの名前を記入します。
データの復元ポイント
データ破損する直前で、データが正常であった時点を記入すればよいと思います。
データ破損操作をした5分前の時刻を記入しました。
アカウントのすべてのデータベースとコレクションを復元しますか?
Cosmos DB アカウントのすべてのデータベースとコンテナーを復元したい場合は「はい」を選択します。一部のデータベースやコンテナーだけを復元したい場合は「いいえ」を選択し、その対象を指定します。
復元されたDBを、既存のDBから切り替えてそのまま運用していきたい場合などは、「はい」を選択すればよいと思います。
復元要求に関するその他の詳細情報を提供してください。
以下のような内容を記入しておくとよいと思います。
- 発生した問題についての説明
- データ削除や破損した時刻
- アカウント/データベース/コンテナーの削除なのか、ドキュメントの削除や変更なのか
- より詳細な操作内容など
- その他（破損時刻をメトリックのDocument Countで特定したことも記載しました）
- バックアップ設定
- 元のバックアップ設定（「バックアップ期間 240分、バックアップ保有期間 8時間」など）
- バックアップ保有期間を7日以上に先ほど変更したこと
- 復元先となる新しいアカウント名（Microsoftが作成するのでこちら側ではあらかじめ作成はしません）
- データやシステムの用途や重要性
重要度
復元に関する記入内容は以上ですが、この重要度がデータ復元できるかの明暗を分けるポイントになると思います。
重要度Aの場合は24時間体制で対応が行われるため、復元作業がすぐに着手されると思われます。しかし、重要度B以下の場合は、復元作業の対応が翌営業日になる可能性もあり、バックアップ保有期間の設定によってはデータ復元できない可能性もあります。
即座にデータ復元作業に着手してもらうことをこちらが希望しても、重要度がどれに該当するかはMicrosoftの判断に依るので、重要度Aで起票してもBに下げられる可能性はあることは覚悟しましょう。このことからも、そもそものバックアップ設定を適切にしておくことの重要性がわかります。
以上の内容でサポートリクエストを作成し、あとはサポートリクエストの担当者とやりとりして復元作業を進めてもらいます。
データが復元されたら
バックアップはリクエストで指定した名前の新しい Cosmos DB アカウントに復元されます。このデータを元の Cosmos DB アカウントに移行したり、そのままそれを運用先として利用するケースが考えられます。
私の今回の場合は、既存DBに無いドキュメントを復元先DBから移行するPythonスクリプトを作成して、データ移行しました。公式では、以下のツールが提供されているので、要件が合う場合は利用できそうです。
デスクトップ データ移行ツールを使用してデータを移行する - Azure Cosmos DB | Microsoft Learn
最後に
定期的バックアップからのデータ復元にはサポートリクエストの作成が必要になることは、今回の件で初めて認識しました。復元作業をMicrosoftで行ってくれるため便利な一方で、復旧作業がユーザー側で完結しないことにやりにくさも覚えました。
今回の経験を基に Cosmos DB のバックアップ設定をどのようにすべきか検討したため、これについては次回の記事で整理して紹介したいと思います。
