 |
It seems that Bareos MySQL database return zero on statement ld4-bar-dir-01 (15): bvfs.c:798-0 q=SELECT 'F', T1.PathId, T1.FilenameId, Filename.Name, File.JobId, File.LStat, File.FileId FROM Job, File, ( SELECT MAX(JobTDate) AS JobTDate, PathId, FilenameId FROM ( SELECT JobTDate, PathId, FilenameId FROM File JOIN Job USING (JobId) WHERE File.JobId IN (17925,28325) AND PathId = 0 UNION ALL SELECT JobTDate, PathId, FilenameId FROM BaseFiles JOIN File USING (FileId) JOIN Job ON (BaseJobId = Job.JobId) WHERE BaseFiles.JobId IN (17925,28325) AND PathId = 0 ) AS tmp GROUP BY PathId, FilenameId LIMIT 2000 OFFSET 0) AS T1 JOIN Filename USING (FilenameId) WHERE T1.JobTDate = Job.JobTDate AND Job.JobId = File.JobId AND T1.PathId = File.PathId AND T1.FilenameId = File.FilenameId AND Filename.Name != '' AND File.FileIndex > 0 AND (Job.JobId IN ( SELECT DISTINCT BaseJobId FROM BaseFiles WHERE JobId IN (17925,28325)) OR Job.JobId IN (17925,28325)) With "PathId = 0", the statement always returns null value. |
|
|
Shodan your note is in the wrong ticket i guess? |
|
|
I had a look at the vbackup code and it seems this is by design. e.g. it copies back the data from the last previous Job e.g. /* * Update final items to set them to the previous job's values */ Mmsg(query, "UPDATE Job SET StartTime='%s',EndTime='%s'," "JobTDate=%s WHERE JobId=%s", jcr->previous_jr.cStartTime, jcr->previous_jr.cEndTime, edit_uint64(jcr->previous_jr.JobTDate, ec1), edit_uint64(jcr->JobId, ec2)); |
|
|
The timestamps need to be set to the ones of the last backup that was consolidated, as the new Full Backup can be the base for incremental or differential backups. In order to not skip files that were created between the last backup that was consolidated and the virtual full backup run itself, the timestamp needs to be set as it is being set. |
- Anonymous
