vierbergenlars
commented
3 years ago Can you check the results for the following query: SELECT j.Name, j.Type, j.ClientId, j.FileSetId, COALESCE(c.Name, ''), COALESCE(f.FileSet, ''), COUNT(*), SUM(j.JobBytes), SUM(j.JobFiles) FROM job j LEFT JOIN client c ON c.ClientId = j.ClientId LEFT JOIN fileset f ON f.FileSetId = j.FileSetId GROUP BY j.Name, j.Type, j.ClientId, j.FileSetId, c.Name, f.FileSet HAVING MAX(j.SchedTime) >= '2021-07-15 00:00:00'
For my case, the first column (j.Name) (the job ID) is unique, but from the query output you posted, it looks like you have multiple different filesets for the same job name, which I did not know could happen during normal operations.
To determine how bareos_exporter can handle this situation, it would be helpful to know how this situation occured.
It looks like you were trying to get a job working, and trying to get it working. So I wonder if you modified the fileset at som
e point?
In that case, the failed jobs are just not the actual problem, but multiple rows for a job name being returned. As a quick fix, you can delete the failed jobs with delete jobid=? in bconsole. Or you can wait for 7 days (default, or the number specified with the -job-discovery-days argument) until the jobs with an obsolete fileset ID are outside the window considered by bareos_exporter.
karlism
BareOS exporter (version 0.5.6) stops working when there are failed backup jobs:
Here's database entries related to this backup job:
Judging by Prometheus
upmetric, I can see that exporter stopped working around 10:08, thus I conclude that this failure was triggered by jobid 243. I'm using BareOS 20.0.1 and PostgreSQL 13 backend database.