Veeam 13.1: checkpoint removal in Warning anche dopo il fix

In breve

Dopo la patch 13.1.1.18 e il fix privato del supporto, i Backup Copy verso Wasabi erano tornati in Success. Pochi giorni dopo, però, il Background Removal Job ha iniziato a chiudere in Warning con lo stesso errore di prima: Blockset blocks immutability mismatch, questa volta sul metodo Cloud.DeleteCheckpointsNoSession.

Il fix privato era installato e l’infrastruttura era sulla 13.1.1.18. Il primo fix, però, non bastava per la rimozione dei checkpoint, che è un processo separato dai Backup Copy.

Si è risolto con un secondo fix privato del supporto, che si installa solo sul server VBR e aggiorna poi i componenti. Dopo averlo applicato ho aggiornato comunque alla 13.1.2.57, e le sessioni si sono sistemate da sole.

Se dopo il fix i Backup Copy sono verdi ma il Background Removal Job resta in Warning, non è un problema di configurazione: segnalalo sul case e chiedi il fix aggiornato per la tua build.

Il contesto

Questo è il terzo capitolo di una storia che ho già raccontato qui su ConsalviTech. Nel primo articolo ho spiegato il bug della build 13.1.0.411 sui metadati di immutabilità. Nel secondo, perché in alcuni casi l’errore restava anche dopo la patch 13.1.1.18 e serviva un fix privato del supporto.

Quel fix aveva funzionato: i job di Backup Copy erano tornati verdi. Ma il Backup Copy non è l’unico processo che lavora sul bucket. C’è anche il Background Removal Job, che ogni notte rimuove i checkpoint scaduti dalle catene in object storage. Ed è lì che il problema si è ripresentato.

L’ambiente in cui è successo:

Componente	Configurazione
Veeam Backup & Replication	13.1.1.18 su Windows, con fix privato TF1579668 applicato
Repository	Wasabi S3 con immutabilità abilitata
Job coinvolto	Backup Copy verso cloud, a cadenza settimanale

Il primo fix aveva rimesso in ordine i Backup Copy. Il resto della storia riguarda la pulizia dei checkpoint.

Il sintomo

La sessione di Background Removal è andata bene per qualche giorno, poi ha iniziato a chiudere in Warning. Nel dettaglio della sessione compariva questo messaggio, una riga per ogni backup coinvolto:

Failed to remove checkpoints for the backup Backup Copy on Cloud - Wasabi\<job> - <VM> from the repository WASABI: Blockset blocks immutability mismatch. Agent failed to process method {Cloud.DeleteCheckpointsNoSession}.

Tre cose rendevano il caso poco chiaro:

I job di Backup Copy erano in Success. Il problema riguardava solo la pulizia dei checkpoint, non la copia dei dati.
Le VM coinvolte cambiavano. Una sessione segnalava tre backup, quella dopo due, con nomi diversi.
Non succedeva sempre. Alcune sessioni erano pulite, altre no, senza un motivo evidente.

Il messaggio è identico a quello del bug originale, quindi la prima reazione è pensare che il fix non sia stato applicato bene. In realtà era installato correttamente: semplicemente non copriva questo processo.

Un checkpoint che non viene rimosso non è una perdita di dati: i restore point restano integri. Però lo spazio occupato nel bucket non si libera, e su object storage lo paghi.

Primo tentativo: risincronizzare il repository

Il primo consiglio del supporto è stato il classico per ogni mismatch: una sincronizzazione pulita del repository, seguendo la KB4303. In pratica:

Disattivare i job che scrivono sul repository object storage, così nessuna sessione lo tiene occupato.
Lanciare il Rescan del repository dalla console.
Riattivare i job e aspettare i run successivi.

L’ho fatto, ma il warning si è ripresentato già nella sessione di Background Removal successiva. Ha senso: il rescan riallinea la vista che VBR ha del bucket, ma non corregge il codice che esegue la rimozione.

Il rescan resta comunque il primo passo giusto. Esclude i casi in cui il mismatch dipende solo da metadati disallineati nel database di configurazione.

Raccogliere i log giusti

Per i problemi su object storage il supporto chiede una raccolta log diversa da quella che si fa per un singolo job. Il bundle del job non basta, perché la checkpoint removal non è una sessione di quel job.

La procedura corretta:

Apri il Support Wizard dalla console (menu principale, Help, Support Information).
Scegli l’opzione Export logs for these components e seleziona il server VBR.
Imposta un intervallo che copra le sessioni in warning. Io ho preso gli ultimi 14 giorni.
Carica il pacchetto sul case e avvisa il tecnico via mail: Veeam non riceve notifiche automatiche dell’upload.

I riferimenti sono la KB1832 per la raccolta e la KB4162 per l’upload.

Il vantaggio di questa modalità è che il pacchetto include anche le cartelle di log dei componenti remoti, gateway compresi. Al supporto servono per capire con quale build è girata ogni sessione.

Cosa è emerso dai log

Il primo fix (TF1579668) era installato e faceva il suo lavoro sui Backup Copy. Non copriva però tutti i casi della checkpoint removal, che gira con il proprio agent e ha una logica sua sulle catene immutabili.

La risposta del supporto è stata un nuovo fix privato, sempre per la 13.1.1.18, pensato per chiudere anche questa parte.

Un controllo utile in questi casi: l’intestazione dei log dell’agent dice con quale build è girata la sessione. I log della rimozione si trovano in una cartella di questo tipo:

<componente>\VeeamBackup\System\CheckpointRemoval\<data>\Agent.Cleanup.BlobRepo_<n>.log

Un componente con il fix applicato riporta nell’intestazione qualcosa del genere:

Module version: 13.1.1.1004
Build edition: standard
Comments: Private Fix TF1579668,13.1.1-GA-PF VDP

Il campo Comments indica il fix privato installato. Se è null, quella sessione è girata sulla build standard.

La soluzione

A risolvere è stato il nuovo fix privato fornito dal supporto (TF1701255, per la 13.1.1.18).

Rispetto al primo ha un vantaggio: si installa solo sul server VBR. Al riavvio la console chiede di aggiornare i componenti, e l’agent viene sostituito automaticamente su tutta l’infrastruttura.

La procedura:

Verifica che non ci siano job in esecuzione.
Chiudi la console e ferma il servizio Veeam Backup Service.
Controlla l’hash SHA-256 del pacchetto ricevuto dal supporto, prima di eseguirlo.
Esegui l’installer del fix sul server VBR.
Avvia il Veeam Backup Service, se non riparte da solo.
Apri la console e completa l’aggiornamento dei componenti quando viene proposto.
Tieni d’occhio le sessioni di Background Removal per i 2-3 giorni successivi.

Per il controllo dell’hash su Windows basta PowerShell:

Get-FileHash .\<nome-del-fix>.exe -Algorithm SHA256

Il valore deve coincidere con quello del file .sha256 incluso nel pacchetto.

I fix privati sono legati al singolo case e alla build esatta. Non scaricarli da link trovati in rete e non riusarli su build diverse: apri un case e fattelo dare dal supporto.

Upgrade alla 13.1.2.57 e chiusura

Dopo il fix ho aggiornato anche alla 13.1.2.57, così da avere server e componenti allineati sulla stessa build. Il supporto ha confermato che i job e la checkpoint removal si sarebbero sistemati da soli alla prima sessione dopo l’upgrade, senza interventi manuali sulle catene.

Un dettaglio utile già prima dell’upgrade: nei log della sessione successiva al primo fix, il mismatch compariva come messaggio informativo e non più come errore. Secondo il supporto era il meccanismo di riparazione al lavoro.