Caricamento in corso
News VMware VMware

[VMware] Backup schedulati che falliscono su vCenter Server 9.0.2.0 con la policy “Retain Last X Backups”

Questa guida spiega passo-passo come risolvere un problema che affligge vCenter Server 9.0.1 / 9.0.2.0 (Build 25148086): i backup file-based schedulati falliscono ogni notte, mentre i backup manuali continuano a funzionare regolarmente. Nell’interfaccia VAMI i job compaiono con stato Error e il messaggio generico:

“BackupManager encountered an exception. See logs for details.”

Si tratta di un bug noto e confermato da Broadcom (KB 428785), legato alla combinazione tra la versione 9.0.2.0 e la policy di retention “Retain Last X Backups”. Di seguito vediamo come diagnosticarlo dai log e come applicare il workaround ufficiale.

Sintomi del problema

  • I backup schedulati falliscono in modo costante (stato Error nel VAMI → Backup → Activity).
  • I backup manuali riescono sempre, indipendentemente dalle impostazioni.
  • La policy di retention è impostata su “Retain Last X Backups” (es. trattieni gli ultimi 5).
  • Con la policy “Retain All Backups” i backup schedulati funzionano.
  • Il problema si presenta dopo l’aggiornamento a vCenter 9.0.1 o 9.0.2.0.

Il rischio concreto è restare scoperti per giorni o settimane senza accorgersene, dato che il messaggio d’errore è generico. Verifica sempre la data dell’ultimo backup schedulato completato.

Fase 1 — Confermare la causa dai log

  • Accedi via SSH alla vCenter Server (user root).
  • Entra nella shell bash digitando: shell
  • Apri il log del backup e cerca gli errori:
grep -iE "error|exception|fail" /var/log/vmware/applmgmt/backup.log | tail -40

Se sei davanti a questo bug, nel log troverai una sequenza di errori che parte dalla fase di backup dei file WAL (Write-Ahead Logging) del database vCenter:

[VCDB-WAL-Backup] error writing output file
BrokenPipeError: [Errno 32] Broken pipe
ERROR: Failed to backup WAL files
ERROR: Failed to dispatch WAL files
ERROR: Encounter error during backup VCDB
ERROR: BackupManager encountered an exception: Hit exception inside process VCDBBackup:
       BackupRestoreError.__init__() missing 1 required positional argument: 'status'

Il dettaglio chiave è il BrokenPipe sul processo VCDB-WAL-Backup seguito dal TypeError su BackupRestoreError. Non è un problema di spazio disco o di rete: è un bug nel codice di gestione della retention.

Prima di procedere conviene escludere le cause banali verificando che non si tratti di disco pieno (né sull’appliance né sul target di backup):

df -h
df -ih

Se gli spazi e gli inode sono regolari, la causa è il bug descritto.

Fase 2 — La soluzione rapida (workaround temporaneo)

Se hai bisogno di tornare operativo immediatamente, senza toccare i file di sistema, cambia la policy di retention:

  • Apri il VAMI (https://<vcenter>:5480) → Backup.
  • Clicca EDIT sullo schedule.
  • Imposta “Retain all backups” al posto di “Retain last X backups”.
  • Salva e lancia un BACKUP NOW schedulato per verificare.

Svantaggio: con “Retain all backups” i backup non vengono più ruotati automaticamente, quindi dovrai eliminare manualmente quelli vecchi dal repository per non saturare lo spazio.

Per mantenere la rotazione automatica, passa alla Fase 3.

Fase 3 — Applicare il fix ufficiale del KB 428785

Broadcom fornisce due script Python sostitutivi che correggono la gestione della retention. La procedura va eseguita con attenzione.

Prima di iniziare, esegui una snapshot non-memory della VM del vCenter Server. È la tua rete di sicurezza in caso di problemi.

1. Scaricare gli script dal KB

Accedi al portale Broadcom, apri l’articolo KB 428785 e scarica i due file allegati:

ScheduleManager.py
SchedulerCron.py

2. Caricare gli script sul vCenter

Dal tuo PC, carica i due file nella directory /root dell’appliance via SCP:

scp ScheduleManager.py SchedulerCron.py root@<vcenter>:/root/

Se scp fallisce con l’errore “Received message too long”, è perché la shell di default di root è la appliancesh ristretta. Dalla sessione SSH imposta temporaneamente bash come shell con chsh -s /bin/bash root, esegui di nuovo lo scp, e (se vuoi) ripristina alla fine con chsh -s /bin/appliancesh root.

3. Salvare una copia degli originali

Via SSH sul vCenter, crea un backup dei file di sistema esistenti:

cp /usr/lib/applmgmt/backup_restore/py/vmware/appliance/backup_restore/ScheduleManager.py /root/ScheduleManager.py.original
cp /usr/lib/applmgmt/backup_restore/scripts/SchedulerCron.py /root/SchedulerCron.py.original

4. Sostituire i file

cp /root/ScheduleManager.py /usr/lib/applmgmt/backup_restore/py/vmware/appliance/backup_restore/
cp /root/SchedulerCron.py /usr/lib/applmgmt/backup_restore/scripts/

5. Impostare i permessi corretti

chmod 544 /usr/lib/applmgmt/backup_restore/scripts/SchedulerCron.py
chmod 444 /usr/lib/applmgmt/backup_restore/py/vmware/appliance/backup_restore/ScheduleManager.py

6. Riavviare il servizio applmgmt

service-control --restart applmgmt

Attendi il messaggio Successfully restarted service applmgmt.

Verifica finale

  • Lascia la policy su “Retain Last X Backups” (ora dovrebbe funzionare).
  • Attendi l’esecuzione del job schedulato (il BACKUP NOW manuale non testa il bug, perché i backup manuali funzionavano già).
  • Controlla l’esito dal VAMI oppure via SSH:
grep -iE "job complete|job failed" /var/log/vmware/applmgmt/backup.log | tail -5

Se vedi Backup job complete con il timestamp dell’ultimo job schedulato, il workaround ha funzionato.

Una volta confermato il corretto funzionamento, ricordati di rimuovere la snapshot della VM del vCenter, per evitare problemi di performance e di crescita del disco.

Note importanti

  • Questo è un fix manuale ai file di sistema: un futuro patch/update di vCenter potrebbe sovrascriverlo. Conserva gli originali (*.original) e documenta l’intervento.
  • La correzione permanente è inclusa in VMware Cloud Foundation / vCenter 9.1: l’upgrade a quella versione risolve il problema in modo nativo, permettendo di tornare a usare “Retain Last X Backups” senza modifiche manuali.
  • Riferimento ufficiale: Broadcom KB 428785.