[Veeam] Veeam 13.1: “Blockset blocks immutability mismatch” persiste anche dopo la patch 13.1.1.18

Introduzione

Se i job di Backup Copy verso un object storage immutabile continuano a fallire con l’errore “Blockset blocks immutability mismatch” anche dopo aver installato la patch 13.1.1.18, la soluzione c’è: la patch ferma i nuovi casi, ma per le catene già compromesse serve un fix privato fornito dal supporto Veeam.

In questa guida racconto il caso che ho affrontato in produzione, con un repository su Cloud con immutabilità abilitata. Vediamo come riconoscere il problema, come confermarlo nei log, come ottenere il fix e dove applicarlo, passo per passo.

Se non hai ancora aggiornato, parti dalla 13.1.1.18: potrebbe bastare. Questa guida serve per le VM che restano in errore anche dopo la patch.

I sintomi

Il segnale tipico è un Backup Copy job verso cloud in cui alcune VM completano correttamente e altre falliscono sempre, sessione dopo sessione. Nel mio caso il job copiava su Wasabi decine di VM: la maggior parte in Success, quattro in Failed.

Nel report via email e nel dettaglio della sessione in console l’errore si presenta così:

Failed to perform post-processing: Blockset blocks immutability mismatch.
Failed to delete cloud storage {GUID}. Agent failed to process method {Cloud.DeleteStorage}.
Failed to delete 'VM01.vm-12345D2026-08-05T040025_XXXX.vbk' per retention policy
Processing finished with errors

Tre dettagli aiutano a riconoscerlo:

• Il trasferimento dei dati va a buon fine. Nella prima sessione della giornata il job legge e trasferisce regolarmente, poi fallisce alla fine.
• L’errore arriva in post-processing. Il job si blocca quando applica la retention e prova a eliminare un .vbk o un .vib vecchio dal bucket.
• I retry falliscono tutti allo stesso modo. Ogni tentativo dura pochi minuti, trasferisce 0 B e si ferma sullo stesso file.

Nel mio ambiente l’errore è comparso subito dopo l’installazione della prima release della 13.1. Con l’aggiornamento alla 13.1.1.18 la situazione è migliorata molto, ma alcune VM sono rimaste in errore.

La causa

Non è un problema del cloud né di configurazione del repository. È un bug di Veeam 13.1 che Veeam stessa ha messo al primo posto nel “[V13.1] Top Issues Tracker” sui propri R&D Forums.

Durante l’aggiornamento dei metadati di immutabilità può crearsi un’incoerenza tra ciò che Veeam registra e i blocchi presenti sull’object storage. Quando la retention prova a eliminare un restore point, il controllo sull’immutabilità dei blocchi non torna e l’operazione viene interrotta.

Spiega anche perché alcune VM funzionano e altre no: falliscono solo le catene i cui metadati si sono corrotti.

Versione	Comportamento
Prima release 13.1	Il bug può corrompere i metadati di immutabilità di nuove catene
13.1.1.18	Elimina la causa: le catene sane non si corrompono più
13.1.1.18 + fix privato	Ripara anche le catene già compromesse

Una nota rassicurante: i restore point già presenti sul repository immutabile restano integri e ripristinabili. Il problema riguarda la gestione della retention, non i dati.

Come confermarlo nei log

La conferma definitiva sta nei log del task della singola VM, sul server Veeam. Il percorso di default è:

C:\ProgramData\Veeam\Backup\<Nome Backup Copy job>\<Nome job sorgente>\Task.<NomeVM>.vm-<ID>.log

Cerca la stringa “immutability mismatch”. Se si tratta di questo bug troverai una sequenza come questa:

Error  Blockset blocks immutability mismatch. (Veeam.Backup.Common.CCppComponentException)
Error     in c++: Failed to unlink FIB layer. FIB layer ID: [{GUID}/...]
Error     in c++: Failed to release FIB layer.
Error     in c++: Failed to delete storage [{GUID}].
Error  Failed to delete cloud storage {GUID}.
Error  Agent failed to process method {Cloud.DeleteStorage}.

La riga chiave è “Failed to unlink FIB layer”: Veeam non riesce a sganciare i blocchi del file dalla catena perché i metadati di immutabilità non coincidono.

Come ottenere il fix

Il fix non è pubblico: va richiesto aprendo un case al supporto Veeam. Nel mio caso il tecnico ha analizzato i log e ha inviato il pacchetto già nella prima risposta.

Per velocizzare il case conviene includere:

• versione e build esatte (per esempio 13.1.1.18) e quando è comparso l’errore rispetto agli aggiornamenti;
• tipo di repository (object storage, provider, immutabilità abilitata);
• l’elenco delle VM in errore e il testo completo dell’errore;
• il riferimento al known issue del “[V13.1] Top Issues Tracker”;
• l’export dei log da menu ☰ → Help → Support Information, selezionando il Backup Copy job e le ultime sessioni fallite.

Specifica anche che non hai fatto interventi manuali sul bucket o sulle catene. È un’informazione che il supporto chiede sempre, e con l’immutabilità attiva comunque non potresti cancellare nulla a mano.

Il pacchetto ricevuto contiene due binari: VeeamAgent.exe per Windows e veeamagent per Linux, con i rispettivi hash SHA256.

Dove va applicato il fix

Il fix va applicato sul server Veeam Backup & Replication e sulle macchine che fanno da gateway verso l’object storage. Non va toccato nulla sulle VM protette.

Il motivo è semplice: VeeamAgent è il componente di trasporto che dialoga con il bucket ed esegue materialmente la cancellazione per retention. Sul bucket non si può installare nulla, quindi le operazioni le esegue la macchina Veeam che fa da gateway.

flowchart LR
  A[VM protette<br/>nessuna modifica] --> B[Server VBR<br/>VeeamAgent patchato]
  B --> C[Gateway server<br/>VeeamAgent patchato]
  C --> D[Bucket immutabile<br/>nessuna modifica]

Per capire quali macchine includere apri le proprietà del repository object storage e guarda la pagina dei gateway:

Configurazione del repository	Dove sostituire VeeamAgent
Gateway server specificati	Server VBR + i gateway indicati
Gateway = server VBR	Solo server VBR
Selezione automatica o Direct connection	Server VBR + tutti i proxy e i repository gestiti che possono fare da gateway

Il binario Linux serve solo se tra i gateway c’è una macchina Linux, per esempio un hardened repository o un proxy Linux.

Procedura passo passo

1. Preparazione

Prima di toccare qualsiasi file mettiti in sicurezza:

• Snapshot del server VBR, se è una VM.
• Backup della configurazione da menu ☰ → Configuration Backup → Backup now.
• Verifica dell’hash del file ricevuto, prima di usarlo.

Get-FileHash .\Windows\VeeamAgent.exe -Algorithm SHA256

Il valore deve coincidere con quello indicato dal supporto nel case.

2. Fermare job e servizio

Disabilita i job o verifica che non ce ne sia nessuno in esecuzione. Chiudi la console e ferma il servizio Veeam Backup Service:

Stop-Service -Name VeeamBackupSvc

3. Sostituire VeeamAgent sulle macchine Windows

Sul server VBR e su ogni gateway Windows:

1. Vai in C:\Program Files\Veeam\Backup Transport\x64.
2. Rinomina VeeamAgent.exe in VeeamAgent.exe.bak, in modo da poter tornare indietro.
3. Copia al suo posto il VeeamAgent.exe del fix.

VeeamAgent non è un servizio: viene avviato a ogni task. A job fermi il file non è in uso e si sostituisce senza problemi.

4. Sostituire veeamagent sulle macchine Linux

Solo se hai gateway Linux. Da root:

systemctl stop veeamtransport
mv /opt/veeam/transport/veeamagent /opt/veeam/transport/veeamagent.bak
cp veeamagent /opt/veeam/transport/
chown root:root /opt/veeam/transport/veeamagent
chmod 755 /opt/veeam/transport/veeamagent
systemctl start veeamtransport

5. Riavvio e test

Riavvia il servizio, riabilita i job e lancia a mano il Backup Copy sulle VM che erano in errore:

Start-Service -Name VeeamBackupSvc

Il primo run dopo il fix può durare più del solito, perché applica in una volta sola la retention rimasta arretrata. Nel mio caso tutte le VM sono tornate in Success al primo tentativo.

Dopo il fix

Una volta sistemate le catene restano un paio di cose da tenere presenti.

Il prossimo aggiornamento sovrascrive il binario. Qualsiasi patch o upgrade di Veeam reinstalla i componenti di trasporto e rimpiazza il VeeamAgent modificato. Se nel frattempo le catene sono tornate sane non è un problema, ma è bene saperlo.

Documenta la modifica. Un binario non standard in produzione va registrato nel change management, con riferimento al case, data e macchine coinvolte. In un ISMS certificato ISO/IEC 27001 è esattamente il tipo di modifica che un auditor si aspetta di trovare tracciata.

Controlla i job nei giorni successivi. Verifica che la retention sul bucket venga applicata regolarmente e che non compaiano nuove VM con lo stesso errore. Se succede, la causa non è più solo il bug della prima release e conviene riaprire il case.

Conclusioni

L’errore “Blockset blocks immutability mismatch” spaventa perché tocca proprio i backup immutabili, cioè l’ultima linea di difesa contro il ransomware. In realtà i dati sono al sicuro: è la retention che si inceppa.

La strada è chiara. Aggiorna alla 13.1.1.18 per fermare nuovi casi, apri un case per ottenere il fix privato e applicalo sul server VBR e sui gateway. Non serve cancellare nulla, né ricreare job o catene.

Se avete incontrato lo stesso problema, magari con un provider diverso da Wasabi, scrivetelo nei commenti: è utile capire quanto è diffuso.