Progress Backup wrong value

[marcos-lazaro]

Hey man, all right?

I noticed that the itens 'Progress Backup' values are all like 100% even with jobs running.

I performed a query directly in SQL and the values are in line with what is shown in Veeam, but in the script\zabbix all items return 100%.

[aholiveira]

Hello,
Once a backup is finished (to completion) the progress is always 100 (zabbix will keep collecting that data even when the backup job is done).
Also, bear in mind that Zabbix is polling the database every 5 minutes or so for values, so if a backup job starts and finishes between two consecutive polls Zabbix will also not see any progress.
You can check:

• The values you are getting on Zabbix during the job execution window (check history data)
• Table Backup.Model.JobSessions has all the sessions for all the backup jobs, while on the script it only checks for the last execution of each job. If a job session is interrupted before it reaches 100% Veeam will have an entry for that interrupted entry on the table (with a progress less than 100) but Zabbix might not "see" it (depending on how long the job ran for). We cannot see the job ID column on that screeshot, so it's not possible to check if they are different executions of the same job or different jobs.
• Only a few job types are supported by the script/template because Veeam's behaviour is a little bit different in some other job types. Make sure that the data you are looking at in the database is for those supported job types (again, we only have the progress column there, so there's no way to confirm).

Hope this helps.

Regards.

[dchronis]

Hello,
i also get progress 100 for all jobs of all supported types (Backup, replication).
i run a query on Table Backup.Model.JobSessions for a job that gets hours to finish and the progress is presented correctly but the script returns 100 to zabbix.

[dchronis]

It seems that the sorting on Get-JobInfo() is not correct. It returns correct results when the jobs are not running but does not return the running job because the end_time on running jobs is 1900-01-01.00.00.00.
I tested with changing the sort-object in line 319 from end_time to creation_time and it fixes the issue. Not sure if it breaks something else.