JOB APPESO / FANTASMA

Ciao, secondo me il modo più rapido col quale puoi killarlo è andare a cercare il PID del processo relativo al Backup Job in questione, cercandolo nell’ultimo log che ha generato (partendo dal fondo); se lo trovi ancora nel Task Manager, killalo (dovrebbe far capo ad un processo chiamato Veeam.Backup.Manager.exe, potresti trovarne più di uno, ma ovviamente ognuno ha un PID diverso).

si può andare a caccia del processo ma… visto che sono 43 giorni, approfitterei per un windows update e un riavvio 😊

Io ho avuto un problema simile con un Job Kasten che mi era rimasto appeso per giorni nella console di VBR (lo avevo stoppato sporco) e mi sono fatto aiutare da "Claudio".

La procedura allegata ha funzionato… delicata ma efficace.
Spero sia applicabile anche al tuo caso.

sì, diciamo che il tuo runbook al livello 2 prevede il riavvio del server e, in un caso come questo sopra dove il job è iniziato/controllato dal VBR al 99.9% risolve.

kasten non lo tocco da molto ma credo che la schedulazione delle policy di protezione parta ancora da dentro kasten e il VBR lo mostri solamente… o mi sbaglio? 😊

Quando colleghi Kasten a VBR (da VBR col Kasten plugin) puoi osservare lo stato dei Job eseguiti da Kasten (localmente sul cluster K8s su cui è installato) come fossero dei normali job VBR.

Il job è fisicamente eseguito da Kasten ma visto da VBR come fosse suo. Pasticciando nel lab avevo staccato la spina brutalmente al job lato Kasten e VBR ha continuato per giorni a restare appeso.

Il livello 2 non è stato sufficiente, ho dovuto mettere le mani dentro il DB Postgres della VSA e ripulirlo.

Diciamo che la procedura è per i casi estremi ma non dovrebbe essere limitata a job Kasten.

sì, allora è come ricordavo o, per fare un esempio legacy, col plugin RMAN gestito dal server Oracle e non dal VBR: la console VBR è solo un monitor. e il VBR stesso poco più di una destinazione di scrittura.

nel caso del nostro amico invece è il “capo” e quindi una riavviata lo risveglierà 🤓