AzureのWindows VMをサイズ変更した直後に「データドライブが消えた」と見える現象は、実際には一時ディスク(D:)の再初期化、マネージドデータディスクの未接続、またはドライブレター変更が主因です。復旧できるケース/できないケースを切り分け、具体的な確認手順と再発防止策をまとめます。
Azure Windows VMのサイズ変更で「データドライブが消えた」と感じる理由
AzureポータルでWindows VMのサイズを変更（スケールアップ/スケールダウン）したあと、これまで見えていたドライブがOS上から見えなくなることがあります。特にD2alds_v6 → D2ads_v6のように「系列は近いがサイズ名が変わる」変更では、VMが別ホストへ再配置される可能性が高く、見え方が変わりやすいです。
ただし、ここで重要なのは「本当にディスクが消えたのか」「OS上の表示・割り当てが変わっただけなのか」を切り分けることです。結論から言うと、次のどれかに該当します。
- 一時ディスク（Temporary Storage）だった：サイズ変更/再デプロイ/ホストメンテで初期化され、保存データは復旧できない
- マネージドデータディスクだった：ディスク自体は残っていることが多く、再接続やドライブ文字の再設定で復旧できる可能性が高い
- ドライブレターだけが変わった：同じディスクが別の文字で見えている（例：E: → F:）
- Windows側でオフラインになった：ディスクの管理でオンライン化すれば見える
以降は、最短で復旧判断できるように「切り分け → 復旧 → 再発防止」の順で具体的に解説します。
まず最初に確認すること：そのドライブは「永続」か「一時」か
AzureのWindows VMで扱うストレージは、大きくOSディスク、マネージドデータディスク、一時ディスク（ローカル一時ストレージ）に分かれます。ここを誤ると、復旧できるものを「消えた」と諦めたり、逆に復旧できないものに時間を使ってしまいます。
| 種類 | Azure上の実体 | Windowsでの典型的な見え方 | サイズ変更/再デプロイ時の挙動 | データ復旧 | 推奨用途 |
|---|---|---|---|---|---|
| OSディスク | マネージドディスク | C:（OS） | 基本的に保持 | 可能（バックアップ/スナップショット含む） | OS、アプリ本体 |
| マネージドデータディスク | マネージドディスク | E: / F: など（任意） | ディスク自体は残ることが多いが、VMから未接続になる場合あり | 高確率で可能（再接続で見える） | DB、ファイル、永続ログ |
| 一時ディスク（ローカル一時ストレージ） | ホスト側のローカルディスク（エフェメラル） | 多くはD:（ラベルがTemporary Storageのことが多い） | 再割り当てのタイミングで再作成・初期化 | 原則不可 | pagefile、TEMP、キャッシュ、ワーク領域 |
「消えたのがD:ドライブかもしれない」という追加質問が出るのは自然です。AzureではWindows VMのD:に一時ディスクが割り当てられる構成が一般的で、サイズ変更や再配置で内容が消える設計だからです。
切り分けの最短ルート：AzureポータルとWindowsで同時に確認する
次の表のとおり、Azureポータル側とWindows側を並行して確認すると、最短で原因に到達できます。
| 確認ステップ | どこで見る | 見るポイント | 判断 | 次のアクション |
|---|---|---|---|---|
| ディスクがVMに接続されているか | Azureポータル：VM → 設定 → ディスク | データディスク一覧に対象があるか、LUNは何か | 一覧にあるなら「未接続ではない」 | Windows側でオフライン/ドライブ文字を確認 |
| 未接続ディスクが存在するか | Azureポータル：すべてのリソース → 種類=ディスク | 状態が「未接続（Unattached）」のディスク | 見つかれば再接続できる可能性大 | VMへアタッチしてドライブ文字を割り当て |
| Windowsがディスクを認識しているか | Windows：ディスクの管理 / PowerShell | ディスクが「オフライン」「不明」「未初期化」等になっていないか | 見えているのにドライブがないだけのことが多い | オンライン化・文字割り当て |
| 一時ディスクかどうか | Windows：エクスプローラー / ボリュームラベル | D:のラベルがTemporary Storage、容量がVMサイズ依存 | 一時ディスクなら中身は消える設計 | 復旧ではなくバックアップ/再構築へ切替 |
マネージドデータディスクが「消えた」場合の復旧手順
ここからは、もっとも復旧できる確率が高いマネージドデータディスクを想定し、ポータルとWindowsの両面から復旧する手順をまとめます。ポイントは「ディスクを見つける → 正しく接続する → OS側でオンライン化してドライブを付け直す」です。
AzureポータルでVMのディスク構成を確認する
- Azureポータルで対象VMを開きます。
- 左メニューの「設定」→「ディスク」を開きます。
- データディスクの欄に、問題のディスク名が表示されているかを確認します。
ここでディスクが表示されていれば、「Azure的には接続済み」です。OS側の表示（オフライン、ドライブ文字なし、認識遅延など）が原因であることが多いので、次のWindows側の確認に進みます。
リソースグループ内の「未接続（Unattached）」ディスクを探す
VMの「ディスク」に見当たらない場合でも、ディスク自体はサブスクリプション内に残っていることがあります。サイズ変更は内部的に停止（割り当て解除）や再配置を伴うことがあり、そのタイミングでVMから外れたように見えるケースがあるためです。
- Azureポータルの「すべてのリソース」を開き、種類を「ディスク」に絞り込みます。
- ディスクの状態が「未接続（Unattached）」のものを探します。
- ディスク名、サイズ、作成日時、タグ（環境名/用途）を見て候補を絞ります。
未接続ディスクが複数あり迷う場合は、「ディスクサイズ」と「タグ」が強い手掛かりになります。運用的には、日頃からディスクに「用途」「システム名」「担当」などのタグを付けておくと復旧時に圧倒的に楽です。
対象ディスクをVMへ再接続（アタッチ）する
未接続ディスクが見つかったら、ディスクの画面からVMへ再接続します。ポイントはLUN番号です。LUNはSCSIの論理番号で、Windows側での並びやドライブレターのズレに影響します。
- 対象ディスクのリソースを開きます。
- 「VMに接続（Attach to VM）」（または同等の操作）を選びます。
- 対象VMを選択し、空いているLUN番号を指定して接続します。
- 接続後、VM側の「ディスク」画面でデータディスクとして表示されることを確認します。
GUIが難しい場合はAzure CLIでも確認/操作できます。運用でCLIを使えると、夜間トラブルでも素早く状況把握できます。
# VMに紐づくデータディスク一覧（LUN含む）
az vm show -g <resource-group> -n <vm-name> --query "storageProfile.dataDisks[].{name:name,lun:lun,managedDisk:managedDisk.id}" -o table
# リソースグループ内のディスク一覧（未接続の洗い出しに便利）
az disk list -g <resource-group> --query "[].{name:name, sizeGB:diskSizeGb, state:managedBy}" -o table
上の例で、state（managedBy）が空なら「未接続」の候補です。
Windows側でディスクをオンラインにしてドライブ文字を戻す
ディスクがVMに接続できたら、次はWindowsでの確認です。ここで焦って「初期化」や「フォーマット」を実行すると、復旧できたはずのデータを破壊してしまうので注意してください。
ディスクの管理で状況を確認する
- RDPでVMにログインし、diskmgmt.msc（ディスクの管理）を開きます。
- 該当するディスクが表示されているか確認します（サイズが一致するディスクが手掛かり）。
- 状態が「オフライン」なら右クリックして「オンライン」にします。
- パーティションがあるのにドライブ文字がない場合、右クリックして「ドライブ文字とパスの変更」から文字を割り当てます。
「以前はE:だったからE:に戻す」といった運用があるなら、同じ文字を再割り当てするとアプリの設定変更が最小で済みます。逆に、今後ドライブ文字の揺れを減らしたい場合は、後述のマウントポイント（例：C:\Data）運用が堅実です。
diskpartで強制的に再認識・割り当てする
ディスクの管理で表示が追いつかない/GUIで操作しづらい場合は、diskpartが確実です（実行は管理者権限で）。
diskpart
rescan
list disk
select disk <番号>
detail disk
online disk
attributes disk clear readonly
list volume
select volume <番号>
assign letter=E
exit
ここでunallocated（未割り当て）やRAWに見える場合、慌てて初期化しないでください。ディスクの選択ミス、暗号化（BitLocker）、ストレージスペース構成、またはディスク破損など複数の可能性があります。スナップショットやバックアップがあるなら、まずはそちらを優先して復旧計画を立てるのが安全です。
PowerShellで「どのディスクが何か」を見える化する
ドライブレターが変わっただけなのか、そもそもディスクが見えていないのかを短時間で判断するには、PowerShellの標準コマンドが便利です。
# ディスク一覧（番号、サイズ、接続種別）
Get-Disk | Select-Object Number, FriendlyName, BusType, Size, OperationalStatus
# ボリューム一覧（ドライブレター、ラベル、ファイルシステム）
Get-Volume | Select-Object DriveLetter, FileSystemLabel, FileSystem, SizeRemaining, Size
# パーティションとドライブ文字の対応
Get-Partition | Select-Object DiskNumber, PartitionNumber, DriveLetter, Size
特にFileSystemLabel（ボリュームラベル）を日頃から「DATA」「LOG」「DB」など用途で揃えておくと、トラブル時に「どれが重要ディスクか」を即断できます。
BitLockerや暗号化が原因で見えないケース
データディスクをBitLockerで暗号化している場合、再接続後に自動でロックが解除されず、エクスプローラーに出てこない（またはアクセス不能）ことがあります。その場合は状態確認と解除が必要です。
# BitLockerの状態確認
manage-bde -status
# 解除が必要な場合（回復キーが必要）
manage-bde -unlock E: -RecoveryPassword <回復キー>
回復キーの保管場所（Azure Key Vault、AD DS、Intuneなど）を運用で決めていないと、ここで詰まりやすいので要注意です。
D:ドライブ（一時ディスク/Temporary Storage）だった場合の結論と対処
追加の確認としてよくあるのが「消えたのがD:ドライブなら、データは戻らないのか？」という質問です。結論は次のとおりです。
- D:がAzureの一時ディスク（Temporary Storage）なら、保存していたデータは原則として復旧できません。
- 一時ディスクはVMホスト上のローカルストレージで、サイズ変更、再デプロイ、割り当て解除、ホストメンテナンス等で再作成・初期化される前提です。
つまり、運用上は「D:は消えるもの」と考えるのが正解です。実務的には、次のような対応に切り替えることが重要になります。
一時ディスクに置いてよいもの・置いてはいけないもの
| 用途 | 一時ディスクに置く | 理由 | 代替（永続ストレージ） |
|---|---|---|---|
| TEMP、キャッシュ、ビルド成果物 | 可 | 消えても再生成できる | 不要（必要ならデータディスク） |
| pagefile（ページファイル） | 条件付きで可 | 性能面で有利なことがあるが、再起動/再配置でリセット前提 | OSディスクまたは要件に応じて設定 |
| アプリの永続ログ | 不可 | 障害時に一番必要なログが消える | データディスク、Log Analytics、Blob |
| DBデータ、ファイルサーバーデータ | 不可 | データ消失リスクが高すぎる | マネージドデータディスク、Azure Files |
「一時ディスクに置いてしまった」場合の現実的な復旧ルート
一時ディスクそのものからの復旧は期待できないため、現実的には次のどれかになります。
- Azure Backupやアプリ側のバックアップから復元する
- アプリが別ストレージへ書き出していた副本（Blob、Files、DBのレプリカ等）から再構築する
- 復旧手段がない場合は、残念ながらデータは失われたと判断し、再発防止策に注力する
「重要データは必ずマネージドディスクへ」という運用原則は、こうした事故が現場で頻発するからこそ定着しています。
サイズ変更で起きやすい「見えなくなる」パターン集
ここでは、実際の現場でよくある“勘違いポイント”を整理します。問題が再発した際の切り分けが速くなります。
ドライブレターが変わっただけ
- 例：以前E:だったデータディスクが、再配置後にF:になった
- 対策：ボリュームラベルで識別し、必要なら同じ文字に戻す
ディスクがオフラインになっている
- Windowsの「ディスクの管理」でオフライン表示になることがある
- 対策：オンライン化してからドライブ文字を割り当て
自動マウント（automount）が無効になっている
- 稀にポリシーや操作で自動マウントが無効だと、新規ディスクが文字なしで追加される
- 対策：diskpartでautomountを確認し、必要なら有効化する
diskpart
automount
automount enable
exit
VMサイズに依存するローカル一時領域を「データディスク」と誤認していた
サイズ名や系列によっては、ローカル一時ストレージの容量や構成が変わります。これを“速いから”という理由でアプリのデータ置き場にしていると、サイズ変更で初期化され「データドライブが消えた」と見えます。設計上の前提なので、重要データの置き場としては不適切です。
それでも見つからないとき：ディスクが本当に消えた可能性の確認
AzureポータルのVM画面にも、未接続ディスクにも見つからない場合は、次の順で「ディスクがどう扱われたか」を確認します。
アクティビティログでディスク操作の履歴を追う
VMのサイズ変更そのものは通常ディスク削除を伴いませんが、運用中の別操作（誤削除、スクリプト、IaCの差分適用など）が重なっていることがあります。まずはAzureポータルのアクティビティログで、ディスクに対するDelete/Detach/Updateが走っていないか確認します。
- ディスクリソースのアクティビティログ
- VMリソースのアクティビティログ（サイズ変更時刻の前後）
- 自動化（Azure DevOps、GitHub Actions、Terraform等）があるなら実行履歴
バックアップ/スナップショットの有無を確認する
本当にディスクが削除されていた場合、現実的な復旧はスナップショットまたはAzure Backupなどのバックアップに依存します。トラブル時に「あるかないか」で、復旧難易度と復旧時間が大きく変わります。
- ディスクスナップショットがあれば、その時点のディスクを作成してVMへ接続
- Azure Backupがあれば、ファイル単位/ディスク単位で復元（構成により異なる）
「バックアップがない」「削除から時間が経っている」という条件が重なるほど、復旧は厳しくなります。重大インシデントとして扱い、必要に応じてAzureサポートへの相談も検討してください。
再発防止：Azure Windows VMで“消えない”データ配置を作る
サイズ変更は性能調整のために今後も行うはずです。毎回ヒヤッとしないために、運用ルールを先に整備しておくのが最も効きます。
重要データは必ずマネージドデータディスクへ
- DBデータ、アップロードファイル、永続ログ、設定ファイルなどはマネージドディスク（またはAzure Files/Blobなど）に置く
- 一時ディスクは“消える前提”のワーク領域に限定する
ドライブ文字に依存しない設計に寄せる
アプリやバッチが「E:固定」で作られていると、サイズ変更や運用変更のたびに事故が起きます。次のどれかを採用すると、障害時の復旧が安定します。
- ボリュームラベルで識別し、起動時にドライブ文字を自動で付け直す（PowerShellで実装可能）
- ドライブ文字ではなくマウントポイント（C:\Data 等）でパスを固定する
- OS起動時のチェックリスト（後述）をRunbook化する
サイズ変更前後で確認するチェックリストを固定化する
| タイミング | 確認項目 | 確認方法 | 目的 |
|---|---|---|---|
| サイズ変更前 | データディスク名・LUN・容量 | VM → ディスク / az vm show | 後で“正しいディスク”を特定する |
| サイズ変更前 | Windowsのドライブレターとラベル | Get-Volume / エクスプローラー | ドライブレター変化に備える |
| サイズ変更直後 | VMのデータディスク接続状態 | VM → ディスク | 未接続化の早期発見 |
| サイズ変更直後 | Windows側でディスクがオンラインか | ディスクの管理 / Get-Disk | オフラインを即復旧 |
| 平常時 | バックアップの成功/復元テスト | Azure Backup / 復元演習 | いざという時に戻せる状態を保証 |
バックアップ戦略を“復元できる形”で用意する
バックアップは「設定した」だけでは不十分で、復元できることが重要です。サイズ変更のような運用操作に備えるなら、次の組み合わせが現実的です。
- 定期：Azure Backupで保護（要件に合わせて保持期間と世代管理）
- 作業前：重要ディスクのスナップショットを1回取る（作業ロールバック用）
- 監査：バックアップ失敗のアラートを通知（メール/Teams等）
よくある質問
ポータルではディスクが接続済みなのに、Windowsで見えません
- ディスクの管理でオフラインになっていないか確認
- diskpartのrescanで再検出
- ドライブ文字が外れていないか（ボリュームはあるが文字なし）
- BitLockerでロックされていないか
未接続ディスクが複数あります。どれが正しいですか
- 容量、作成日時、タグ、命名規則（VM名や用途）が一致するか
- 迷う場合は、まず別の検証用VMに“読み取り目的”で接続して中身を確認
- 誤ディスクの初期化だけは避ける（復旧不能になり得る）
サイズ変更のたびに怖いので、運用でできる対策はありますか
- 重要データはマネージドディスクへ移し、D:はワーク領域に限定
- ボリュームラベルを統一し、ドライブ文字を固定するスクリプトを起動時に実行
- 作業前スナップショットをルール化し、戻せる状態を担保
まとめ：復旧できるケースと復旧できないケースを最初に分ける
- マネージドデータディスクなら、未接続ディスクを探して再接続し、Windowsでオンライン化・ドライブ文字を付け直すことで復旧できる可能性が高い
- D:などの一時ディスク（Temporary Storage）なら、サイズ変更や再配置で初期化される設計のため、保存データは原則復旧不可
- 今後のために、重要データは永続ストレージへ、バックアップと作業前スナップショットで“戻せる運用”を作る
コメント