Azure Cosmos DB は自動バックアップが強力ですが、「アカウントを消してしまった！」「コンテナーを誤削除した！」というときに、どこまで戻せるのか・誰がどう操作すればよいのかは意外と分かりづらいポイントです。本記事では、連続バックアップ／定期バックアップそれぞれの復元方法と注意点、さらに運用で押さえておきたい手動バックアップの選択肢までまとめて解説します。
Azure Cosmos DB のバックアップ／復元の全体像
まずは、Azure Cosmos DB のバックアップと復元の「大枠」を整理しておきます。
2つのバックアップ方式と復元の関係
Cosmos DB には、次の 2 種類のバックアップ方式があります。
- 定期バックアップ（Periodic backup）：既定の方式。一定間隔でスナップショットを取得。
- 連続バックアップ（Continuous backup, Point-in-Time Restore）：変更履歴を継続的に保存し、任意の時点に巻き戻せる方式。
バックアップ方式ごとの「復元の主な違い」は次の通りです。
| 項目 | 連続バックアップ（Continuous） | 定期バックアップ（Periodic） |
|---|---|---|
| 復元操作 | ポータル／CLI／PowerShell から 自分で実行 | Azure サポートに復元依頼が必要 |
| 復元可能な期間 | 7 日または 30 日のどちらかの「連続ウィンドウ」から任意秒単位で指定 | 設定したバックアップ間隔と保持期間に依存（最大 30 日程度） |
| 復元対象 | アカウント全体／データベース／コンテナー単位で選択可能 | アカウント全体／データベース単位／一部コンテナーなどをサポートチームが復元 |
| 復元先 | 基本は新しいアカウントとして復元。 一部シナリオでは同一アカウント内への復元（Same-account restore）も可能（DB／コンテナー単位） | 必ず新しいアカウントとして復元される |
| 誰が操作するか | サブスクリプション管理者／Cosmos DB 管理者が自力で実行 | Microsoft サポート エンジニアが復元を実施（Standard / Developer 以上のサポート プランが必要） |
| コスト | バックアップ容量＋復元実行ごとに課金。30 日 tier は 7 日 tier より高コスト | 最新 2 世代までは無料、それ以上の保持はバックアップ ストレージに応じて課金 |
重要なのは、「どの方式でも基本的に削除から 30 日以内ならアカウント復元のチャンスがある」一方、「どの時点まで戻せるか」は方式ごとに大きく違うということです。
削除した Cosmos DB アカウントは復元できるのか
アカウント削除後に復元できる期間
Cosmos DB アカウントは、削除後も Azure 側で「削除済みアカウント」として 30 日間保持され、復元候補として一覧表示されます。連続バックアップ モードの公式ドキュメントでも、「削除から 30 日以内であればポータルから完全なアカウント復元が可能」と明記されています。
また、Microsoft Q&A でも、バックアップ方式にかかわらず「削除した Cosmos DB アカウントは 30 日以内なら復元可能」と案内されています。
ただし、ここで注意したいポイントが 1 つあります。
- 「30 日」はあくまで削除されたアカウントが復元候補として残る期間（ソフト デリートの期間）
- 「何日前の状態まで戻せるか」は連続 7 日／30 日 tier などの「バックアップ保持期間」に依存
つまり、「削除から 30 日以内だから必ず 30 日前の状態に戻せる」わけではない点は押さえておきましょう。連続 7 日 tier なら、実質的な復元ウィンドウは 7 日が目安になります。
連続バックアップ モードのアカウントを削除してしまった場合
連続バックアップ モードのアカウントであれば、Azure ポータルから自分でアカウント復元ができます。
- Azure ポータルにサインイン。
- 上部の検索ボックスで
Azure Cosmos DBを検索し、一覧画面を開く。 - 画面上部の [復元] (Restore) ボタンをクリック。
- 削除済みアカウントの一覧から、復元したいアカウントを選択。
- ここに表示されるのは削除から 30 日以内のアカウントのみ。
- 以下の情報を入力して復元を実行。
- 復元ポイント (UTC)：復元したい時点（秒精度）
- リージョン：復元先リージョン（元アカウントが存在していたリージョンに限る）
- リソース グループ：復元先アカウントを作成する RG
- 復元先アカウント名：新しく作成されるアカウントの名前
復元操作により、元アカウントとは別の新規アカウントが作成され、指定した時点のデータ／設定がコピーされます。元アカウントと同じ名前を使うことも可能ですが、すでに同名アカウントが存在すると利用できないため、「誤って同じ名前でアカウントを再作成しない」ことが重要です。
定期バックアップ モードのアカウントを削除してしまった場合
定期バックアップ モードのアカウントを削除した場合、ポータルから自力での復元はできません。代わりに、Azure サポートに「バックアップからの復元」を依頼します。
- Azure ポータル右上の [ヘルプ + サポート] を開く。
- [サポート リクエストの作成] をクリック。
- フォームで次のように入力。
- サービス：Azure Cosmos DB
- リソース：削除したアカウント（または同一サブスクリプション内の関連リソース）
- 問題の種類：バックアップと復元／データ復旧 など
- 詳細欄で以下の情報をできるだけ詳しく記載。
- サブスクリプション ID
- 削除した Cosmos DB アカウント名（同名アカウントを作り直した場合はその旨も記載）
- 削除日時（UTC）
- 希望する復元時点（UTC）
- ネットワーク制限（VNET / Private Endpoint など）を復元先に適用したいか
- Standard / Developer 以上のサポート プランを利用していることを確認し、チケットを送信。
サポート チームは、バックアップから新しい Cosmos DB アカウントを作成してデータを復元します。その後、アプリケーション側で接続文字列を復元先に切り替える運用が一般的です。
| 項目 | 連続バックアップ | 定期バックアップ |
|---|---|---|
| 削除済みアカウントの保持期間 | 原則 30 日間（どちらの方式でも復元候補としては 30 日間保持） | |
| 復元トリガー | ポータルの [復元] から自力で実行 | サポート チケットから復元依頼 |
| 復元先 | 新規アカウント（ターゲット名を指定） | 新規アカウント（通常 <元名>-restored1 のような名前） |
データベース／コンテナーを削除してしまったときの復元
連続バックアップ モード：同一アカウント／新しいアカウントのどちらにも復元可能
連続バックアップ モードでは、誤って削除したデータベース／コンテナーを、以下 2 パターンで復元できます。
- 同一アカウント内に復元（Same-account restore）
- 既存アカウント内に、削除されたデータベース／コンテナーを「巻き戻して」復元。
- 復元対象の DB／コンテナーは新しく作成されるため、同名のリソースが既に存在している場合は選択できません。
- 新しいアカウントとして復元
- アカウント全体あるいは特定 DB／コンテナーを、別アカウントとして復元。
- 元アカウントと切り離して動作検証したい場合に有効。
同一アカウントに復元する場合の操作イメージは以下の通りです。
- Azure ポータルで対象 Cosmos DB アカウントを開く。
- 左メニューから [Point in Time Restore]（[ポイントインタイム復元]）を選択。
- [Restore to same account]（同一アカウントに復元）タブを選択。
- 検索欄にデータベース名やコンテナー名を入力し、削除イベントを含むタイムラインを絞り込む。
- 削除前の時刻を選び、復元を実行。
「どの時点に戻すか」は、削除イベントの直前を選ぶのが基本です。ポータルのイベント フィードでは、DB／コンテナーの作成・更新・削除が時系列で一覧できるため、どのタイミングに巻き戻すべきかを視覚的に判断できます。
定期バックアップ モード：サポートに「いつ・何を消したか」を伝えて復元
定期バックアップ モードで DB／コンテナーを削除してしまった場合も、Azure サポートに復元依頼を出す必要があります。
このとき重要なのは、「バックアップ保持期間」×「削除から経過した時間」の組み合わせです。
- 定期バックアップでは、既定で4 時間ごとにフル スナップショットが取得され、最新 2 世代が保存されます（保持期間は設定で拡張可能）。
- DB／コンテナーを削除した場合、その時点までのスナップショットは最大 30 日間保持されます。
そのため、次の 2 つをサポートに正確に伝えることが非常に重要です。
- 削除したリソース：アカウント名／データベース名／コンテナー名
- 削除日時（UTC）：できれば「◯◯:◯◯:◯◯Z」の秒単位
また、公式ドキュメントでは、データの削除・破損を検知してから 8 時間以内にサポートへ連絡し、かつバックアップ保持期間を少なくとも 7 日に増やすことが推奨されています。これによって、バックアップデータが上書きされる前に復元作業に入ることができます。
データ破損（UPDATE／DELETE ミス）の場合
「コンテナーそのものは残っているが、多数のドキュメントを誤更新／誤削除してしまった」というケースでは、次のように切り分けます。
- 連続バックアップ：
- 誤操作の直前の時刻を特定し、その時点に巻き戻した新規アカウントを作成。
- 比較用に元アカウントと復元アカウントを並行運用し、必要なデータのみ再インポートするパターンが安全。
- 定期バックアップ：
- 誤操作を検知したら即座にバックアップ保持期間を 7 日以上に延長し、8 時間以内にサポートへ連絡。
- 「どの時刻の状態に戻したいか」を UTC で指定し、復元先アカウントから必要データを戻す。
連続バックアップ（PITR）を有効化・確認する手順
「今は定期バックアップだが、セルフサービスで復元できるようにしたい」というケースでは、既存アカウントのバックアップ モードを連続バックアップに切り替えることが可能です。
現在のバックアップ方式を確認する
- Azure ポータルで対象の Cosmos DB アカウントを開く。
- 左メニューの [設定] → [バックアップと復元] (Settings > Backup & Restore) をクリック。
- 右側の「バックアップ ポリシー」や「バックアップ ポリシー モード」に、現在の設定が表示される。
- Periodic / 定期 と表示されていれば「定期バックアップ」。
- Continuous7Days / Continuous30Days などと表示されていれば「連続バックアップ」。
既存アカウントを定期 → 連続バックアップへ切り替える
バックアップ モードの切り替えは、定期 → 連続のみ（片方向）で行えます。連続にしたあとで定期に戻すことはできないため、事前に十分に検討してください。
- 対象の Cosmos DB アカウントを開く。
- [設定] → [バックアップと復元] を開く。
- 「バックアップ ポリシー モード」の右側にある [変更]（Change）リンクをクリック。
- [連続]（Continuous）を選択し、保持期間を 7 日 or 30 日 から選ぶ。
- 連続 7 日：バックアップ ストレージ料金が安いが、巻き戻せる期間も 7 日に限定。
- 連続 30 日：コストは増えるが、復元ウィンドウが広く運用上安心。
- [保存] をクリックして反映。
| 事前チェック項目 | ポイント |
|---|---|
| 対応 API かどうか | 連続バックアップは NoSQL / MongoDB / Table / Gremlin でサポート。 |
| 書き込みリージョン構成 | 単一書き込みリージョンであることなど、いくつかの前提条件があるため、ドキュメントを確認。 |
| コスト | 7 日 / 30 日 tier でバックアップ ストレージ料金が変わる。復元実行時にも別途課金。 |
| 巻き戻しニーズ | 運用上「7 日で十分か、30 日欲しいか」を関係者とすり合わせておく。 |
連続バックアップによる復元操作の実践手順
アカウント全体を新しいアカウントとして復元する
アカウント設定の大半（RU 設定、インデックス、リージョン構成など）を含めて丸ごと巻き戻したい場合は、アカウント全体の復元を行います。
- 復元元の Cosmos DB アカウントを Azure ポータルで開く。
- 左メニューから [Point in Time Restore] を選択。
- 「復元元（ライブ アカウント／削除済みアカウント）」と「復元ポイント (UTC)」を指定。
- イベント フィードから作成／更新／削除イベントを確認し、巻き戻したいタイミングを決定。
- [Restore Resource] で [Entire account] を選択。
- 新しいリソース グループ／アカウント名／リージョンを指定して復元を実行。
復元が完了すると、元アカウントとは別の新規アカウントが 「Creating」→「Online」 状態になります。以降は、この復元アカウントに対してアプリケーションの接続文字列を切り替え、動作確認を行います。
削除したデータベース／コンテナーを同一アカウントに復元する
影響範囲が限定されている場合は、「同一アカウントへのポイントインタイム復元」が便利です。
- Cosmos DB アカウント → [Point in Time Restore] を開く。
- [Restore to same account] タブを選択。
- 検索ボックスにデータベース名を入力し、削除イベントを含むイベント フィードを確認。
- 削除前の時刻を選び、対象データベース／コンテナーを選択して復元。
この方法では、対象データベース／コンテナーだけが復元されるため、アカウント全体を巻き戻さずに済むのがメリットです。
復元後に行うべきアプリ側の変更
復元先が新しいアカウントの場合、アプリケーション側で次の変更が必要です。
- 接続文字列／エンドポイント URL／キーの更新（Key Vault 等にも反映）。
- アプリ設定（App Service, Functions, コンテナーの環境変数等）の更新。
- 必要に応じて DNS / API Gateway / Front Door などのルーティング設定更新。
一方、同一アカウント内への DB／コンテナー復元の場合は、接続先アカウントは変わらないため、アプリ側での変更は少なくて済むケースが多いです。ただし、「異なるコンテナー名」「別 DB」に復元した場合は、アプリ側の設定も合わせる必要があります。
定期バックアップからの復元依頼を成功させるコツ
サポートに伝えるべき情報リスト
定期バックアップからの復元は、いかに情報を整理してサポートに渡せるかでスピードと成功率が変わります。
| カテゴリ | 具体的な内容 |
|---|---|
| 基本情報 | ・サブスクリプション ID ・リソース グループ名 ・Cosmos DB アカウント名 |
| 対象リソース | ・削除／破損したデータベース名 ・削除／破損したコンテナー名 ・同名の DB／コンテナーを作り直していないかどうか |
| 時刻情報 | ・事故発生日時（UTC） ・「この時点に戻したい」という希望復元時刻（UTC） |
| ネットワーク | ・復元先アカウントをパブリックアクセス可にするか／VNET / Private Endpoint のみとするか |
| 優先度 | ・本番系かどうか ・いつまでに復元したいか（SLA の目安） |
これらをあらかじめテンプレート化しておき、インシデント発生時には「埋めて送るだけ」にしておくと、実際の障害対応が格段に楽になります。
よくある誤解と注意点
「連続 7 日＝アカウント復元 7 日」ではないが、油断は禁物
連続バックアップの 7 日／30 日 tier は、「どの時点の状態に戻せるか」のウィンドウを表します。
- 連続 7 日：過去 7 日間の任意の時点まで。
- 連続 30 日：過去 30 日間の任意の時点まで。
一方、削除済みアカウントが「復元候補」としてポータルに表示される期間は 30 日です。
このため、
- 「削除から 29 日目に気付いても、連続 30 日 tier ならまだ復元できる可能性がある」。
- 「連続 7 日 tier の場合、削除から 9 日経ってしまうと、実質的に戻せるポイントが残っていない可能性が高い」。
という差が生じます。「30 日はあくまで上限。実運用では『事故に気付いてすぐ動けるか』が決定的に重要」と考えるのがおすすめです。
連続バックアップでも「既存アカウントへの上書き復元」は限定的
連続バックアップでは、アカウント全体の復元は常に「新規アカウント」として行われる点に注意が必要です。
- 既存アカウントをそのまま上書きすることはできません。
- DB／コンテナー単位であれば「同一アカウントへの復元」が可能ですが、それでも「指定のリソースを新規作成する」動きになります。
そのため、「別アカウント／別コンテナーとして復元 → データを比較・移行 → 不要になった復元先を削除」という手順を標準フローとして決めておくと安全です。
手動バックアップ（外部バックアップ）をどう設計するか
Cosmos DB の自動バックアップは強力ですが、「Azure アカウントとは独立したバックアップ」「長期保管」「監査用スナップショット」などの要件がある場合は、外部バックアップも併用すると安心です。
代表的な手動バックアップ手段
| 手段 | 概要 | 向いている用途 |
|---|---|---|
| Azure Data Factory（コピー） | Cosmos DB コネクタでデータを定期的に JSON として Blob / Data Lake にエクスポート。 | 日次／週次フルバックアップ、長期保管用スナップショット |
| Change Feed（変更フィード） | コンテナーの変更履歴を読み出し、外部ストレージや別コンテナーに増分コピー。 | 増分バックアップ、監査ログ的な用途、DR 先への継続レプリケーション |
| Desktop Data Migration Tool | Azure Cosmos DB Desktop Data Migration Tool を使い、コンテナーの内容を JSON などにエクスポート／インポート。 | 臨時の「手動バックアップ」、特定ポイントのスナップショット、別環境への複製 |
| Container Copy Jobs | Cosmos DB のコンテナー コピー機能を使い、同一／別アカウントへオンラインコピー。 | スキーマ変更前の退避、性能検証用のコピー、DR リージョンへの複写 |
これらの外部バックアップは、
- Azure 内の障害に備えるための「第二のバックアップ」
- アプリケーションバグによる論理削除／データ汚染への追加保険
- 監査やコンプライアンス要件（一定期間のデータ保持）への対応
といった観点で非常に有効です。
復旧リハーサルを定期的に行う
バックアップは、「復元できて初めて意味がある」ものです。年に数回でも良いので、次のような 復旧リハーサルを行うことをおすすめします。
- バックアップデータ（JSON, Blob, 別アカウントのコンテナーなど）から、新しい Cosmos DB アカウントにデータをリストア。
- アプリケーションの接続先を一時的に切り替え、最低限の動作確認を行う。
- 実際に試してみて分かった手順やハマりどころを、社内 Runbook（手順書）に反映。
これを「本番リリース前」や「大規模スキーマ変更前」のチェック項目に組み込んでおくと、いざというときの安心感が大きく変わります。
運用に組み込むためのチェックリスト
最後に、本記事の内容を踏まえて「明日からすぐに決めておきたいこと」をチェックリストとして整理します。
- □ 現在の Cosmos DB アカウントのバックアップ方式（連続 / 定期）を把握しているか。
- □ 連続バックアップの場合、7 日 tier / 30 日 tier どちらを採用しているか、関係者に共有されているか。
- □ 定期バックアップの場合、バックアップ間隔と保持期間がワークロードに見合っているか（短すぎてすぐ上書きされていないか）。
- □ 事故発生時に「誰が」「どのドキュメントを見て」「どのように」復元操作／サポート依頼を行うか、Runbook が用意されているか。
- □ サポート プランが Standard / Developer 以上 になっているか（Basic のままになっていないか）。
- □ 少なくとも本番アカウントでは、連続バックアップ + 外部バックアップ（Data Factory / Change Feed 等）の二重構成を検討しているか。
- □ 少なくとも年 1 回は、本番相当データを用いた復旧リハーサルを実施しているか。
まとめ：Cosmos DB バックアップ戦略の考え方
本記事で扱ったポイントをあらためて整理すると、以下のようになります。
- 削除した Cosmos DB アカウントは、原則として削除から 30 日以内なら復元候補として残る。バックアップ方式にかかわらず、この 30 日を過ぎると復元は事実上困難です。
- 連続バックアップなら、ポータルから自力でポイントインタイム復元が可能です。7 日／30 日 tier のどちらかを選び、運用の RPO / RTO に合わせて設定しましょう。
- 定期バックアップの場合は、Azure サポート経由での復元になります。サポート プランとテンプレート化された復旧依頼書をあらかじめ用意しておくと安心です。
- 「連続 7 日／30 日」はバックアップ保持ウィンドウであり、「削除済みアカウントの保持期間（30 日）」とは別の概念です。特に 7 日 tier を選ぶ場合は、異常検知から復元開始までのスピードが命になります。
- 将来の事故に備え、連続バックアップ + 外部バックアップ（Data Factory、Change Feed、Migration Tool 等）を組み合わせ、かつ定期的な復旧リハーサルを行うことで、Cosmos DB のレジリエンスを高めることができます。
一度バックアップ／復元の仕組みと手順を整理しておけば、「アカウントを消してしまった」「大量にデータを壊してしまった」という最悪の状況でも、落ち着いて対処できるようになります。本記事をベースに、ぜひ自社環境向けのバックアップ／リストア Runbook を作成してみてください。
コメント