Windows Server 2022: corrigir erro “Windows Backup failed to get an exclusive lock on the EFI system partition (ESP)” (0x8078011E, eventos 517/518)

Instalações novas do Windows Server 2022 podem apresentar falhas aleatórias no Windows Server Backup (WSB) com o erro “Windows Backup failed to get an exclusive lock on the EFI system partition (ESP)”. Este guia explica por que ocorre e traz um workaround automatizado que resolve na prática.

Índice

Visão geral do problema

Em servidores físicos e máquinas virtuais com Windows Server 2022, administradores têm observado falhas intermitentes no Windows Server Backup quando a seleção inclui Bare Metal Recovery (BMR) e, portanto, a partição EFI System Partition (ESP). O sintoma central é o erro:

Windows Backup failed to get an exclusive lock on the EFI system partition (ESP)
(ex.: código 0x8078011E, eventos 517 ou, às vezes, 518 no log Application — Fonte: Microsoft‑Windows‑Backup).

Sintomas típicos que você pode observar

Backups agendados falham de forma aleatória. Rodando manualmente (“Back up now”), o job quase sempre conclui sem erros.
Se você excluir Bare Metal/ESP da seleção, o backup de volumes costuma funcionar normalmente.
Sem software de terceiros evidente interferindo, e os VSS Writers normalmente aparecem como “Stable”.
Causa raiz não confirmada; indícios apontam para condição de corrida/bloqueio ao tentar travar a ESP no momento exato do agendamento.

O que significam 0x8078011E, Event ID 517/518 e o “lock” da ESP

O Windows Server Backup, via serviço wbengine.exe, orquestra VSS para preparar snapshots consistentes antes de copiar dados. Quando a seleção inclui BMR, o WSB precisa inspecionar e brevemente travar a EFI System Partition para enumerar/backup do conteúdo necessário à recuperação bare metal. Esse “exclusive lock” às vezes falha — tipicamente quando algum processo, serviço ou transição momentânea do próprio sistema já mantém handle, mount ou operação pendente sobre a ESP. O resultado é o erro 0x8078011E e o registro de falha como Event ID 517 (e em certos ambientes 518).

Como o erro é intermitente, um simples retry alguns segundos/minutos depois quase sempre consegue o lock, e o backup termina com sucesso. Isso dá a pista de que o problema gira em torno de timing, não de corrupção ou configuração definitiva.

Solução comprovada: retry automático por evento (517/518)

A correção mais eficaz na prática é automatizar a reexecução do mesmo job do WSB sempre que o evento 517 ou 518 ocorrer. Dessa forma, você mantém a seleção com BMR/ESP e garante que, após poucas tentativas, o backup conclua ainda na mesma janela diária.

Por que esta abordagem funciona

O erro está ligado a uma janela estreita de bloqueio da ESP. Reexecutar diminui o impacto do timing.
Não altera a política de backup (continua com BMR) e preserva a capacidade de Bare Metal Recovery.
É simples de auditar, reversível e compatível com ambientes físicos e virtuais.

Pré‑requisitos

Permissões administrativas locais.
Uma tarefa de backup já configurada no Windows Server Backup (agendada pela interface do WSB).

Passo a passo (GUI) no Agendador de Tarefas

Abra o Agendador de Tarefas (taskschd.msc).
Navegue até Biblioteca do Agendador de Tarefas → Microsoft → Windows → Backup.
Abra as Propriedades de Microsoft‑Windows‑WindowsBackup e aceda ao separador Definições/Settings:
- Marque “Permitir que a tarefa seja executada sob demanda” (Allow task to be run on demand).
- Opcional: a opção “Se esta tarefa falhar” apenas cobre falhas da tarefa do Agendador, não o job interno do WSB; portanto, não resolve sozinha o erro de lock na ESP.
Crie uma nova tarefa que dispare ao ocorrer o erro e reexecute o job do WSB.

Passo a passo (linha de comando)

Execute os comandos abaixo em um CMD (Admin) para criar o retry automático ao Event ID 517. Em ambientes onde o erro também aparece como Event ID 518, crie uma segunda tarefa idêntica ajustando apenas o ID:

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\RetryBackupError517" ^
  /TR "schtasks /run /tn \"Microsoft\Windows\Backup\Microsoft-Windows-WindowsBackup\""

Observações práticas:

Após criar, Atualize a pasta Backup no Agendador e valide se o trigger por evento foi aplicado.
Resultado típico: o primeiro agendamento falha, a tarefa Retry_Backup roda na sequência e o backup conclui. Em cenários piores, o retry pode ocorrer várias vezes no mesmo dia (p.ex., até ~7), mas tende a fechar com êxito.

Evite loops infinitos (recomendado)

Edite a tarefa de retry e, em Definições/Settings:

Ative “Parar a tarefa se durar mais que:” e defina um limite razoável (2–4 horas, conforme janela/volume).
Selecione “Se a tarefa já estiver em execução, não iniciar uma nova instância”.
Opcional: limite o número máximo de repetições via condições/período ativo (por exemplo, valide que a tarefa só esteja habilitada dentro de uma janela de backup).

Como validar rapidamente

No Visualizador de Eventos, filtre Application pela Fonte Microsoft‑Windows‑Backup e Nível: Erro para confirmar os eventos 517/518.
Dispare manualmente a tarefa Microsoft‑Windows‑WindowsBackup uma vez fora de hora para um teste controlado e, se necessário, force um retry executando a tarefa de Retry que você criou.
Verifique se o backup resultante inclui BMR e conclui com sucesso (eventos de informação correspondentes no log).

Alternativa de contingência: excluir Bare Metal/ESP

Se você precisa de um alívio imediato sem mexer no Agendador, é possível excluir Bare Metal Recovery (o que retira a ESP da seleção). Isso evita o bloqueio e o backup de volumes tende a êxito. Entretanto, o trade‑off é perder a capacidade de Bare Metal Recovery enquanto essa configuração estiver ativa. Use apenas como contingência, com ciência do risco operacional.

Mitigações operacionais úteis

Agendar janelas múltiplas (ex.: duas execuções diárias) para aumentar a probabilidade de pelo menos um backup concluir.
Disparo manual em caso de falha do agendado, especialmente em janelas críticas.
Monitorização por evento: criar alertas/ações para os eventos 517/518 e para o evento de sucesso do WSB, garantindo visibilidade proativa.

Runbook: o que fazer quando o agendado falhar

Confirmar o ID do evento (517 ou 518) e a mensagem “failed to get an exclusive lock on the ESP”.
Ver se há concorrência: outro backup ou operação de disco (veja itens de checklist abaixo).
Executar retry automático (pela tarefa que você criou) ou manualmente reexecutar a tarefa Microsoft‑Windows‑WindowsBackup.
Registrar o incidente: data/hora, contagem de retries, duração total e resultado.
Revisar janelas/overlaps e considerar ajustar o horário do backup para um período mais ocioso.

Checklist de diagnóstico e boas práticas

Verificação	Como checar	O que esperar / Ação
Concorrência de backups	Event Viewer (Application) – eventos como 581 podem sugerir job concorrente	Garanta que apenas um backup rode por vez
VSS Writers	`vssadmin list writers`	Todos Stable. Se instáveis, reinicie COM+ Event System, Cryptographic Services, Volume Shadow Copy, nesta ordem
VSS Providers	`vssadmin list providers`	Confirme se há apenas os providers esperados
Bloqueadores na ESP	Process Explorer (Sysinternals) para observar handles na janela do backup	Se identificar processo com handle, reprograme o horário ou ajuste o processo
Saúde do destino de backup	Monitorização de disco, espaço livre, erros de E/S	Resolva gargalos antes do próximo ciclo
Firmware/BIOS/UEFI	Política de atualização de plataforma	Mantenha atualizados; inconsistências de firmware podem ampliar janelas de lock
Conflitos com outras ferramentas	Revise janelas de varredura AV, inventário, gestão de disco	Evite overlap com a janela do WSB
Antivírus/EDR	Testes controlados com exclusão de `C:\Windows\System32\wbengine.exe`	Alguns relatos sugerem alívio, mas não é solução consistente para o lock na ESP
Plano B	Testar software de backup alternativo	Útil para isolar se o problema é específico do WSB

Comandos e trechos prontos

Criar tarefa de retry (Event ID 517)

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\RetryBackupError517" ^
  /TR "schtasks /run /tn \"Microsoft\Windows\Backup\Microsoft-Windows-WindowsBackup\""

Criar tarefa de retry (Event ID 518)

schtasks /create /F /RU SYSTEM /RL HIGHEST ^
  /SC ONEVENT /EC Application ^
  /MO "*[System[Provider[@Name='Microsoft-Windows-Backup'] and (EventID=518)]]" ^
  /TN "Microsoft\Windows\Backup\RetryBackupError518" ^
  /TR "schtasks /run /tn \"Microsoft\Windows\Backup\Microsoft-Windows-WindowsBackup\""

Executar o job do WSB sob demanda

schtasks /run /tn "Microsoft\Windows\Backup\Microsoft-Windows-WindowsBackup"

Listar rapidamente erros 517/518 dos últimos 7 dias (PowerShell)

$start = (Get-Date).AddDays(-7)
Get-WinEvent -FilterHashtable @{
  LogName='Application';
  ProviderName='Microsoft-Windows-Backup';
  Id=517,518; StartTime=$start
} | Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Evitar instância duplicada da tarefa de retry (dica)

Na tarefa de retry, defina em Settings a opção “Se a tarefa já estiver em execução, não iniciar uma nova instância”. Assim, caso vários eventos 517/518 disparem em sequência, você não acumula múltiplas reexecuções desnecessárias.

Boas práticas de agendamento e janelas

Escolha janelas ociosas (baixa atividade de E/S) para reduzir a chance de lock na ESP.
Evite overlap com:
- Verificações completas do antivírus/EDR;
- Tarefas de inventário de hardware/BIOS/UEFI;
- Jobs de manutenção de volumes e tarefas de terceiros (defrag, migração, snapshot externo).
Considere duas execuções diárias: uma principal e uma secundária de contingência.

FAQ – Perguntas frequentes

Isso acontece apenas no Windows Server 2022?
É onde os relatos são mais frequentes neste contexto. Ainda assim, o método de retry por evento é genérico e pode ser adotado se sua telemetria mostrar o mesmo padrão.

É problema do VSS?
Os VSS Writers costumam aparecer como Stable. O padrão observado aponta mais para timing/bloqueio transitório da ESP do que para falha estrutural do VSS.

Excluir BMR resolve definitivamente?
Remove a ESP da seleção e, por consequência, o lock que falha. Porém, você perde a capacidade de Bare Metal Recovery. Use como contingência, não como solução definitiva.

Retry automático é seguro?
Sim, desde que você imponha salvaguardas (tempo máximo da tarefa, sem instâncias concorrentes) e monitore o resultado final do backup.

Devo criar exclusões no antivírus?
A exclusão de wbengine.exe foi sugerida em alguns ambientes, mas não resolve de forma consistente este caso específico. Use apenas após avaliar risco e com evidência de interferência.

Funciona em VMs e servidores físicos?
Sim. O padrão de erro e a eficácia do retry foram vistos em ambos.

Exemplo de política operacional

RPO/RTO: defina a janela máxima aceitável sem backup concluído. O retry por evento reduz MTTR do job ao automatizar a reação.
Auditoria: registre (data/hora, contagem de retries, duração total, resultado) para alimentar melhoria contínua.
Notificação: acione alerta em 517/518 e confirmação em evento de sucesso, mantendo o time informado.

Resumo tático e lições aprendidas

Problema: falha aleatória no lock exclusivo da ESP no WSB do Windows Server 2022 (0x8078011E, eventos 517/518).
Hipótese: condição de corrida/bloqueio transitório ao travar a partição EFI.
O que funciona hoje: retry automático por evento (517/518) via Agendador de Tarefas, reexecutando o job do WSB até concluir no mesmo dia.
Plano B: excluir Bare Metal/ESP (perde BMR) para garantir volumes enquanto ajusta a estratégia.
Estado: encaminhado à Microsoft; acompanhe atualizações futuras do Windows Server 2022 para correção oficial assim que disponível.

Apêndice – Passo a passo condensado

No Agendador: habilite “Permitir que a tarefa seja executada sob demanda” em Microsoft‑Windows‑WindowsBackup.
Crie tarefa(s) de retry por evento 517 e, se aplicável, 518 com schtasks conforme acima.
Imponha salvaguardas: tempo máximo, sem nova instância se já estiver em execução.
Monitore: eventos 517/518 (falha) e eventos de sucesso do WSB para fechar o ciclo.
Opcional: agende uma segunda janela diária como contingência.

Conclusão prática

Embora a causa raiz não esteja oficialmente confirmada, o comportamento observado indica um bloqueio intermitente da ESP durante o backup agendado. Na prática, o retry automático por evento 517/518 via Agendador de Tarefas resolve de forma consistente: em poucas tentativas, o backup com BMR/ESP conclui diariamente. Caso precise de continuidade imediata, retirar BMR/ESP da seleção elimina o lock, com o custo de abrir mão do Bare Metal Recovery. Mantenha a higiene de plataforma (UEFI/firmware, discos, janelas sem concorrência) e monitore os eventos para garantir previsibilidade operacional até que uma atualização do Windows Server 2022 trate o problema de forma definitiva.