ディスク一式を新しいシステムへ移行した直後から、Windows Server Backup（wbadmin.msc）を開くと「The server threw an exception」で落ち、スケジュールバックアップまで止まって困るケースがあります。本記事では、移行で起きやすい原因と、最短で復旧させる現実的な手順（バックアップカタログの再作成）を、注意点込みで整理します。
起きている症状（典型パターン）
ディスク移行（物理サーバー入替、VM移行、ストレージ交換、クローンなど）の後、Windows Server Backup（GUI：wbadmin.msc）周りで次のような症状がまとまって発生することがあります。
- wbadmin.msc を開いた瞬間に「Windows Server Backup スナップイン操作中に致命的エラー。The server threw an exception（サーバーが例外をスローしました）」が出る
- Scheduled backup（スケジュールバックアップ）が動かなくなる／実行されない
- イベントログに wbengine.exe が 0xc0000005（アクセス違反）で落ちた形跡が残る
この組み合わせは、GUIだけの軽微な表示崩れではなく、バックアップエンジン側（wbengine）が例外で落ちてスケジュール処理も止まっている可能性が高い状態です。
まず押さえるべき前提：バックアップ「データ」と「バックアップカタログ」は別物
Windows Server Backup には、ざっくり言うと次の2種類の情報が存在します。
| 区分 | 役割 | よくある実体（例） | 壊れる／不整合になると |
|---|---|---|---|
| バックアップデータ | 実際の復元に必要な中身 | バックアップ先の WindowsImageBackup など | 当然、復元ができない |
| バックアップカタログ（管理情報） | GUIやエンジンが参照する「世代」「保存先」「履歴」などの整合管理 | OS側が保持する管理情報（バックアップ先の情報と紐づく） | GUIが落ちる／スケジュールが失敗する／過去世代が見えない |
今回の「The server threw an exception」や 0xc0000005 は、移行前の環境情報を握ったままのカタログが、移行後のディスク構成や識別子と噛み合わず、wbadmin.msc や wbengine が例外で落ちる（または内部的に破綻する）方向で説明できることが多いです。
なぜディスク移行後に起きやすいのか（原因の方向性）
ディスク移行後に、バックアップ先が同じUSB HDDに見えていても、OS視点では「別物」になっていることがあります。たとえば次のような変化は、バックアップカタログの整合に影響します。
- ディスク署名／識別子（内部ID）の変化（クローンやコントローラ変更など）
- ドライブレターの変化（E: が F: になった、など）
- ボリュームGUIDやマウントポイントの変化
- バックアップ先の接続形態の変化（USB接続の経路、ドライバ、認識順）
- 移行時にバックアップ構成だけが「半端に」引き継がれた（GUIは設定が残っているのに参照が壊れている、など）
結果として、カタログが参照している「バックアップの保存先」や「世代情報」が実体と一致せず、GUIやエンジンが処理中に落ちる、という形になりやすいのがこの問題の厄介なところです。
結論：バックアップカタログを削除して再作成すると復旧することがある
移行前の環境情報が混ざったカタログ不整合が疑わしい場合、実務的に最も効くことが多いのが バックアップカタログの削除 → 作り直しです。スレッド等でも「受理済みの解決策」として扱われやすい手順がこれです。
実行するコマンドは次の1行です。
wbadmin delete catalogただし、カタログ削除は「管理履歴を捨てる」側面があり、過去バックアップの見え方が変わる可能性があります。安全策を取ってから実行してください。
実行前の安全策（やっておくと事故が減る）
本番サーバーでの作業は、バックアップを直すための操作が「バックアップを壊す」ことにならないよう、先に確認を挟むのが重要です。
| チェック項目 | 確認方法（例） | 狙い |
|---|---|---|
| バックアップ先にデータが残っているか | エクスプローラーで WindowsImageBackup フォルダー等を確認 | 「実体は残っている」ことの確認（復旧余地の判断） |
| 世代が列挙できるか | wbadmin get versions -backuptarget:<バックアップ先> | 復元に使える世代が存在するかの確認 |
| バックアップ先のドライブレター・オンライン状態 | ディスクの管理で確認（オフライン／未割当になっていないか） | 移行後の認識不良や接続順の問題を先に潰す |
| 作業時間帯とバックアップ競合 | スケジュールバックアップの時間を避ける／停止する | 実行中にカタログを触って二次障害を起こさない |
| 最悪に備えた退避 | 可能ならバックアップ先HDDを別環境に接続して内容をコピー保全 | 「何があっても戻せる」状態を作る |
少なくとも バックアップ先の中身（WindowsImageBackup等）の存在確認 と、get versions で世代が見えるか は先に見ておくと、判断が一気に楽になります。
基本手順：wbadmin delete catalog でカタログを削除する
以下は「最短で復旧を狙う」ための基本手順です。GUIが開けないケースでも実行できます。
- 管理者権限でコマンドプロンプト（または PowerShell）を開きます。
- スタートメニュー → 「Windows PowerShell（管理者）」または「コマンドプロンプト（管理者）」
- 次のコマンドで、バックアップカタログを削除します。
wbadmin delete catalog確認メッセージが表示された場合は、内容を読んだうえで進めます（環境によって表示が異なります）。 - wbadmin.msc をいったん閉じ、開き直します。
- 改善しない場合は、サーバー再起動も検討します（移行後のサービス状態が不安定な場合に効くことがあります）。
- バックアップ設定（スケジュール）を再設定し、まずは 新しいバックアップを1回作成 します。
- いきなりスケジュールだけ戻すより、手動実行で1回成功させて「現環境の基準点」を作るほうが再発が減ります。
この手順で、GUIが正常に開き、スケジュールバックアップが再開する例が多く報告されています。
カタログ削除で何が起きる？（誤解されやすいポイント）
「delete catalog」という名前の強さから、バックアップデータそのものが消えるイメージを持たれがちですが、ここで消しているのは主に 管理情報（カタログ） です。
- バックアップデータ自体が即座に削除されるとは限りません（ただし環境・構成によって挙動は変わり得ます）。
- 一方で、カタログが無い状態では GUI から過去バックアップが参照できなくなることがあります。
- 「過去世代をGUIで見える化したい」「移行前のバックアップから復元したい」場合は、次の補足手順が重要です。
既存バックアップを“見える化”したい場合：カタログの再構築
バックアップ先（USB HDD など）が健全で、移行前のバックアップデータが残っているなら、カタログを再構築できるケースがあります。
バックアップ先を指定してカタログを再構築する
wbadmin restore catalog -backuptarget:<バックアップ先>ここでの「バックアップ先」は、ドライブレター（例：E:）やボリュームの指定など、環境に合わせて入力します。USB HDD の認識が不安定な場合は、まずディスクの管理でオンライン状態・ドライブレターを安定させてから実行してください。
世代が見えるか確認する（復旧判断の基準）
wbadmin get versions -backuptarget:<バックアップ先>世代一覧が取得できれば、少なくとも「復元に使える可能性があるバックアップが存在する」方向です。逆に、ここで何も出ない／エラーになる場合は、バックアップ先のパス指定や認識状態、フォルダー構成が期待とズレている可能性があります。
復元を行う場合のイメージ（例）
実際の復元は、対象（ファイル、ボリューム、システム状態など）によってコマンドが変わりますが、基本的には「世代（Version identifier）を指定して復元」を行います。例として、ファイル/フォルダー復元の入口になるコマンドは次のような形です。
wbadmin start recovery -version:<VersionIdentifier> -itemtype:File -items:<復元したいパス> -recoveryTarget:<復元先>本番復元は影響が大きいので、まずはテスト用のファイルを別フォルダーへ復元するなど「小さく検証」してから進めるのが安全です。
スケジュールバックアップが止まる場合の復旧ポイント
カタログ不整合を解消してGUIが復旧しても、スケジュールがそのまま復活しない場合があります。移行後のスケジュール復旧では、次の観点が効きます。
一度「設定を作り直す」ほうが早いことが多い
ディスク移行の前後で識別子が変わっていると、古いスケジュール設定が「存在しないバックアップ先」を見に行って失敗することがあります。GUI（Windows Server Backup）から、バックアップ先の選択を含めて再設定し、手動バックアップ1回成功→スケジュール有効化、という流れが堅いです。
タスクスケジューラ側も念のため見る
Scheduled backup は内部的にタスクとして管理されます。移行後は、タスク自体は残っているが条件や参照先が破綻している、ということがあり得ます。
- タスク スケジューラで「バックアップ関連のタスク」が失敗していないか
- 失敗履歴のエラー内容（アクセス拒否、パス不正、デバイス不在など）
- バックアップ先USB HDDがスケジュール時刻に確実に接続されているか（省電力設定で切れていないか）
コマンドで状況確認する（例）
GUIが開けない／不安定なときでも、コマンドで状況が取れることがあります。
wbadmin get statusここで「進行中」「失敗」「次回実行」などのヒントが取れる場合があります（出力は環境・状態で変わります）。
よく使うコマンドまとめ（コピペ用）
本件の切り分けと復旧で登場頻度が高いコマンドを、用途別にまとめます。
| 目的 | コマンド | ポイント |
|---|---|---|
| カタログ削除（復旧の本命） | wbadmin delete catalog | 移行後不整合のリセットに効く |
| バックアップ世代の一覧 | wbadmin get versions -backuptarget:<バックアップ先> | 既存バックアップの有無・復元可能性の判断 |
| カタログ再構築 | wbadmin restore catalog -backuptarget:<バックアップ先> | 過去世代を参照したい場合に試す |
| 現在の状態確認 | wbadmin get status | 失敗の兆候や実行中の確認に使う |
それでも直らない場合の追加チェック（再発・別原因の可能性）
カタログ削除・再作成をしても改善しない場合、原因が「カタログ不整合以外」に寄っている可能性があります。次の順で確認すると、遠回りを減らせます。
サービス（VSS含む）が止まっていないか
Windows Server Backup は、ボリュームシャドウコピー（VSS）と連動します。移行後にサービスの起動種類や依存関係が崩れていると、バックアップが不安定になります。
- Volume Shadow Copy（VSS）
- Microsoft Software Shadow Copy Provider
- Block Level Backup Engine Service（wbengine）
停止している、または開始できない場合は、まずそちらの解決が優先です。
バックアップ先USB HDDの「認識が不安定」問題を疑う
特にUSB接続HDDは、移行後に以下が変わるだけで挙動がブレます。
- USBポート（前面/背面、USB2/USB3、ハブ経由）
- 省電力設定（スリープ・電源断でバックアップ時に不在になる）
- ドライブレターの自動割り当て（別のディスクが先に刺さると変わる）
運用としては「バックアップ専用の接続口を固定」「電源設定でUSBの省電力を抑制」「ドライブレターを固定」の3点が効きやすいです。
イベントログで“落ち方”を確認する
0xc0000005 はアクセス違反なので、何らかの不整合や例外が原因でプロセスが落ちています。イベントビューアーで次のログを中心に確認します。
- アプリケーション ログ（wbengine.exe のアプリケーションエラー）
- バックアップ関連のログ（Microsoft-Windows-Backup の運用ログ等）
- システム ログ（ディスク切断、I/Oエラー、USB再接続、VSSエラー）
「バックアップ先デバイスが見つからない」「I/Oエラー」「アクセス拒否」などが見えているなら、カタログというより保存先や権限・デバイス側の問題に寄ります。
システムファイル破損・WMI不整合を疑う（最後の手段）
サーバー移行の過程で、コンポーネントが中途半端に引き継がれた場合、wbadminのGUI（MMCスナップイン）が WMI 連携で落ちるケースもあり得ます。ここは影響範囲が大きくなりやすいので、安易に「リポジトリリセット」等へ突っ込まず、まずは以下から検討してください。
- Windows Server Backup 機能の再インストール（役割/機能の追加削除で入れ直す）
- システム整合性チェック（SFC/DISM など、OS世代に合わせた手順）
ただし、これらは環境ごとの注意点が多いため、バックアップの重要度が高いサーバーでは「影響の少ない検証環境で先に試す」「メンテナンスウィンドウで実施する」などの配慮が必要です。
再発防止：ディスク移行時にやると効く運用のコツ
Windows Server Backup（wbadmin）は手軽ですが、ハードウェア・ストレージの入替に対して“強い設計”とは言いづらい部分があります。移行を前提にするなら、次の運用で事故が減ります。
| ポイント | 理由 | 現場でのやり方（例） |
|---|---|---|
| バックアップ先を「専用化」する | 別用途のファイル混在でトラブルが増える | バックアップ専用USB HDD／専用LUNに統一 |
| ドライブレターと接続口を固定する | 移行後に参照先がズレやすい | 常に同じUSBポート、ドライブレター固定 |
| 移行直後に「手動バックアップ1回成功」を作る | 現環境基準の整合を作ってからスケジュールに載せる | 移行日当日にテストバックアップ→ログ確認 |
| 復元テスト（小さく）を実施する | バックアップは取れていても戻せないことがある | テストファイルを別フォルダーへ復元して確認 |
| バックアップ以外の“第二経路”を持つ | WSB単体に依存すると移行で詰みやすい | スナップショット、別製品、クラウド保管など |
Windows Server Backupの限界と、別方式を検討すべきサイン
今回のように「カタログを消して復旧」は、確かに短期的な解決になります。ただし、運用の観点では次のサインが出たら別方式（別製品/別設計）を検討したほうが安全です。
- ディスク移行のたびにバックアップ設定が壊れ、復旧に手作業が必要
- GUIが落ちる／スケジュールが止まるなど、運用で許容しづらい不安定さがある
- 世代管理や監査（いつ誰が何をバックアップしたか）の要件が厳しい
- オフサイト保管や世代保持ポリシー、暗号化、通知が必須
Windows Server Backup は「最低限のバックアップを素早く用意する」には便利ですが、移行や拡張を繰り返す環境では、バックアップ基盤としての堅牢性が課題になりやすい点を押さえておくと判断がしやすくなります。
よくある質問（現場で詰まりやすいところ）
カタログ削除でバックアップデータは消えますか？
一般には「管理情報（カタログ）」を消す操作であり、バックアップ先のデータが即消える操作とは限りません。ただし、環境によっては「GUIから過去世代が見えない」「参照できない」状態になることがあります。実行前にバックアップ先の内容確認（WindowsImageBackup等）と、可能なら別媒体への退避を行うのが安全です。
既存バックアップを残したまま復旧したいです
まず wbadmin get versions -backuptarget:<バックアップ先> で世代の存在を確認し、必要に応じて wbadmin restore catalog -backuptarget:<バックアップ先> を試します。そのうえで、移行後は新規バックアップを1回成功させ、スケジュールを作り直すのが堅い流れです。
なぜ「The server threw an exception」でGUIまで落ちるのですか？
GUI（wbadmin.msc）はMMCスナップインとしてバックアップ情報を読み込みます。その読み込み元（カタログ）が移行前の情報を保持したまま不整合になると、内部処理で例外が発生し、結果として「The server threw an exception」になりやすい、という整理ができます。0xc0000005 が絡む場合は、例外処理できずにプロセスが落ちている（アクセス違反）可能性があります。
再発したらどうすべき？
同じ手順で復旧できることはありますが、繰り返す場合は「WSBをバックアップ基盤として使うこと自体が限界に近い」サインになり得ます。バックアップ先の専用化、接続の固定、復元テストの定期実施に加え、別方式の併用（第二経路）を検討すると運用リスクが下がります。
最短で復旧させたいときの実務フローは？
現場での最短ルートは次の流れが安定です。
- バックアップ先に WindowsImageBackup 等が残っているか確認
wbadmin get versions -backuptarget:<バックアップ先>で世代確認wbadmin delete catalogでカタログを削除- 必要なら
wbadmin restore catalog -backuptarget:<バックアップ先>を試す - バックアップ設定を作り直し、手動で1回成功させてからスケジュールへ
「まず直す」だけでなく、「復元できる状態を守る」ことがバックアップ運用では最重要です。移行後に一度つまずいた環境ほど、復元テストまで含めた再設計が効きます。
コメント