Error «Failed to get an exclusive lock on the EFI system partition (ESP)» en Windows Server 2022: solución definitiva con reintento automático

Las copias programadas de Windows Server Backup (WSB) en Windows Server 2022 pueden fallar de forma aleatoria con el código 0x8078011E y los eventos 517/518: «Failed to get an exclusive lock on the EFI system partition (ESP)». A continuación se describen las causas, las pruebas habituales que no lo resuelven y el único procedimiento que garantiza respaldos estables sin perder la recuperación “Bare Metal”.

Índice

Comprender el error

La partición EFI (ESP) contiene los cargadores de arranque y los datos de arranque seguros del servidor. Durante un backup completo, WSB monta la ESP en modo solo lectura y solicita un bloqueo exclusivo (exclusive lock) para que ningún otro proceso escriba en ella mientras se toma la instantánea de VSS. Si otro servicio, controlador o aplicación toca ese volumen en el instante crítico, WSB recibe el error 0x8078011E y anota el evento 517 (o 518 si el fallo llega al commit de la imagen).

Por qué ocurre solo en trabajos programados

  • Solapamiento de tareas de mantenimiento nocturnas: defensas antimalware, optimización de unidades, inventarios de hardware, etc.
  • Arranque rápido de firmware UEFI en servidores modernos que deja la ESP montada al sistema operativo más tiempo del previsto.
  • Drivers de monitorización (iLO, iDRAC, RAID) que realizan lecturas periódicas de la ESP.
  • Diferencias de prioridad: la tarea interactiva (backup manual) se ejecuta a una prioridad más alta que la tarea del programador.

Diagnóstico y comprobaciones preliminares

Antes de adoptar la solución definitiva, conviene descartar problemas de base. Todas las pruebas siguientes son inocuas, pero ninguna soluciona el error de forma consistente:

EstrategiaResultado
Actualizar BIOS/UEFI, firmware RAID, controladores de almacenamiento.No elimina la intermitencia.
Ejecutar chkdsk /f /r en todos los volúmenes.Descarta corrupción de disco pero el fallo reaparece.
Revisar escritores VSS con vssadmin list writers, reiniciar servicios COM+, Cryptographic Services y VSS.Los escritores suelen mostrarse estables; no hay impacto duradero.
Desactivar el antivirus o excluir wbengine.exe y la ESP.Éxito aleatorio; el error vuelve tras unas semanas.
Excluir la partición EFI (“Bare Metal”) del conjunto de copia.El backup termina siempre, pero la restauración completa del sistema deja de ser posible.
Lanzar el respaldo manualmente desde la consola WSB.Funciona el 99 % de las veces, pero no es viable en operaciones 24×7.

La única solución estable: reintento automático

Microsoft reconoce el problema y recomienda un workaround que reinicia la tarea cuando detecta el evento 517 (o 518). En la práctica, el primer intento puede fallar, pero el segundo o tercer intento bloquea la ESP con éxito porque ya no coinciden otros procesos.

Paso a paso

  1. Abrir el Task Scheduler (taskschd.msc) y navegar a Task Scheduler Library → Microsoft → Windows → Backup.
  2. Doble clic en Microsoft‑Windows‑WindowsBackup → pestaña Settings y activar Allow task to be run on demand.
  3. (Opcional) En la misma pestaña marcar If the task fails, restart every X minutos.
  4. Crear una tarea que se dispare por evento. Como administrador, ejecutar:
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\""

Para cubrir también el ID 518 basta con duplicar el disparador o añadir una segunda tarea idéntica que vigile ese ID.

Ajustes recomendados

  • Límite de reintentos: en la pestaña Settings de la nueva tarea, activa Stop the task if it runs longer than y marca un máximo de 7 intentos para evitar bucles.
  • Ventana de mantenimiento: programa el job principal fuera de otras cargas intensas (por ejemplo, antivirus o patching mensual).
  • Monitoreo: suscribe el visor de eventos o tu monitor NOC a la palabra clave Microsoft‑Windows‑Backup / Error.

Qué ocurre tras aplicar el workaround

Un flujo típico es:

  1. WSB lanza la copia a las 23:00.
  2. Un servicio de inventario toca la ESP y provoca el evento 517.
  3. La tarea Retry_Backup detecta el evento en segundos y arranca WSB de nuevo.
  4. En el segundo intento la ESP ya está libre; el backup termina a las 23:07 sin errores.

Los administradores que llevan meses con este esquema reportan éxito diario sostenido incluso en entornos con varios servidores (HP ML30 Gen10 Plus, Dell T150, Lenovo/Vmware, etc.).

Buenas prácticas para entornos críticos

  • Mantén Windows Server 2022 actualizado: a partir del parche acumulativo de febrero 2025 se redujo la frecuencia del fallo en algunos modelos de Dell e HPE.
  • No excluyas la ESP si requieres restauraciones “Bare Metal”. El reintento automático es la única forma segura de incluirla.
  • Supervisa la tendencia de eventos: si observas más de tres eventos 517 consecutivos, revisa drivers y aplicaciones de terceros que usen la ESP (seguridad UEFI, agentes RAID).
  • Evalúa software de terceros (Veeam, Unitrends, Altaro) si tu SLA no tolera los minutos adicionales que añade el reintento.
  • Prueba la restauración regularmente: arranca desde un medio WinRE, selecciona “System Image Recovery” y confirma que la copia detecta la partición ESP.

Preguntas frecuentes (FAQ)

¿Afecta a volúmenes ReFS o solo NTFS?

El error está ligado a la ESP, que siempre es FAT32; el sistema de archivos del resto de volúmenes es irrelevante. ReFS es compatible.

¿Puedo deshabilitar Secure Boot para evitar el bloqueo?

No. El bloqueo es a nivel de sistema de archivos, no de firma UEFI. Deshabilitar Secure Boot reduce la seguridad y no soluciona el problema.

¿Sirve si programo el backup con PowerShell en lugar de la GUI?

Programar por PowerShell o por la consola WSB genera la misma tarea del programador; por tanto, hereda el mismo riesgo y se beneficia del mismo workaround.

¿Cuánto tarda un reintento?

Normalmente entre 10 y 60 segundos, porque WSB reutiliza la enumeración de volúmenes de la primera pasada.

Conclusión

El mensaje «Failed to get an exclusive lock on the EFI system partition» en Windows Server 2022 combina tres factores: la forma en que WSB bloquea la ESP, la actividad de procesos en segundo plano y la prioridad del task scheduler. Las revisiones de firmware, los chequeos de disco y la exclusión de antivirus pueden atenuar la frecuencia pero no son una solución permanente. La estrategia de reintento automático recomendada por Microsoft es, a día de hoy, el único método que garantiza copias diarias exitosas sin sacrificar la partición EFI ni la capacidad de recuperación “Bare Metal”.

Índice