Azure Cosmos DB for MongoDB vCore 誤削除の復旧方法｜terraform destroy後のデータ復元とAzureサポート手順

Terraform の terraform destroy で Azure Cosmos DB for MongoDB（MongoDB vCore）を誤って削除してしまっても、条件次第では Azure 側の自動バックアップから復旧できる可能性があります。復旧可否の考え方と、Azure サポートへ最短で依頼する手順を具体的にまとめます。

結論：完全削除でも「復旧できる可能性」はある。ただし時間勝負

Terraform で Cosmos DB を誤削除すると、いちばん厄介なのは「アカウント（またはクラスター）が消えた時点で、通常の復元画面にたどり着けなくなる」点です。特に削除後に同名で作り直してしまうと、復旧の導線がさらに分かりにくくなります。

一方で、Azure 側の自動バックアップが残っている場合は、Azure サポート経由で復旧できるケースがあります。実際に「terraform destroy で MongoDB vCore を削除 → その後にチケット経由で製品チーム連携 → クラスター復旧まで完了した」事例も報告されています。

最優先でやること：「削除した日時（UTC）」「サブスクリプションID」「対象リソース名（消えた側と作り直した側）」をすぐ確定し、サポートへ復旧依頼を出すこと。

まず切り分け：あなたの「Cosmos DB for MongoDB」はどの種類？

同じ「MongoDB」と書かれていても、Azure には大きく分けて2系統あります。復旧手段が違うので、ここを最初に整理します。

系統	管理単位	復元の考え方	誤削除時の頼り先
MongoDB vCore（クラスター型）	クラスター	自動バックアップ（PITR）から新規クラスターとして復元	削除済みならサポート依頼が現実的
API for MongoDB（RU課金のアカウント型）	Cosmos DB アカウント	継続バックアップ（PITR）または定期バックアップ（サポート復元）	連続バックアップなら自己復元も可能、定期はサポート

本記事の主題は、質問内容どおり MongoDB vCore（クラスター型）を中心に扱います。なお、最近のドキュメントでは vCore 系が Azure DocumentDB（MongoDB 互換）という名称で記載されることがあります（ポータル表示は環境や時期で揺れます）。

なぜ「PITR（Point-in-Time Restore）」が使えないのか

今回のパターンで PITR が使えない理由はシンプルで、復元ポイントが紐づく“元のアカウント/クラスター”が消えているためです。さらに、削除後に新規作成すると、そこにある PITR は「作り直した後の世界線」しか復元できません。つまり、消してしまった元データを戻すには、削除前に存在していた側のバックアップを参照する必要があります。

MongoDB vCore（クラスター型）の自動バックアップと「削除後の保持期間」

MongoDB vCore（クラスター型）は、プラットフォーム側で自動バックアップが行われ、ポイントインタイム復元（PITR）を前提に設計されています。ただし重要なのは、削除してしまった後にバックアップがいつまで残るかです。

現行の公式ドキュメントでは、クラスターのバックアップ保持について次のように整理されています。

稼働中（アクティブ）クラスター：バックアップ保持 35日
削除済みクラスター：バックアップ保持 7日
バックアップファイルはエクスポートできず、復元用途でのみ利用

一方で、少し前の Microsoft Q&A の回答では「削除後 30 日以内なら復旧できる」と案内されているケースもあります。機能や保持仕様は更新される可能性があるため、現実的な運用としては“日数に賭けないで、即チケット”が最適解です。

復旧できるかどうかの判断軸

サポートへ依頼する前に、復旧可能性を左右するポイントを整理します（結論としては「条件が揃っていなくても依頼価値はある」ことが多いです）。

判断軸	見方	なぜ重要か
削除からの経過時間	Azure Activity Log / 運用ログ / 実行履歴	削除済みバックアップの保持期間に直結
「同名で作り直したか」	作り直したクラスター/アカウント名、作成日時	復元ターゲット名の衝突・調査の混乱を生みやすい
対象が vCore か RU 型か	ポータルのリソース種別 / 作成時の選択	復元手段・窓口が異なる
ネットワーク制約	Private Endpoint / VNet / FW の有無	復元後に接続できず「戻ったのに使えない」事故が起きやすい

「削除してしまった」直後にやるべき行動（チェックリスト）

復旧の成功率を上げるために、最初の数十分でやることを手順化しておきます。

削除した正確な時刻（可能なら秒まで）を UTC で確定する（Activity Log を見る）
対象のサブスクリプション ID、リソースグループ名、（分かれば）削除したクラスター名/アカウント名を控える
もし作り直してしまったなら、作り直した側の名前・作成時刻・接続情報も控える
アプリ側の書き込みを止める（作り直した環境に書き込みが走ると、後でマージが難しくなる）
Azure サポートへ復旧依頼を起票する（次章）

Azure 側バックアップからの復旧は「自分で実行できる？」

結論として、削除済みリソースの復旧は、自分だけで完結しないことが多いです。

MongoDB vCore（クラスター型）：クラスターが生きていればポータルの PITR で新規クラスター作成として復元できますが、削除済みだとポータル導線に乗れないため、サポート依頼が必要になるケースがあります。復元後は新しいクラスターに切り替える運用が前提です。

なお、（RU型の Cosmos DB アカウントの場合ですが）バックアップ復元は「復元先として新しいアカウントが作られる」「事前に作ったアカウントへは復元できない」などの制約が明記されています。削除後に同名で作り直すと、復元名の衝突や調査の混乱を招くため、基本は作り直す前にサポートへが推奨です（作り直した場合でも、その事実をサポートに共有することが重要です）。

Azure サポートプランの制約（Basic では技術チケット不可）

「問い合わせたいのに、そもそもチケットが作れない」問題はよく起きます。整理すると次のとおりです。

プラン	技術サポート（チケット）	選べる重大度	注意点
Basic	原則不可	―	課金/契約などのサブスク管理支援が中心
Developer	可	Severity C のみ	初動は営業時間対応が基本
Standard	可	Severity A/B/C	緊急度の高いケースは上位が有利
Professional Direct など	可	Severity A/B/C	より短い応答時間や支援範囲が拡大

Developer プランでも復旧依頼は可能ですが、重大度を上げられないため「一刻を争う本番障害」なら Standard 以上の検討余地があります。

Azure ポータルからサポートチケットを起票する手順（最短ルート）

削除済みでリソースが選べない場合でも、基本はポータルから起票できます。以下は迷いにくい手順です。

Azure ポータルにサインイン
上部検索で Help + support（ヘルプとサポート） を開く
Create a support request（サポートリクエストの作成） を選ぶ
種類は「Technical（技術）」を選び、サービスに Azure Cosmos DB を指定
API/種類の選択で MongoDB (vCore)（該当する方）を選ぶ
リソースが残っていない場合は、サブスクリプションを対象にして進める
Problem type / subtype は Backup & Restore または Data recovery 系を選ぶ
Developer プランなら Severity C を選択
詳細情報をできるだけ具体的に記載して送信（次章のテンプレ参照）

もし「チケットを作る権限がない」と出る場合は、サブスクリプションに対して Owner / Contributor / Support Request Contributor 等の権限が必要です。運用チーム内で権限が分かれている組織では、ここで詰まりやすいので先に確認してください。

サポートチケットに書くべき情報（不足すると復旧が遅れる）

サポート側は「どのバックアップを」「どの状態に」戻すかを特定できないと動けません。最低限、次の情報をまとめて渡すと往復が減ります。

項目	例	補足
削除日時（UTC）	2025-12-14T01:23:45Z	Activity Log で確定。UTC 指定が重要
サブスクリプションID	xxxx-xxxx-xxxx	必須
リソースグループ名	rg-prod-db	削除前と再作成後で違うなら両方
削除した側の名前	mongo-prod-cluster	分かる範囲で
再作成した側の情報	同名/別名、作成時刻	同名の場合は必ず明記（混乱を防ぐ）
求める復元地点	削除直前 / 事故の直前	秒単位が望ましい

そのまま貼れる：復旧依頼テンプレ（MongoDB vCore / Cosmos DB for MongoDB）

サポートに伝える文章は、丁寧さよりも特定に必要な情報の網羅が大切です。以下をベースに埋めてください。

件名：
[Data Recovery] Azure Cosmos DB for MongoDB (vCore) を terraform destroy で削除してしまったため復旧希望

概要：
terraform destroy の実行により、Azure Cosmos DB for MongoDB (vCore) クラスターを誤って削除しました。
削除後に新規クラスターを作成してしまい、ポータル上で PITR を実行できません。
Azure 側の自動バックアップから、可能な範囲で削除前の状態へ復旧を依頼します。

削除日時（UTC）：
YYYY-MM-DDThh:mm:ssZ（可能なら秒まで）

サブスクリプションID：
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

リソースグループ：
削除前：rg-xxxx
再作成後：rg-yyyy（再作成していない場合は空欄）

削除したクラスター名（分かる範囲で）：
cluster-xxxx

再作成したクラスターの有無：
あり / なし
（ありの場合）クラスター名：cluster-yyyy
（ありの場合）作成日時（UTC）：YYYY-MM-DDThh:mm:ssZ

希望する復旧ポイント：
削除直前（YYYY-MM-DDThh:mm:ssZ）

補足：
・削除前に使用していた接続元（VNet/Private Endpoint 等）がある場合は、復旧後に再設定が必要であることを理解しています。
・復旧が新しいクラスター作成として提供される場合、アプリ側の接続先を切り替えて対応します。

復旧後にやるべきこと（「戻ったのに繋がらない」を防ぐ）

MongoDB vCore の復元は「元のクラスターがそのまま戻る」というより、復元ターゲットとして新しいクラスターが作成される形になります。復元後は、最低限次を確認してください。

アプリの接続先を新クラスターへ切り替え（接続文字列・認証情報・DNSなど）
ネットワーク設定を再構成（Private/ Public の公開範囲、必要なら許可IP、ルーティング）
高可用性（HA）が必要なら有効化（復元直後は無効になっていることがある）
監視（メトリクス/ログ/アラート）を戻す

実例：サポート→製品チーム連携で復旧できたケース

同様の事故（terraform destroy による削除、削除後に再作成、PITR が使えない）について、Microsoft Q&A では次の流れで解決した例が報告されています。

質問者が復旧可否と問い合わせ方法を相談
モデレーターが手順を案内し、状況によりチケット作成を支援
サポートエンジニアが削除日時やサブスクリプション等の情報を確認
製品チーム（Product Group）と連携して復旧作業
結果として、MongoDB クラスターが復旧してアクセス可能になった

すべてのケースで同様に復旧できるとは限りませんが、少なくとも「完全に詰み」と決めつける前に、必要情報を揃えてサポートへ依頼する価値があることを示す具体例です。

再発防止：Terraform / IaC で「消せない仕組み」を作る

復旧できたとしても、誤削除は事業リスクそのものです。IaC 前提なら、次の“多層防御”が効きます。

Terraform 側のガードレール

lifecycle の prevent_destroy を重要リソースに付ける（Cosmos/ネットワーク/鍵など）
本番は destroy を実行するパイプラインを分離し、承認フローを必須にする
ワークスペース/環境ごとに サブスクリプションを分ける（「違う環境に打った」が起きにくい）

Azure 側のガードレール

リソースロック（CanNotDelete） を運用で付与（Terraform 管理外にすると事故耐性が上がる）
Azure Policy で「特定タグが付いた DB は削除禁止」などの統制をかける

バックアップ設計を「復元手段」から逆算する

“自動バックアップがある”だけでは安心できません。復元に誰が関与するのか、どのくらいの復元粒度が必要かで選ぶべき方式が変わります。

狙い	向く選択肢	ポイント
自分で 7〜30 日の範囲を即時復元したい	（RU型なら）継続バックアップ（Continuous）	7日/30日ティアがあり、PITR で自己復元できる
サポート復元でもよいが、復旧できる期間を伸ばしたい	定期バックアップ（Periodic）の保持期間見直し	既定保持は短いので、運用要件に合わせる
最悪 Azure 側が無理でも自分で戻したい	外部退避（定期エクスポート/多重保管）	“サービス外”にもコピーを持つ

よくある質問

削除後に同名で作り直してしまった。もう無理？

無理とは限りません。ただし復旧側の特定が難しくなるため、チケットには「同名で再作成した事実」「再作成した日時」「再作成後のリソース情報」を必ず書いてください。定期バックアップの復元手順でも、同名再作成の有無をサポートへ共有する重要性が明記されています。

Basic プランでも何とかならない？

課金・契約系の問い合わせは可能でも、今回のような「データ復旧」は技術サポートの領域です。技術チケットを前提に動く必要があるため、原則としてサポートプランが必要になります。

（RU型の場合）削除したアカウントは自分で戻せる？

連続バックアップ（Continuous）を利用している場合、削除済みアカウントをポータルから復元できる仕組みがあります（復元可能な保持期間の範囲内）。

まとめ

terraform destroy による Cosmos DB for MongoDB（MongoDB vCore）誤削除でも、Azure 側バックアップから復旧できる可能性はある
ただし、削除済みバックアップの保持期間は限定的で、行動が遅れるほど不利（現行ドキュメントでは削除済みクラスターの保持が短い旨が示されている）
復旧は多くの場合自己完結ではなく Azure サポート経由。Developer 以上のプランでチケット起票し、必要情報を揃えて依頼する
再発防止は「Terraform のガードレール」「Azure のロック/統制」「バックアップ設計の見直し」をセットで実装する

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。