Azure Databricksワークスペース誤削除時の復旧方法と再発防止ガイド

「うっかり Azure Databricks ワークスペースを削除してしまった…」という事態は、誰にでも起こり得ます。誤操作だと気づいたとき、復旧できるのか、本番データはどうなるのか、不安で手が止まってしまいがちです。本記事では、削除から約10時間で相談した実例と公式／コミュニティ情報をベースに、Developer サポート プランを前提とした現実的な復旧プロセスと、その後の再発防止策を、実務でそのまま使えるレベルまで具体的に解説します。

Azure Databricks ワークスペース削除の現実を理解する

まず押さえておきたいのは、Azure Databricks ワークスペースは Azure ポータル上からは「元に戻す」ことができない、という点です。Microsoft Q&A や Stack Overflow でも、削除済みワークスペースはユーザー操作では復元できず、技術サポート チケット経由でのみバックエンドのエンジニアが復旧を試みる形であることが繰り返し案内されています。

さらに、2025年の Microsoft Q&A では、誤って削除された Azure Databricks ワークスペースが、サポート経由で 「limited resources（限定的な状態）」として復旧された事例が紹介されており、完全な構成ロールバックはできないという製品仕様も明記されています。

この挙動は、ソフト デリート機能が用意されていてポータルから自分で復元できる Azure Log Analytics や Azure Machine Learning のワークスペースとは対照的です。

サービス	削除後の扱い	自己復旧の可否
Azure Databricks ワークスペース	内部的に一時的に保持されるが、ユーザー操作での復旧は不可	不可（技術サポート経由のみ）
Azure Log Analytics ワークスペース	ソフト デリート期間中はポータルから復元可能	可（ポータルで「Recover」操作）
Azure Machine Learning ワークスペース	ソフト デリート状態からの復元が可能だが、一部リソースは再作成が必要	可（ただし完全ロールバックではない）

つまり、Azure Databricks のワークスペース誤削除は、「サポートに頼らないとどうにもならない」性質のインシデントであることを前提に動く必要があります。

結論の整理：ポータルでの復元は不可能、サポートチケットが唯一のルート

今回の QA 事例や公式回答を踏まえると、結論は次のとおりです。

• Azure ポータルや CLI から、削除済み Databricks ワークスペースを自分で復元する方法はない。
• 復旧の唯一のルートは、Azure サポートへの「技術サポート チケット」。
• 時間との勝負。削除後しばらくは内部的なメタデータが保持されるため、早く連絡するほど復旧の可能性が高い（公式 SLA ではなくベストエフォート）。
• 復旧できたとしても、ワークスペースは 「limited resources（限定的な状態）」で戻るだけで、削除前の構成へ完全ロールバックはできない。
• Developer（開発者）サポート プランでも技術サポート チケットの起票は可能。ただし対応時間や SLA は標準／プレミアムより制限される。

特に 「Portal からは絶対に復元できない」という現実を理解しておくと、いつまでもポータルをクリックし続けて時間を浪費することを避けられます。まずはサポートチケットの起票に全力を注ぐべきです。

時間との戦い：削除後どのくらいまで望みがあるのか

Databricks 側の内部実装や保持期間は公式に細かく公開されていませんが、コミュニティで「削除から 10 時間程度で相談して復旧できた」「15 日程度はアーティファクトが取り出せる状態だった」といった事例が共有されています。

もちろん、これは 「保証された復旧期間」ではなくベストエフォートに過ぎません。しかし、「削除からの経過時間」はサポート側の判断材料になるため、チケットには必ず明記し、気づいた瞬間に起票することが重要です。

削除からの経過時間	現場感覚での復旧可能性	ポイント
〜24時間	もっとも高いゾーン。実例でもこの時間帯で復旧したケースが報告されている。	気づいた瞬間にチケット起票。削除時刻を UTC で正確に伝える。
1〜7日	まだ可能性はあるが、日が経つほどリスクが高まる。	「ビジネス影響」「外部ストレージの有無」なども含めて詳細に説明。
7〜15日	コミュニティの一部では 15 日以内に限りアーティファクト抽出ができたという声もあるが、期待はあくまで低め。	「復旧できればラッキー」レベル。並行して新規ワークスペース構築プランも検討。
15日以降	原則として復旧は極めて困難と考えるべき。	サポートに相談しつつも、基本は新規構築・バックアップからの復元を前提に動く。

今回の QA 事例では、削除から約 10 時間で相談し、結果として限定状態での復旧に成功している点からも、「気づいた瞬間に動く」ことの重要性がわかります。

Azure サポートチケットの起票手順（Developer プラン）

ここからは、Developer サポート プランを前提に、実際にどのようにサポートチケットを起票すべきかを、できるだけ具体的な操作レベルで解説します。

Azure ポータルからのサポートリクエスト作成手順

1. Azure ポータルにサインインします。
2. 左側メニュー（または上部検索バー）から 「ヘルプ + サポート」 を開きます。
3. 「新しいサポート リクエスト」 をクリックします。
4. 問題の種類 に 「技術（Technical）」 を選択します。
5. サブスクリプション に、該当する Databricks ワークスペースが属していたサブスクリプションを選びます。
6. サービス は 「Azure Databricks」 を選択します。
7. リソース は、削除されたワークスペース（表示される場合）か、近い関連リソースを選びます。
8. タイトル（概要） に、例えば次のように記入します：
   “Accidentally deleted Azure Databricks workspace – urgent restore request”
9. 問題の詳細 セクションで、後述の情報を日本語＋英語で記載しておくとスムーズです。

チケットに必ず記載したい情報チェックリスト

項目	例	ポイント
サブスクリプション ID	xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx	ポータルのサブスクリプション画面からコピー。打ち間違わないこと。
ワークスペース名	adb-prod-westus-001 など	リソース名と Databricks ワークスペース URL のオーガナイゼーション ID をあわせて伝えると確実。
リージョン	Japan East / West Europe など	復旧作業の対象範囲を明確にするため必須。
リソース ID	/subscriptions/…/resourceGroups/…/providers/Microsoft.Databricks/workspaces/…	アクティビティ ログや IaC テンプレートからコピーしておくと正確。
削除日時（UTC）	2025-12-09T01:23:45Z など	ローカル時間ではなく UTC で伝えると、サポート側での照合がスムーズ。
削除からの経過時間	約 10 時間 など	「現在時刻」とセットで書くと、緊急度を判断しやすい。
ビジネス影響	本番ジョブ停止、ユーザー数、SLA など	「本番 / 検証」「影響ユーザー数」「停止している基幹処理」の有無を具体的に。
サポートプラン	Developer Support Plan	Developer プランでも技術サポートチケットは起票可能である旨はすでに Q&A でも確認されている。

英語問い合わせ文のサンプル

海外サポート エンジニアにそのまま渡せるよう、英語のテンプレートも準備しておくと安心です（必要に応じて日本語も併記）。

Subject:
Accidentally deleted Azure Databricks workspace – urgent restore request

Body:
Hello Azure Support Team,

We accidentally deleted an Azure Databricks workspace and would like to request an urgent restore.

- Subscription ID: <your-subscription-id>
- Workspace name: <your-workspace-name>
- Resource ID: <full-resource-id>
- Region: <region>
- Workspace URL (if available): <https://<yourworkspace>.azuredatabricks.net>
- Deletion time (UTC): 2025-12-09T01:23:45Z
- Time elapsed since deletion: ~10 hours
- Support plan: Developer support

Business impact:
This workspace hosts production (or staging) workloads, and multiple scheduled jobs have stopped.
We urgently need to access notebooks, jobs, and other workspace artifacts.

We understand that, according to product design, deleted workspaces can only be restored
in a limited-resources state and cannot be fully reverted to the previous configuration.
Even a limited restore that allows us to export our artifacts would be extremely helpful.

Could you please engage the Databricks core engineering team to attempt a restore?

Thank you in advance for your help.

ポイントは、「limited-resources state での復旧でもかまわないので、とにかくアーティファクトにアクセスしたい」という意図を明確に伝えることです。これは、実際の Q&A でも「限定状態での復旧 → 利用者はノートブックなどをコピーして、新しい環境に移す」という流れが推奨されているためです。

Developer プランでの現実的な期待値

Developer サポート プランは、本番環境というよりは 開発・検証向けのサポートプランであり、対応時間帯や SLA が標準／プレミアムよりも制限されます。しかし、前述の Q&A 事例では、Developer プランを利用しつつも、重要度の高さからサポートが Databricks コアチームにエスカレーションし、最終的に復旧までたどり着いています。

したがって、「Developer だから無理だ…」と諦めるのではなく、

• ビジネス影響を具体的に書く
• 復旧できればどれだけ損失を減らせるかも伝える
• 必要であれば電話連絡や Teams ミーティングでの状況共有を申し出る

といった工夫で、「緊急性」と「ビジネス上の重要度」への理解を引き出すことが重要です。

復旧時の「limited resources（限定的な状態）」とは何か

サポートからの回答では、削除されたワークスペースは 「limited resources state」 として復元される、という説明がされています。これは、「削除前とまったく同じ状態に戻る」のではなく、「アーティファクトにアクセスしてコピーできる程度の最小限の状態で蘇る」イメージです。

項目	期待できる状態	想定される対応
ワークスペース UI	ログインして画面を開ける可能性が高い	ノートブックやジョブ設定などをエクスポート／スクリーンショット等で保存
ノートブック	大半のケースで参照・エクスポート可能	Git へのインポート、.dbc/.py 形式でのバックアップ取得
ジョブ定義	一覧や詳細は参照できることが多いが、ジョブ実行はできない場合がある	設定をエクスポート／スクリーンショットし、新ワークスペースで再定義
クラスタ	クラスタ自体は存在しない、もしくは起動不可の状態が多い	スペックやランタイムの情報を控え、新ワークスペースで作り直し
DBFS（/FileStore 等）	リソースグループやストレージの削除状況に依存。削除済み RG の場合は復旧困難。	外部 ADLS/Blob にデータを置く設計にしておくと、ワークスペース削除の影響を最小化できる。
Unity Catalog / メタストア	メタストア側の構成やデータ保護設定に依存。ワークスペース単体削除か、RG ごと削除かで結果が変わる。	本番では「外部テーブル＋ストレージ側でのバックアップ／ソフトデリート」を基本戦略とする。

重要なのは、復旧後のワークスペースを「そのまま使い続ける場」と捉えるのではなく、「アーティファクトを救出するための一時的な避難所」として捉えることです。そのうえで、新しいワークスペースに対してクラスタ・ジョブ・ポリシー等を再構築するほうが、安全で管理もしやすくなります。

復旧後に行うべきチェックリスト（詳細版）

ここでは、復旧後に確認・再設定しやすいよう、チェックリストを整理します。

カテゴリ	確認内容	復旧されていなかった場合の対処
クラスタ	クラスタ一覧の有無、スペック、Databricks Runtime バージョン、オートスケール設定など	要件と過去の構成を元に新規作成。IaC やドキュメントがあればそれを参照。
ジョブ	ジョブ名、スケジュール、依存関係、トリガー、実行ユーザー	ジョブ定義を新ワークスペースに再作成。REST API や CLI での一括登録も検討。
ライブラリ／Init スクリプト	クラスタやジョブで参照している whl/jar/egg、Init スクリプトのパス	外部ストレージや Git から再配置。できれば今後はアーティファクト管理ツールを利用。
シークレット スコープ	スコープ名、格納されているキー、Key Vault 連携の有無	Azure Key Vault 側は残っていることが多いので、再度リンクと権限設定を行う。
ノートブック／Repos	プロジェクト単位のフォルダ構成、Repos（Git）との連携状況	Git 上を最新のソース・オブ・トゥルースにし、そこから再クローンする運用に切り替える。
権限設定	ワークスペース管理者、フォルダ・ノートブック・ジョブ・クラスターなどの ACL	グループベースの RBAC 設計に見直し、再設定。スクリーンショットを取っておくと再現が容易。
Webhook / 外部連携	CI/CD（Azure DevOps・GitHub Actions）、通知（Teams / Slack / メール）の設定	URL・シークレット・イベント種別を再登録。運用ドキュメントにパラメータを残すようにする。
ネットワーク設定	VNet 注入、プライベートリンク、IP アクセスリストなど	ネットワークは Azure リソース側の再設定も絡むため、インフラチームと連携して再構築。

合わせて、削除に至った経緯を把握するために、Azure アクティビティ ログ や Azure Monitor のアラート履歴を確認し、「誰が」「どの操作」で削除したかを特定しておくことも重要です。この情報は、後述する再発防止策（RBAC、リソースロック、二重承認など）の設計にも直結します。

もし復旧できなかった場合の現実的な代替策

残念ながら、サポートから「既に完全に削除されており復旧不可」と回答される場合もあります。その場合に備えて、新規ワークスペースを前提としたリカバリ プランを用意しておくことが重要です。

ステップ 1：データがどこにあるかを正確に棚卸しする

まずは、「Databricks ワークスペース削除 ＝ データ消失」とは限らないことを理解しておきましょう。コミュニティ情報によると、

• デフォルト DBFS（内部 Blob ストレージ）にのみデータを置いていて、かつそのストレージアカウントやリソースグループも削除されている場合、復旧はほぼ絶望的。
• 一方で、ADLS Gen2 / Blob / 外部 DB にデータを保存しており、そこでソフトデリートやスナップショットを有効化していた場合は、ストレージ側からの復元が可能なケースもある。

そのため、次のような観点で棚卸しすることをおすすめします。

• 本番データは Azure Data Lake / Azure Blob / SQL Database など、外部ストレージに置いていたか？
• 外部ストレージで「ソフト デリート」「バージョン管理」「スナップショット」は有効になっていたか？
• DBFS 上のどのパスが「唯一の保管場所」になっていたか？

ステップ 2：新規ワークスペースを作成して再構築する

データの所在が整理できたら、新たな Databricks ワークスペースを作成して再構築するのが現実的な選択肢です。

1. Azure ポータルから、新しい Azure Databricks ワークスペースを作成する（ネットワーク要件や SKU を再検討する良い機会）。
2. ADLS/Blob/DB など、外部データソースをマウント／接続する。
3. Git リポジトリにノートブックが残っている場合は、Databricks Repos として再連携する。
4. ジョブ・クラスタ設定は、残っているドキュメントや過去のエクスポート、ログをもとに再定義する。
5. このタイミングで、後述の「リソースロック」「RBAC」「IaC」などの再発防止策を一気に導入してしまう。

一見大変そうですが、「どうせ一から作り直すなら、この機会に構成をきれいにしたほうが長期的には得」という考え方もできます。特に、試行錯誤の履歴が長く積み上がったワークスペースほど、「リフト＆シフト」より「クリーン スタート＋必要なものだけ再インポート」のほうが運用しやすくなります。

再発防止のための実務的なポイント

ここからは、同じ事故を繰り返さないための 具体的なガードレール を整理します。技術的な仕組みと運用ルールの両面から対策することが重要です。

リソース ロック（Delete ロック）の活用

Azure には、リソース削除を防ぐための 「リソース ロック」 機能があります。Databricks ワークスペースや、その マネージド リソース グループ に対して、少なくとも CanNotDelete（削除禁止）ロック を付与しておくことが推奨されています。

1. ポータルで Databricks ワークスペースを開く。
2. 左メニューの 「ロック」 をクリック。
3. 「追加」 を押し、ロック名を入力。
4. ロックの種類 に 「削除（CanNotDelete）」 を選択。
5. 同様に、マネージド リソース グループ（databricks-rg-xxxxx）側にもロックを設定。

こうしておくことで、誤ってリソースグループごと消してしまい、DBFS やノートブックを完全消失させるリスクを大きく下げられます。

RBAC の最小権限化と削除権限の分離

「なんとなく Owner をばらまく」運用は、Databricks に限らず重大なリスクです。次のような方針をおすすめします。

• 日常運用担当者には Owner ではなく Contributor 相当＋カスタムロール を割り当てる。
• カスタムロールでは Microsoft.Databricks/workspaces/delete 等の削除権限を外す。
• 削除権限を持つのは、クラウド管理者の少数グループのみに限定する。
• Azure AD の Privileged Identity Management (PIM) を使い、「一時的にだけ Owner になれる」ようにする。

このように 「削除できる人」と「日常運用をする人」を分けることで、誤削除の可能性を大きく減らせます。

IaC（Infrastructure as Code）で構成をコード化する

Databricks ワークスペースやネットワーク周り、ポリシーなどの構成は、Bicep / ARM / Terraform などでコード化しておくと、万が一のときに再構築しやすくなります。

• ワークスペースリソース（SKU、リージョン、Managed RG 名など）
• VNet 注入構成、サブネット、NSG、ルートテーブル
• ポリシー（クラスタポリシー、ジョブ実行ポリシーなど）

すべてを一気に IaC 化するのは大変なので、「本番環境から着手」「頻繁に変更されない部分から着手」といった優先度づけがおすすめです。

ノートブック・設定のバックアップ戦略

Databricks 自体にもノートブックのエクスポート機能や Repos 機能がありますが、誤削除対策としてはやや心許ない部分もあります。以下のような多重防御が現実的です。

• Databricks Repos で Git 連携し、ノートブックの正本を Git 側に置く。
• 定期的に workspace export API / CLI を使い、全ノートブックをストレージにバックアップする。
• ジョブ、クラスタ定義も REST API から JSON で取得し、Git でバージョン管理する。

特に、「ノートブックは Repos（Git）に置き、ワークスペースは実行のためのキャッシュに過ぎない」という思想で設計しておくと、ワークスペース削除のインパクトは大きく下げられます。

アクティビティ ログのアラートと Azure Policy の活用

削除操作が行われた瞬間に気づけるよう、Azure アクティビティ ログ アラート を設定しておくのも有効です。

• シグナル：Delete 操作（リソースタイプ：Microsoft.Databricks/workspaces、Microsoft.Resources/subscriptions/resourceGroups）
• アクション：メール / Teams / Webhook 通知

また、Azure Policy を用いて、

• environment=prod タグが付いた Databricks ワークスペースは削除禁止
• 指定タグやロックが付与されていない本番ワークスペースの作成を拒否

といった ルール違反を技術的に防ぐ ガードレールを設けることもできます。

運用ルールとしての二重承認＋待機期間

最後に、技術的な対策だけでなく、運用ルール も整備しておくとより安全です。

• ワークスペース削除は必ず 変更申請＋二重承認 を経て実施する。
• 承認から実際の削除までに 最低 24 時間 の「冷却期間」を設ける。
• 削除前に、ノートブックやジョブ定義、設定のバックアップを取得したことをチェックリストで確認する。

これらを 「紙や口頭」ではなくチケットシステムやワークフローに組み込むことで、「うっかり削除」が起こりづらい文化を作ることができます。

対策カテゴリ	代表的な施策	主な効果
技術的ガード	リソースロック、Azure Policy、RBAC	権限や設定ミスによる誤削除を技術的にブロック
構成管理	IaC、Git、API バックアップ	削除されてもすぐに再構築できる状態にしておく
検知	アクティビティ ログ アラート	誤削除に「すぐ気づく」ことで復旧のチャンスを最大化
運用プロセス	二重承認、冷却期間、チェックリスト	人為的なミスの発生率自体を下げる

ケーススタディ：削除から約10時間で相談した実例

今回の QA 事例を要約すると、次のような流れでした。

1. ユーザーが Azure Databricks ワークスペースを誤って削除。
2. 約 10 時間後に、Developer サポート プランで Microsoft Q&A に相談。
3. 回答では、「ポータルからは復元できない」「唯一の方法は技術サポートチケット」「できるだけ早く起票すべき」と明言。
4. ユーザーは Azure サポートに技術サポートチケットを起票。
5. その後、Microsoft 側から 「limited resources 状態でワークスペースを復旧した。これは製品設計上、完全ロールバックはできない仕様である」との回答。
6. ユーザーは復旧したワークスペースから必要なアーティファクトを抽出し、別ワークスペースで再構築。

このケースから学べるポイントは、

• Developer プランでも技術サポートチケットは起票できること
• 削除後の相談が早ければ早いほど、少なくとも「アーティファクトを救出するチャンス」が生まれること
• 復旧はあくまで限定的であり、完全なロールバックは期待すべきではないこと

です。これを前提に、日頃からバックアップ戦略と運用ルールを整備しておくことが重要です。

まとめ：削除してしまったら「迷わずサポート」＋「消しても大丈夫な設計」へ

最後に、本記事の要点を整理します。

• Azure Databricks ワークスペースは、Azure ポータルや CLI から自己復旧することはできない。
• 復旧の唯一のルートは、Azure サポートへの技術サポート チケットであり、削除に気づいた瞬間に起票することが最重要。
• 復旧できたとしても、ワークスペースは 「limited resources」状態での復旧にとどまり、削除前の構成を完全にロールバックすることはできない。
• 復旧後は、クラスタ・ジョブ・ライブラリ・シークレット・権限などを一つ一つ確認し、新しいワークスペースで再構築する前提で動く。
• もし復旧不能なら、外部ストレージのデータ復元＋新規ワークスペース構築を現実的な代替策として進める。
• 再発防止のために、リソースロック、RBAC、IaC、Git 連携、アクティビティ ログ アラート、Azure Policy、二重承認といったガードレールを組み合わせる。

Azure Databricks は、データ分析・機械学習の中核プラットフォームになり得る強力なサービスです。その一方で、ワークスペース削除のような操作ミスが重大インシデントにつながるリスクもあります。「もし削除してしまっても、データと構成を素早く取り戻せる設計」を目指して、今回の知見を自組織のガバナンスに組み込んでいきましょう。