Windows Server 2022: errore backup 0x8078011E / Event ID 517 sulla partizione EFI (ESP) – cause, diagnosi e work‑around con Task Scheduler

Su Windows Server 2022 (stand‑alone ed Essentials in workgroup) molti amministratori incontrano errori di backup pianificato con Event ID 517/518 e codice 0x8078011E: il backup non riesce a ottenere il lock esclusivo sulla partizione EFI (ESP). Ecco diagnosi, cause probabili e un work‑around affidabile.

Indice

Perché questo articolo

Se gestisci Windows Server Backup (WSB) su Windows Server 2022 e vedi fallire i job notturni mentre i backup manuali vanno quasi sempre a buon fine, con messaggi su ESP “in uso”, stai probabilmente affrontando lo stesso bug. In questa guida trovi:

spiegazione del sintomo e del contesto in cui si manifesta;
azioni già provate che non lo risolvono;
tre strategie di mitigazione, fra cui un work‑around con Task Scheduler che rende i backup pianificati affidabili senza rinunciare alla Bare Metal Recovery;
istruzioni operative passo‑passo, script pronti all’uso e raccomandazioni per evitare loop o falsi positivi;
checklist di troubleshooting e consigli di hardening.

Il problema in sintesi

Scenario: Windows Server 2022, edizioni stand‑alone/Essentials in workgroup, su hardware HP/Dell/Lenovo e su VM VMware (quindi non specifico di OEM o hypervisor).
Sintomo: i backup pianificati falliscono in modo intermittente con:

Codice 0x8078011E (talvolta affiancato da altri codici secondari);
Event ID 517 (a volte 518) con origine Microsoft‑Windows‑Backup;
Messaggio: “Windows Backup failed to get an exclusive lock on the EFI system partition (ESP)”.

Comportamento curioso: l’avvio manuale del backup (da GUI WSB o wbadmin) riesce oltre il 99% dei casi; il fallimento si concentra sui job avviati dal Planner.

Diagnosi rapida: come riconoscerlo

Apri Event Viewer e verifica sia il registro Application sia Applications and Services Logs → Microsoft → Windows → Backup.
Cerca eventi con Source Microsoft‑Windows‑Backup e Event ID 517/518. I dettagli includono il riferimento alla EFI System Partition.
Confronta i risultati tra job pianificato e manuale: tipicamente il manuale completa regolarmente.

Azioni tentate che non risolvono

Numerosi amministratori hanno già escluso le cause “ovvie”. Ecco una tabella di sintesi (riproducibile nella tua change‑log):

Azione provata	Esito
Aggiornamento BIOS/firmware, driver, Secure Boot on/off	Nessun cambiamento
`chkdsk /f /r`, verifica salute dischi	Nessun errore trovato, problema persiste
Controllo VSS writers (`vssadmin list writers`)	Tutti in stato Stable
Disattivazione/‑rimozione Defender, esclusione `wbengine.exe`, rimozione Malwarebytes/Firefox	Inefficace
Riavvio servizi COM+, Cryptographic, VSS	Inefficace
Script di monitoraggio VSS prima/durante il backup	Non evidenzia cause

Cause probabili (ipotesi tecniche)

Le evidenze raccolte puntano a un difetto di orchestrazione tra WSB e la gestione del lock sulla partizione EFI (ESP) quando il job è lanciato dal Task Scheduler. In alcune condizioni, un processo di sistema o un filtro (file‑system filter, antivirus, driver di cifratura, indicizzatore o servizio di manutenzione) mantiene un handle “transiente” sull’ESP proprio nell’attimo in cui WSB tenta di eseguire l’instantanea e bloccare la partizione per la fase di enumerazione/backup dei componenti critici. Il fenomeno appare:

intermittente (dipende da timing e concorrenza),
non legato all’hardware (riprodotto su brand diversi e in VM),
correlato alla schedulazione (il job manuale elude la finestra di contesa).

In altre parole: c’è un race condition nella fase di acquisizione del lock esclusivo dell’ESP. Finché Microsoft non rilascia un hotfix, conviene adottare un meccanismo di retry automatico che riprovi il backup pochi secondi dopo il fallimento: nella stragrande maggioranza dei casi il secondo (o terzo) tentativo trova la partizione libera e completa correttamente.

Tre vie per andare in produzione oggi

Work‑around A — Escludere Bare Metal Recovery / EFI dal set

Pro: il backup completa.
Contro: perdi la possibilità di ripristino bare‑metal (BMR) e la copertura dei componenti “allCritical”. È un compromesso pesante e generalmente non consigliato per server di produzione.

Work‑around B — Avviare manualmente

Pro: funziona >99% dei casi.
Contro: richiede presidio umano o script esterni; non è hands‑off.

Esempio con wbadmin (sostituisci V: con il tuo target):

wbadmin start backup -backupTarget:V: -allCritical -quiet

Work‑around C — Task Scheduler con trigger su Event ID 517/518 (consigliato)

Questa soluzione preserva il backup pianificato con BMR e aggiunge un meccanismo di retry intelligente: se compare l’errore 517 (o 518), un secondo task rilancia il job “ufficiale” finché non va a buon fine.

Implementazione passo‑passo del Work‑around C

Prerequisiti

Il task predefinito Microsoft‑Windows‑WindowsBackup già configurato nella console WSB (pianificazione, destinazione, retention).
Permessi amministrativi locali.

Passo 1 — Abilita l’esecuzione “On demand” e (facoltativo) il restart

Apri Task Scheduler → Microsoft\Windows\Backup.
Apri le proprietà del task Microsoft‑Windows‑WindowsBackup → tab Settings → spunta Allow task to be run on demand.
(Facoltativo ma utile) Nella tab Settings, abilita If this task fails, restart e imposta un intervallo (es. 1 minuto) e un massimo di tentativi (es. 3).

Passo 2 — Crea il task di retry su evento 517

Apri una console amministrativa e incolla il seguente comando (tutto su una riga o con le interruzioni ^ come in esempio):

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\""

Nota: se nel tuo ambiente si presenta anche Event ID 518, duplica il task con un secondo trigger o usa un XPath combinato:

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

Passo 3 — Imposta limiti e antiloop

Per evitare retry infiniti se la condizione di errore persiste davvero (ad esempio per un guasto disco), applica una o più di queste contromisure:

Nelle proprietà di Retry_Backup → tab Settings:
- spunta Stop the task if it runs longer than (es. 3 ore);
- spunta If the running task does not end when requested, force it to stop;
- spunta Do not start a new instance (o Stop the existing instance), per evitare job concorrenti.
Aggiungi alla Action un piccolo timeout tra un rilancio e l’altro (quando orchestrato da script wrapper).
Monitora un evento di “backup riuscito” (livello Information) per confermare il completamento e, se usi script, disarmare retry ulteriori.

Cosa aspettarti dopo il deploy

Alla prima esecuzione fallita, il task Retry_Backup rilancia il job dopo pochi secondi. Nella maggior parte dei casi il secondo tentativo completa il backup; in alcuni report si sono resi necessari fino a 7 retry prima del successo. Da quel momento i backup giornalieri risultano costantemente “OK”.

Verifica e validazione

Esegui una pianificazione di prova per la finestra tipica notturna.
Controlla i registri Application e Microsoft‑Windows‑Backup:
- presenza di un 517/518 (fallimento iniziale), immediatamente seguito da un Information di completamento del backup;
- assenza di istanze sovrapposte del task (nessun job bloccato in esecuzione).
Verifica la catena di recovery:
- se usi BMR, monta l’ultimo set e controlla che contenga i Critical Volumes e i componenti di sistema;
- esegui periodicamente un test restore su VM sandbox (o verifica l’avvio del supporto di ripristino).

Confronto fra opzioni di mitigazione

Opzione	Affidabilità	Effetto su BMR	Intervento umano	Note operative
Escludi BMR/EFI	Alta	Perdi BMR	Nullo	Usa solo se accetti la perdita di ripristino bare‑metal
Avvio manuale	Molto alta	Intatta	Richiesto	Buono come emergenza; non scalabile
Task Scheduler + Retry su 517/518	Molto alta	Intatta	Nullo	Soluzione raccomandata finché non arriva l’hotfix

Relazione con Microsoft Support

Un caso documentato da “Vestfold IT AS” è stato chiuso dopo l’accettazione del work‑around; la correzione definitiva è stata rinviata al team di sviluppo, ma al momento non esiste una patch ufficiale. Il caso potrà essere riaperto presentando nuovi log. Consiglio pratico: controlla periodicamente la pagina ufficiale di stato Release Health di Windows Server 2022 per eventuali fix che menzionino backup/ESP/WSB.

Raccomandazioni supplementari

Limita i retry: imposta nel task Retry_Backup un massimo di tentativi o un intervallo minimo tra rilanci per prevenire loop.
Mantieni il sistema aggiornato: Windows Server 2022 e Defender. Tieni escluso C:\Windows\System32\wbengine.exe e, nella finestra del backup, valuta l’esclusione di %SystemVolumeInformation% (se la tua policy lo consente). PowerShell (Admin): Add-MpPreference -ExclusionProcess "C:\Windows\System32\wbengine.exe" Add-MpPreference -ExclusionPath "C:\System Volume Information"
Se il problema riemerge nonostante il retry, usa Process Explorer (Sysinternals):
- Find → Find Handle or DLL…, cerca “ESP” oppure l’ID volume corrispondente alla partizione EFI.
- Identifica eventuali processi che tengono aperti handle sull’ESP proprio nella finestra di backup.
Valuta alternative: software di backup di terze parti che non dipendano da WSB/BMR, oppure job wbadmin personalizzati con logging esteso e log rotation.

Best practice operative e di sicurezza

Finestra di manutenzione: programma il backup quando il server è meno attivo (disabilita attività di manutenzione concorrenti, scansioni AV full, indicizzazione, defrag su volumi tradizionali, ecc.).
Single instance: evita che più job WSB partano in parallelo (ad es. per spostamenti d’orario o per un job manuale “dimenticato”).
Monitoring: aggiungi un alert su Event ID 517/518 e uno su “backup completato”, oltre a un controllo di età del file Catalog sul target.
Retention: non trascurare lo spazio libero. Lo shrinking forzato dei set vecchi può allungare i tempi e favorire le condizioni di contesa.
Ripristini periodici: un backup non testato è un backup ipotetico. Pianifica prove di restore file‑level e bare‑metal su hardware/VM di laboratorio.

Domande frequenti

Perché il backup manuale funziona quasi sempre e quello pianificato no?

Perché i trigger temporali del Planner coincidono spesso con altre attività di sistema (maintenance windows, AV, snapshot di terzi, cleanup, ecc.). Cambiando il timing o riprovando a breve distanza, la contesa sugli handle dell’ESP tipicamente scompare.

Posso “risolvere” disattivando l’antivirus?

Le prove mostrano che disattivare o rimuovere Defender e altre suite non elimina il problema in modo affidabile. Mantieni invece le esclusioni consigliate per wbengine.exe e valuta finestre di esclusione temporanea solo durante il backup, nel rispetto della tua policy di sicurezza.

È un problema del mio hardware?

No: è stato osservato su server di produttori diversi e su VM VMware. Tutto indica un problema a livello software/OS.

Posso ignorare l’ESP dal backup?

Sì, ma perdi il valore della Bare Metal Recovery. È un workaround d’emergenza, non una soluzione definitiva.

Strumenti di analisi aggiuntivi

VSS:
- vssadmin list writers → tutti dovrebbero risultare Stable senza errori;
- vssadmin list shadows per verificare residui; elimina eventuali shadow “bloccate” prima del successivo tentativo.
Volumi/partizioni: diskpart list disk list volume exit Conferma che l’ESP esista e non sia montata con lettera assegnata in modo permanente. Evita assegnazioni manuali a meno di saper esattamente cosa fai.
WSB Logs:
- Event Viewer (Application e Microsoft‑Windows‑Backup);
- cartelle di log e catalogo del target di backup (per verifiche di coerenza).

Esempi di scripting e personalizzazioni

Retry con controllo di esito (PowerShell)

Se preferisci orchestrare tutto via script, ecco uno scheletro che lancia il task WSB e attende un evento di completamento, fino a un massimo di N tentativi:

param(
  [int]$MaxRetry = 5,
  [int]$WaitSeconds = 60
)

\$taskPath = "Microsoft\Windows\Backup"
\$taskName = "Microsoft-Windows-WindowsBackup"

for (\$i = 1; \$i -le \$MaxRetry; \$i++) {
schtasks /run /tn "\$taskPath\$taskName" | Out-Null

attende l'evento di completamento o un nuovo 517

\$deadline = (Get-Date).AddSeconds(\$WaitSeconds)
\$success = \$false
while ((Get-Date) -lt \$deadline) {
\$ev = Get-WinEvent -FilterHashtable @{
LogName='Application';
ProviderName='Microsoft-Windows-Backup';
StartTime=(Get-Date).AddMinutes(-5)
} -MaxEvents 200
if (\$ev | Where-Object { \$.LevelDisplayName -eq 'Information' -and \$.Message -match 'completed|completato' }) {
\$success = \$true; break
}
if (\$ev | Where-Object { $\_.Id -in 517,518 }) { break }
Start-Sleep -Seconds 5
}
if (\$success) { Write-Host "Backup OK al tentativo \$i"; break }
if (\$i -eq \$MaxRetry) { throw "Backup non riuscito dopo \$MaxRetry tentativi" }
} </code></pre>

<p>Questo approccio va usato solo se hai bisogno di logica personalizzata non ottenibile con i trigger <em>onevent</em> del Planner.</p>

<h2>Checklist operativa</h2>
<ul>
  <li>✔️ Conferma che l’errore sia <strong>0x8078011E</strong> con <strong>Event&nbsp;ID&nbsp;517/518</strong> legato alla <strong>ESP</strong>.</li>
  <li>✔️ Verifica che i job <em>manuali</em> completino regolarmente.</li>
  <li>✔️ Applica il <strong>work‑around con Task Scheduler</strong> e testa i retry.</li>
  <li>✔️ Imposta limiti/antiloop e monitoring degli esiti.</li>
  <li>✔️ Aggiorna ed escludi <code>wbengine.exe</code> e (se consentito) <code>%SystemVolumeInformation%</code> nella finestra di backup.</li>
  <li>✔️ Se ricompare, indaga con Process Explorer gli handle sull’ESP e raccogli log per un eventuale follow‑up con Microsoft.</li>
</ul>

<h2>Conclusioni</h2>
<p>Il comportamento osservato è riconducibile a un <strong>bug di Windows Server&nbsp;2022</strong> nella gestione del lock esclusivo sulla <strong>EFI System Partition</strong> durante i backup <em>pianificati</em> di Windows Server Backup. Fino al rilascio di un <em>hotfix</em> ufficiale, il metodo più affidabile per garantire backup giornalieri completi senza rinunciare alla <em>Bare Metal Recovery</em> è il <strong>work‑around basato su Task Scheduler</strong> con trigger sugli <strong>Event&nbsp;ID&nbsp;517/518</strong> e retry controllato. Implementalo con le cautele indicate (limiti, antiloop, monitoraggio) e abbinalo a buone pratiche di manutenzione: otterrai livelli di affidabilità tipici di un sistema “self‑healing” pur restando nell’alveo degli strumenti nativi Microsoft.</p>

<hr>

<p><em>Appendice: esempi utili</em></p>
<ul>
  <li><strong>Comando <code>wbadmin</code> tipico con BMR</strong>:
    <pre><code>wbadmin start backup -backupTarget:\\NAS\Backups\SRV01 -user:DOMAIN\backupsvc -password:* -allCritical -quiet

Verifica rapida VSS:

vssadmin list writers
vssadmin list providers
vssadmin list shadows

Filtro personalizzato in Event Viewer (XML) per 517/518:

&lt;QueryList&gt;
  &lt;Query Id="0" Path="Application"&gt;
    &lt;Select Path="Application"&gt;&lt;![CDATA[ [System[Provider[@Name='Microsoft-Windows-Backup'] and (EventID=517 or EventID=518)]] ]]&gt;*&lt;/Select&gt;
  &lt;/Query&gt;
&lt;/QueryList&gt;

Infine, mantieni un canale aperto con il supporto Microsoft: casi come quello riportato da Vestfold IT AS indicano che il problema è noto e che una correzione è in valutazione. Nel frattempo, il pattern “rileva‑e‑ritenta” descritto sopra è la misura più efficace sul campo.