[Veeam] Veeam 13.1 errore “Blockset blocks immutability mismatch”: cosa significa e come risolverlo

Se dopo l’aggiornamento a Veeam Backup & Replication 13.1 i tuoi job verso object storage immutabile hanno iniziato a fallire con l’errore Blockset blocks immutability mismatch, la buona notizia è che non hai sbagliato nulla nella configurazione del bucket, delle policy IAM o della retention.

La notizia meno buona è che si tratta di un bug noto della build 13.1.0.411, che la patch ufficiale risolve solo in avanti: i job già compromessi continuano a fallire anche dopo l’aggiornamento.

In questa guida vediamo cosa succede tecnicamente, come capire quante macchine sono coinvolte, cosa fare nell’ordine corretto e — soprattutto — cosa non toccare mentre attendi la risoluzione definitiva.

In due parole: i restore point già presenti restano integri e ripristinabili. Il problema riguarda la creazione dei nuovi checkpoint, non i dati esistenti. Non è un incidente di data loss, è un buco nella copertura di backup che si allarga a ogni run.

In breve

1. L’errore colpisce i job che scrivono direttamente su object storage immutabile in VBR 13.1.0.411.
2. La causa è un’inconsistenza nell’aggiornamento dei metadati di immutabilità, che manda in errore la creazione del checkpoint.
3. La patch 13.1.1.18 (12/08/2026, KB4738) risolve la causa radice, ma non sana le catene già compromesse.
4. Installala comunque subito: ogni run senza patch aggiunge nuove VM all’elenco delle colpite.
5. Per le VM già in errore serve l’hotfix del supporto Veeam: apri un case citando il known issue.
6. Nel frattempo verifica la ripristinabilità dei punti esistenti e non modificare i parametri di generazione dei blocchi.

L’errore, per come lo vedi

Nella sessione del job compare una sequenza di questo tipo:

Backup copy for VM01 started at 26/08/2026 15:43:06
Error: Blockset blocks immutability mismatch. Failed to download disk 'VM01_2-flat.vmdk'.
Failed to process VM01 (0 B) at 26/08/2026 15:44:13

Due dettagli che vale la pena notare, perché aiutano a riconoscere il pattern:

• 0 B processati. Il job non fallisce a metà trasferimento: si ferma prima di scrivere qualsiasi cosa. Non hai dati parziali nel bucket per quel restore point.
• Il messaggio parla di “download disk” anche in un job in uscita verso il cloud. Non è un errore di lettura dal source: è la fase in cui Veeam ricostruisce il riferimento ai blocchi già presenti nel repository per capire cosa deve caricare. È lì che il confronto sui metadati di immutabilità non torna.

Il sintomo più caratteristico, però, è un altro: l’elenco delle macchine in errore cresce a ogni esecuzione. Il primo giorno una VM, il giorno dopo tre, poi cinque. Se stai guardando una lista di job con la maggioranza in Success e un blocco crescente in Failed, sei quasi certamente in questo scenario e non davanti a un problema di rete o di provider.

Perché accade

Su un repository object storage con immutabilità attiva, Veeam non si limita a caricare i blocchi: deve anche mantenere allineate le date di scadenza del lock degli oggetti. Quando un nuovo restore point riutilizza blocchi già presenti (ed è la norma con backup incrementali e deduplica), la protezione di quei blocchi va estesa, altrimenti scadrebbero prima del punto che li referenzia.

È esattamente in questo aggiornamento dei metadati che si inserisce il bug. Veeam lo ha classificato come known issue #1 della 13.1 nel Top Issues Tracker dei forum R&D: in alcuni casi si verifica un’inconsistenza durante l’aggiornamento dei metadati di immutabilità, che fa fallire la creazione del checkpoint per il job interessato. I backup e i restore point esistenti rimangono intatti e ripristinabili, ma il job continuerà a fallire fino a quando il problema non viene risolto.

Il perimetro dichiarato è quello dei job che scrivono direttamente su object storage immutabile. Rientrano quindi:

• Backup job con target un repository S3 / S3-compatible / Azure Blob con Object Lock o immutability policy attiva;
• Backup Copy job verso gli stessi target, incluso il caso di un provider Cloud Connect che espone object storage immutabile;
• Deployment su Veeam Software Appliance e su Windows, indifferentemente.

Non rientrano invece i repository hardened Linux con flag di immutabilità XFS. Se vedi errori di immutabilità su una repo hardened, la causa è quasi certamente diversa: vedi la sezione finale sui falsi positivi.

Le versioni: chi è colpito e chi no

Build	Data	Stato rispetto al bug
13.0.x	fino a 08/2026	Non interessata
13.1.0.411	29/07/2026	Colpita
13.1.1.18	12/08/2026	Risolta (solo per il futuro)
ISO 13.1.1 nuove installazioni	—	Già patchata all’origine

La verifica della build installata si fa dal menu principale della console: ≡ > Help > About.

Attenzione a un caso spesso dimenticato: Veeam Recovery Orchestrator 13.1 utilizza un deployment embedded di VBR 13.1.0.411. Se hai VRO in produzione, anche quell’istanza va patchata.

Fase 1 — Installa la patch 13.1.1.18

Questo passaggio non sistema le VM già in errore, ma ferma l’emorragia. È la prima cosa da fare, non l’ultima.

La patch è disponibile da KB4738 in due formati equivalenti — ISO (2,92 GB) ed EXE/ZIP autoestraente (2,68 GB) — e contiene lo stesso payload. L’ISO parte subito perché i file sono già montabili; l’EXE è più piccolo ma richiede più spazio su disco e tempo di estrazione.

Sequenza corretta:

1. Se usi Veeam Backup Enterprise Manager, aggiorna prima quello, poi il backup server.
2. Scarica il file e sbloccalo, altrimenti l’installer si rifiuta di partire:

Unblock-File -Path "C:\Path\to\File\VeeamBackup&Replication_13.1.1.18_20260812_patch.iso"

3. Verifica l’hash prima di installare:

Lancia l’installazione. Può essere richiesto un reboot: pianifica la finestra di conseguenza.

4. Aggiorna i componenti remoti (console su altre postazioni, proxy, mount server) come da procedura standard post-patch.

La patch è utilizzabile esclusivamente sulla build 13.1.0.411. Su versioni precedenti l’installer risponde This update is not compatible with installed product version. Se sei su 13.0.x devi passare dall’ISO di upgrade completo, non dalla patch.

Su Veeam Software Appliance l’aggiornamento si esegue direttamente dall’appliance stessa. Nota di contorno: il 27/08/2026 è stato pubblicato un repack dell’ISO di installazione dell’appliance (VeeamSoftwareAppliance_13.1.1.18_20260825.iso) per risolvere un problema che impediva il boot dell’ISO su una macchina dove l’appliance è già distribuita. Se hai scaricato l’ISO prima di quella data e ti serve per una nuova installazione, riscaricala.

Cosa altro porta la stessa patch

Vale la pena saperlo, perché potrebbe risolverti problemi che stavi indagando separatamente:

Componente	Problema risolto
Object Storage Repository	Blockset blocks immutability mismatch
Veeam Software Appliance	Servizi core non partono e Web UI in HTTP 502 con Failed to connect to identity service su appliance configurate con proxy HTTP/HTTPS
Guest Processing	Warning Failed to explore PostgreSQL instance su guest Windows con istanze PostgreSQL, incluse quelle embedded installate da software terzi
Cloud Connect	Backup Copy job verso repository Cloud Connect che falliscono dopo l’upgrade a 13.1 quando il provider usa un certificato SSL pubblicamente attendibile e la cache di revoca è vuota

Quest’ultimo punto merita attenzione: se hai Backup Copy job verso un provider Cloud Connect che falliscono ma con un errore diverso da quello sull’immutabilità, potresti essere nel secondo scenario e non nel primo.

Se non sei su 13.1: gli altri errori di immutabilità

Se l’errore che vedi somiglia a questo ma la tua build non è la 13.1.0.411, con buona probabilità sei davanti a un problema diverso della stessa famiglia.

Time shift su hardened repository. Il messaggio in questo caso è A problem occurred during setting the immutable flag: repository time shift detected, immutability flag cannot be set e rimanda a KB4482. Il meccanismo: il servizio di immutabilità sulla macchina Linux tiene traccia del tempo in un file timeLog e, se il salto rilevato supera le 24 ore, crea un file immutabile chiamato retainLock che blocca ogni modifica dello stato di immutabilità, sia sui file esistenti sia sui nuovi. È una protezione contro la manipolazione delle date, ma scatta anche per cause del tutto legittime: modifica intenzionale dell’ora di sistema, macchina Linux spenta per un periodo prolungato, arresto del servizio VeeamTransport, o aggiunta di una repository hardened già usata in precedenza e che contiene già un timeLog. Verificata la correttezza dell’ora attuale, la protezione si può resettare con la procedura descritta nella KB.

Retention GFS più lunga del previsto. Con la 13.0.1.1071 Veeam ha corretto un’anomalia per cui l’impostazione [For the minimum immutability duration only] non veniva applicata correttamente ai backup GFS, producendo periodi di immutabilità più lunghi del previsto. Per evitare di accorciare inaspettatamente l’immutabilità dei GFS esistenti, l’aggiornamento imposta automaticamente tutti i repository object storage esistenti su [For the entire duration of their retention policy]. Se dopo quell’update hai visto crescere l’occupazione del bucket, la spiegazione è probabilmente questa: l’impostazione si può riportare al valore precedente, ma solo dopo aver valutato quali restore point ne vengono impattati.

Conclusioni

Questo caso è un buon promemoria su una cosa che si tende a rimuovere: l’immutabilità aggiunge una superficie di fallimento in cambio della protezione che offre. Un blocco non modificabile è un blocco su cui un bug nei metadati non si corregge riscrivendo, e non si aggira cancellando.

Il che non è un argomento contro l’immutabilità resta la difesa più solida che hai contro un ransomware che arriva alle credenziali del backup. Se stai valutando adesso l’upgrade a 13.1 e non l’hai ancora fatto, parti direttamente dall’ISO 13.1.1: la correzione è integrata, e le nuove installazioni non richiedono alcun passaggio aggiuntivo.

Riferimenti

• Veeam KB4738 — Release Information for Veeam Backup & Replication 13 and Updates