Hyper‑V ホストのディスクを抜き差ししただけなのに、Windows Server Backup が突然「致命的なエラー」で起動できず、wbengine.exe が落ちてバックアップが止まる——この現象は、バックアップ対象ではないボリューム変更でも起こり得ます。本記事では、なぜ起きるのかを分解し、最小手順で復旧する方法と、再発防止の実務ポイントまでまとめます。
発生した症状（質問の状況を整理）
今回の状況は、現場でよく見る「ストレージ構成変更をきっかけに Windows Server Backup（WSB）が壊れる」パターンです。ポイントは、バックアップ対象ではないスパンボリューム（動的ディスク）を触っただけでも、WSB 全体が例外で落ちることがある点です。
| 観測された事象 | 具体例 | 読み取れること |
|---|---|---|
| GUI が起動しない | wbadmin.msc を開くと「致命的なエラーが発生しました。エラーの詳細: サーバーが例外をスローしました」 | コンソール初期化（構成読み込み・ボリューム列挙）段階で破綻している可能性が高い |
| エンジンがクラッシュ | イベントログ：wbengine.exe アプリケーションエラー（イベント ID 1000 / 例外コード 0xc0000005） | アクセス違反系の落ち方。構成データの不整合や参照先欠落で起きやすい |
| スケジュールも止まる | 定期バックアップが実行されない | バックアップ定義の読み込み自体が失敗している／開始前に落ちている |
| 手動実行も同じ | wbadmin start backup でも同様のエラー | UI の問題ではなく、WSB の内部状態（カタログ・構成）起因の可能性が濃い |
| 再起動・機能再インストールでも改善しない | 機能の削除→追加でも直らない | OS 上に残るカタログ／構成／メタ情報が温存されている可能性 |
なぜ「バックアップ対象ではないディスク変更」で Windows Server Backup が壊れるのか
結論から言うと、WSB はバックアップ対象のドライブだけを見て動いているわけではありません。内部で「ボリューム構成」「バックアップ履歴」「バックアップ先との紐づけ」などを保持する仕組みがあり、そこに過去のディスク構成が前提として残っていると、構成変更後に不整合が起きます。
Windows Server Backup が持っている「カタログ」とは
WSB には、バックアップの世代管理や一覧表示、復元ポイント列挙などに使うバックアップカタログ（メタ情報）があります。ここに、過去に存在したボリュームやバックアップ関連情報が記録されます。
ディスク構成（特に動的ディスクのスパン、ボリューム GUID、署名、マウントポイント等）が変わると、WSB が起動時に行う「環境列挙」や「既存情報の整合性チェック」で、存在しない参照先を踏んでしまい、結果として wbengine.exe が落ちることがあります。
スパンボリューム（動的ディスク）が絡むと起きやすい理由
- 動的ディスクは、構成情報（どの物理ディスクにまたがるか）への依存が大きく、物理ディスクの抜き差しで構成が崩れやすい
- WSB はバックアップ対象外のボリュームでも、過去に存在したボリューム情報を含めて列挙・評価することがある
- 「以前の構成では成立していた参照」が、ディスク取り外し後に欠落し、未処理例外→アクセス違反（0xc0000005）に繋がるケースがある
「機能の再インストール」で直らないことがある理由
Windows Server Backup 機能を削除→再追加しても、OS 内に残るカタログや構成情報が完全に初期化されない場合があります。そのため、再インストール後も同じ不整合が再現し、wbengine.exe が同じ条件で落ち続けます。
最小手順の解決策：バックアップカタログを削除してリセットする
この障害でまず試すべき定番の対処が、バックアップカタログの削除です。今回のケースでも、これだけで復旧する可能性が高いです。
実行コマンド
管理者権限のコマンドプロンプト（または管理者 PowerShell）で、以下を実行します。
wbadmin delete catalog無人実行したい場合や確認プロンプトを避けたい場合は、環境によっては -quiet が使えることがあります（表示されるメッセージに従ってください）。
このコマンドがやっていること（重要）
- WSB が保持しているローカル側のカタログ情報（バックアップ一覧・構成の紐づけ）を初期化する
- ディスク構成変更で壊れた参照をいったん捨て、現在の構成で作り直せる状態に戻す
- 結果として、wbadmin.msc が起動し、wbengine.exe が落ちずにバックアップを開始できるようになることがある
カタログ削除後にやること（復旧の流れ）
- wbadmin.msc（Windows Server Backup）を起動できるか確認
- バックアップ先ディスクが正しく接続され、十分な空き容量があるか確認
- スケジュールバックアップを再定義（またはジョブを作り直し）
- 手動バックアップで 1 回テストし、イベントログにエラーが出ないことを確認
| タイミング | 確認ポイント | 目安 |
|---|---|---|
| カタログ削除前 | エラー内容の記録（イベント ID / 例外コード / 発生時刻） | 後で切り分けが必要になったときの材料になる |
| カタログ削除直後 | wbadmin.msc の起動可否、wbengine.exe のクラッシュ再発有無 | 改善するならこの時点で変化が出ることが多い |
| 再設定後 | スケジュールが動くか、バックアップ先に新しい世代が作られるか | 「成功したように見えるが世代が増えない」も要注意 |
注意点：カタログを削除すると「何が消えて」「何が残る」のか
wbadmin delete catalog は強力ですが、誤解されやすいポイントがあります。ここを理解してから実行すると事故が減ります。
基本的な考え方
- 消える可能性が高いもの：このサーバーで参照しているバックアップの「一覧情報」や「紐づけ」（いわゆるカタログ）
- すぐ消えるとは限らないもの：バックアップ先ディスク上のバックアップデータ本体（世代データ）
ただし、環境によっては古いバックアップを GUI から辿りにくくなる、または自動世代管理の扱いが変わることがあります。「過去バックアップからの復元が絶対に必要」な環境では、以下のような運用を推奨します。
過去バックアップが必要な場合の現実的な対策
- 可能なら、カタログ削除の前に バックアップの世代情報（version） を控える（WSB が動く範囲で）
- WSB が完全に動かないなら、バックアップ先ディスクを別サーバーに接続して世代情報を確認する（復元手順を検証してから本番サーバーに戻す）
- 「過去世代をどうしても使う」要件があるなら、WSB に依存しすぎず、別製品/別方式での世代管理も検討する
復旧できない場合の「フル手順」：ログ退避＋機能再導入＋カタログ初期化
最小手順で直らない場合は、WSB の周辺状態（ログ、構成、サービス）が壊れている可能性があります。以下は、より徹底して“初期状態に寄せる”ための現場向け手順です。
手順
- ログを退避 次のフォルダーが存在する場合、別の場所にコピー、またはフォルダー名を変更して退避します。
C:\Windows\Logs\WindowsServerBackupログは後で原因調査に使えるため、削除より退避が安全です。 - Windows Server Backup 機能を削除 サーバーマネージャーから「Windows Server Backup」を削除します（GUI の方が確実です）。
- サーバー再起動
- Windows Server Backup 機能を再インストール
- カタログ削除を再実行
wbadmin delete catalog - バックアップジョブの再作成 スケジュール、対象ボリューム、バックアップ先を現在の構成に合わせて作り直します。
切り分けチェック：バックアップカタログ以外に確認すべきポイント
ディスク構成変更後のトラブルは、カタログ不整合が最有力ですが、同時に別の要因が混ざっていることもあります。以下は、現場で「早く原因に当たりを付ける」ためのチェックリストです。
サービス状態の確認
WSB は VSS（ボリュームシャドウコピー）と連携します。サービスが止まっていたり、依存関係が壊れているとバックアップ開始前に失敗します。
| 役割 | サービス名（表示名の例） | ポイント |
|---|---|---|
| バックアップ実行 | Block Level Backup Engine Service（wbengine） | 開始できるか／落ちた直後に停止していないか |
| スナップショット | Volume Shadow Copy（VSS） | 停止しているとバックアップが成立しない |
| ソフトウェアプロバイダー | Microsoft Software Shadow Copy Provider（swprv） | VSS 連携で問題があると失敗しやすい |
| スケジュール実行 | Task Scheduler | スケジュールバックアップが動かない場合に確認 |
VSS ライターの状態確認（Hyper‑V ホストでは特に重要）
Hyper‑V ホストでのバックアップは VSS の整合性に強く依存します。VSS ライターがエラー状態だと、バックアップが開始前に失敗したり、VM 連携が崩れます。
vssadmin list writers理想は、各 Writer が「Stable」相当の正常状態になっていることです。エラー状態が残る場合は、該当するサービス再起動や再起動で直ることもありますが、ディスク構成変更と同時期に発生した場合はカタログ不整合と“二重障害”になっていることもあるため、順番に潰すのが安全です。
「存在しないドライブ」や「変なマウントポイント」が残っていないか
物理ディスクを抜いた後、環境によっては “過去に存在したボリューム” の痕跡が残ります。WSB はボリューム列挙時にそれらを踏み、例外を起こすことがあります。
- ドライブレターが不自然に空いている（例：D がないのに E がある）
- マウントポイントが残っている
- 動的ディスクの管理情報が「失敗」「不明」になっている
最低限、ディスク/ボリュームの現状を把握するために以下を実行します。
diskpart
list disk
list volume
exitシステムファイル破損の確認（0xc0000005 が続く場合）
構成変更と同時に、OS 側の破損や更新失敗が潜んでいることもゼロではありません。カタログ削除でも落ち続けるなら、次を実施しておくと切り分けが前に進みます。
sfc /scannowDISM /Online /Cleanup-Image /RestoreHealthバックアップ再開の「実務テンプレ」：最短で安全に戻す手順
ここでは、現場でよくやる「復旧後に確実にバックアップを再開させる」流れをテンプレ化します。GUI でも可能ですが、障害復旧ではコマンドの方が再現性が高いことが多いです。
ステップ 1：バックアップ先を明確化する
- バックアップ先（外付け USB、別 LUN、NAS など）が安定して接続される構成か
- バックアップ先のファイルシステム、容量、アクセス権に問題がないか
- Hyper‑V ホストの場合、バックアップ先にVM のチェックポイント/一時領域が作られても容量が足りるか
ステップ 2：カタログ削除（最小手順）
wbadmin delete catalogステップ 3：バックアップ定義を作り直す（例）
例として、重要ボリュームを含めてバックアップし、スケジュールを指定して有効化するコマンドのイメージです。実際には環境に合わせてドライブや時刻を調整してください。
wbadmin enable backup -addtarget:E: -include:C: -allCritical -schedule:00:00 -quietHyper‑V ホストで VM 置き場が別ボリューム（例：D:）の場合は、VM の格納先も含める必要があります。
wbadmin enable backup -addtarget:E: -include:C:,D: -allCritical -schedule:00:00 -quiet「バックアップ対象ではないはずのボリュームが巻き込まれていた」事故を防ぐため、含めるボリューム（-include）を明示し、不要なものは入れないのがコツです。
ステップ 4：手動で 1 回だけ実行して結果を確認する
スケジュールだけに頼らず、まず手動で 1 回通して成功を確認します。
wbadmin start backup -backupTarget:E: -include:C: -allCritical -quiet成功したら、バックアップ先に新しい世代が作られていること、イベントログに wbengine のクラッシュが出ていないことを確認します。
「なぜ wbengine.exe が 0xc0000005 で落ちるのか」まで踏み込んだ説明
0xc0000005 はアクセス違反の代表的な例外コードで、アプリケーションが「参照してはいけないメモリ」を触ったときに出ます。WSB でこの落ち方になるときは、概ね以下のどれかの形で「想定外の状態」ができています。
- カタログ内に存在しないボリューム（GUID/ID）が残り、列挙処理が欠落に耐えられず落ちる
- 動的ディスクやスパン構成に関連する情報が中途半端に残り、問い合わせで例外が出る
- バックアップ先との紐づけが壊れ、世代情報の読み込みが破綻する
- VSS の状態不整合（Writer がエラーのまま）とカタログ不整合が重なり、異常系に入りやすくなる
重要なのは、「ディスク構成を変えた」こと自体が悪いのではなく、変更前の前提を持ったまま WSB が動こうとしている点です。だからこそ、wbadmin delete catalog で前提（カタログ）を捨てるのが、最短で効きます。
再発防止：ストレージ構成変更時にやっておくべきこと
バックアップは「必要になってから直す」と間に合わないことが多い領域です。特に Hyper‑V ホストでは、ホスト障害＝複数 VM を一度に失うリスクになります。ストレージ構成を触るときは、次のチェックリストを習慣化すると事故が減ります。
| タイミング | やること | 理由 |
|---|---|---|
| 構成変更の前 | 直近バックアップが成功していること、復元手順が確認できることを確認 | 最悪のときに戻れる状態を担保する |
| ディスクを抜く前 | 対象ディスクが「バックアップ対象」「バックアップ先」「VM 格納先」に絡んでいないか再確認 | 想定外に依存しているケース（マウントポイント等）を潰す |
| 構成変更直後 | diskpart でボリューム一覧を確認し、失敗/不明なディスクが残っていないか確認 | 不整合の痕跡が残ると、WSB が巻き込まれやすい |
| 構成変更直後 | WSB が起動できるか、手動バックアップが 1 回通るか確認 | 問題を“その場で”顕在化させ、後回しにしない |
| 再発する環境 | 構成変更後の標準手順として wbadmin delete catalog → ジョブ再作成を手順書化 | 属人化を減らし、復旧を速くする |
まとめ：このケースで最も可能性が高い原因と、最短で戻す方法
「バックアップ対象ではないスパンボリュームを外しただけ」で Windows Server Backup が落ちるのは、一見すると理不尽ですが、WSB が内部に持つバックアップカタログがディスク構成変更で不整合を起こすと、UI もエンジンもまとめて壊れたように見えることがあります。
そのため、復旧の第一手は次の 1 行です。
wbadmin delete catalogこれで起動とバックアップが戻るなら、あとは現在のディスク構成に合わせてバックアップ定義を作り直し、手動で 1 回成功させてからスケジュール運用に戻すのが、最も安全で早い進め方です。もし改善しない場合も、ログ退避・機能再導入・VSS 状態の確認まで順に行うことで、原因を切り分けながら確実に復旧へ近づけます。
コメント