企業の基幹システムを支えるWindows Server 2022ですが、バックアップを自動化して運用負荷を軽減しようとした際に、思わぬエラーが発生して困っている方が多いようです。なかでも「EFIシステムパーティションの排他ロックを取得できない」エラーは原因がはっきりせず、対処に苦慮するケースが少なくありません。そんな方のお役に立てるよう、本記事では具体的な解決策と運用ノウハウをまとめていきます。
Windows Server 2022で発生するEFIパーティションバックアップエラーの概要
Windows Server 2022でWindows Server Backup機能を利用する際、「EFIシステムパーティションの排他ロックを取得できない」旨のエラーが突発的に起こることがあります。このエラーは以下のような特徴をもち、原因を究明するのが非常に難しいとされています。
典型的なエラー メッセージとイベントID
- 「Windows Backup failed to get an exclusive lock on the EFI system partition (ESP)…」
- エラー コード: 0x8078011E
- EventID: 517 や 518 など
物理サーバー・仮想環境を問わずランダムに発生することが多く、再現性も一定していない点が非常に厄介です。特にHPやDellのエントリーレベルサーバ、Essentialsエディションなどでよく報告されています。
注意すべき症状
- 新規インストール後、ほとんどソフトを導入していない状態でも発生
- ウイルス対策ソフトを無効化・削除しても改善しない
- BIOS/UEFIの更新やベーシックなディスクエラー修復操作（chkdsk /f /r）を行っても変化なし
- スケジュール実行時に頻発するが、手動バックアップだと成功率が高い
- ベアメタル回復を外すとエラーは起きにくいが、ベアメタル復旧ができない
こうした事象からもわかるように、ウイルス対策ソフトやドライバなどの特定要因に絞り込むのが難しく、根本原因を突き止めづらいのが現状です。
エラー発生の背景と考えられる要因
Windows Server Backupでは、EFIシステムパーティション(ESP)のバックアップを行う際に排他ロックを取得するプロセスがあります。この時点で何かしら別のサービスやプロセスがEFIパーティションにアクセスしていると、競合が生じてロック取得に失敗するのが直接的な原因です。
VSS(Volume Shadow Copy Service)の影響
WindowsではVSS(Volume Shadow Copy Service)を通じてスナップショットを作成し、バックアップを実施します。VSSが正常に動作しない状況（VSS Writerのエラーなど）があると、EFIパーティションにも悪影響を及ぼす可能性があります。ただし、vssadminコマンドなどで異常が見つからないケースも多く、「VSSだけが原因」とは言い切れません。
UEFIとの相性やファームウェア周り
EFIパーティションはUEFI環境でOS起動に不可欠な領域です。BIOS/UEFIのバージョンによっては、EFIパーティションの扱いに特殊な制限や不具合が存在するケースもあります。しかし、実際にファームウェア更新だけで改善する環境は一部で、根本的な問題解消に至らない例が多数報告されています。
ウイルス対策ソフトや常駐プロセスの干渉
実行中のウイルス対策ソフト（Microsoft Defenderを含む）などがEFIパーティションを参照・ロックしている可能性は考えられます。ですが、対策ソフトを無効化しても変化しないケースがあるため、「原因の一端になっている可能性はあるが、単独ではない」と推察されています。
実際に試されたさまざまな対処法
多くの管理者がこの問題を解決すべく、いろいろな方法を試しています。以下は主な対処策と、その効果が報告されている例です。
1. ウイルス対策ソフトの除外設定・停止
- 除外設定: wbengine.exe や Windows Server Backup関連のプロセスをスキャン対象外にする
- 常駐監視の停止やアンインストール
しかし、前述のとおり、これで確実に改善したという報告は限定的です。原因が一部環境依存である可能性もあります。
2. BIOS/UEFIファームウェアの更新
マザーボードやサーバベンダーが提供する最新のファームウェアにアップデートすると、稀にロックエラーの発生頻度が下がったという声もあります。ただし、これも確実性は低く、本質的な回避策とは言いがたいのが実情です。
3. VSS Writerの状態確認
コマンド プロンプト（管理者権限）で以下を実行し、VSS Writerに問題がないかを確認します。
vssadmin list writers
「Waiting for completion」や「Failed」になっているWriterがあれば、そのサービスや関連ソフトを修復または再起動することで改善を図る手法があります。とはいえ、Writerに異常がない状態でもエラーが発生するケースが多いため、抜本的な解決には繋がりにくいかもしれません。
4. chkdsk /f /r でディスク修復
EFIパーティションを含む全ボリュームに対してchkdskを実施することにより、ファイルシステムやクラスタ不良が修復される可能性があります。
chkdsk C: /f /r
（Cドライブ以外にも論理ボリュームがあれば都度実行）
ただし、これも万能ではなく、報告事例では「修復できてもエラーは再発する」ケースがほとんどでした。
一時的な回避策：EFIパーティションをバックアップ対象から除外
最も簡単にエラーを回避する方法として、バックアップ設定からベアメタル回復を除外する手段があります。Windows Server Backupのウィザードで「ベアメタル回復」にチェックを入れないことでEFIパーティションを対象外にできます。
メリットとデメリット
| メリット | デメリット |
|---|---|
| バックアップ時のエラーを回避しやすい | ベアメタル復旧ができなくなる |
| スケジュール実行で失敗率が下がる | OSクラッシュなどの非常時に迅速な復旧が困難 |
このように、システム全体のバックアップを取らずに「データボリュームのみ」や「必要最低限のドライブだけ」をバックアップして運用する形となります。小規模環境やベアメタル復旧が不要な場面であれば有効ですが、大多数の企業システムではベアメタル回復は重要ですから、割り切りが必要です。
最も有効だった対処策：失敗時の自動リトライタスクを設定
現場の報告で「最終的にほぼ確実にバックアップを成功させられる」方法として挙げられるのが、Windows Server Backupに失敗したときに自動再実行を行う仕組みをタスクスケジューラで組むやり方です。根本的にエラーを消し去るわけではありませんが、バックアップが最終的に成功すれば運用上は問題ないという考え方です。
設定手順
- タスクスケジューラを開く
「タスク スケジューラ (taskschd.msc)」を起動し、左ペインの「Microsoft\Windows\Backup」フォルダにある「Microsoft-Windows-WindowsBackup」を探します。 - タスクのプロパティを開く
[プロパティ] → [設定]タブで「必要に応じてタスクを実行できるようにする(Allow task to be run on demand)」にチェックを入れ、[OK]で設定を保存します。 - EventIDをトリガーにしたタスクを追加する
管理者権限のコマンドプロンプトで以下のコマンドを実行します。EventIDは環境によって517や518などを確認して置き換えます。
schtasks /create /F /RU SYSTEM /RL HIGHEST /SC ONEVENT /EC Application ^ /MO "*[System[Provider[@Name='Microsoft-Windows-Backup'] and (EventID=517)]]" ^ /TN "Microsoft\Windows\Backup\Retry_Backup" ^ /TR "schtasks /run /tn \"Microsoft\Windows\Backup\Microsoft-Windows-WindowsBackup\""
これにより、バックアップが失敗(＝EventID 517等がイベントログに記録)すると自動的に「Microsoft-Windows-WindowsBackup」タスクを再実行します。
実運用での効果
- 初回のバックアップが失敗しても短時間後に再実行されるため、最終的に成功する確率が飛躍的に上がる
- 失敗が頻発する環境でも、数回リトライすれば成功するというケースがほとんど
- バックアップが成功すればログの確認だけで済むので、管理者の手動介入が大幅に削減される
ただし、根本的にエラーが完全に消えるわけではないため、あくまで「ワークアラウンド(暫定対処)」という位置づけです。環境によってはリトライが続いてしまい、ログが大量に生成される恐れもあります。
Microsoftサポートへの問い合わせと今後の見通し
実際にMicrosoftサポートへ問い合わせた事例によると、開発チーム側でも問題は認識しているものの、現時点での恒久的な修正パッチは公開されていないようです。サポート担当者からも「自動リトライタスクの導入」という暫定策が提示されるのが現状で、今後リリースされるアップデートやサービスパックで修正が入ることを期待するしかありません。
まとめ：ベアメタル復旧が必要なら自動リトライ、不要ならEFI除外
バックアップは企業のBCP(事業継続計画)において重要な役割を担うため、確実に実行されるよう対策を講じる必要があります。Windows Server 2022で「EFIシステムパーティションの排他ロックを取得できない」エラーに直面した際は、以下の方針を検討してみてください。
- ベアメタル復旧が必須 → 失敗時に再実行するタスクを設定する
- ベアメタル復旧が不要 → EFIパーティションを除外して安定運用を図る
これらを踏まえながら、引き続きMicrosoftのアップデート情報を注視し、パッチがリリースされた際には適用の検討をすすめてみてください。最先端の技術であっても意外なところにバグが潜むことも多く、安定稼働にはこうしたワークアラウンドが欠かせないのが現状です。
コメント