Bareos Bug Tracker
Bareos Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000793bareos-core[All Projects] directorpublic2017-03-06 14:472017-08-16 05:38
Reportermatthijs 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformLinuxOSDebianOS Version8
Product Version16.2.4 
Target VersionFixed in Version 
Summary0000793: Always incremental consolidate fails when no files are changed
DescriptionHi,

To our knowledge the bug reported at https://bugs.bareos.org/view.php?id=745 [^] has not been resolved yet. We can still reproduce the error consistently.

Also the answer "Individual configuration problem, solved by support" does not clarify why this bug would be a configuration problem.

Kind regards
Steps To ReproduceDirector/Job config:

Always Incremental Job Retention = 2 days
Always Incremental Max Full Age = 4 days

Steps:

Run the normal job 6 days in a row without changing any files.
On each day run the consolidate job as well.

The first time the consolidate job needs to process any files there are files from the first normal job which has been upgraded to a Full job. Therefor this time no error is given. After two more days the consolidate job reaches the max Full Age again but this time no files need to be processed because there aren't any changed files. At that moment the error occurs.
Additional InformationWe had a hard time to reproduce the issue but we managed to find the line of code from where the consolidation (virtual full) fails.

We reduced this problem to the consolidate job not needing to process any files.

In vbackup.c on line 255 you have the message 'Could not get or create the FileSet record.' which we got as a 'Fatal error'. When looking into this we see that the 'create_bootstrap_file' function returns a boolean false.

When running bareos-director in debug mode with '/usr/sbin/bareos-dir -d100 -f' we get also the following messages:
... (100): sql_get.c:1272-15 q=SELECT Path.Path, Filename.Name, T1.FileIndex, T1.JobId, LStat, DeltaSeq FROM ( SELECT DISTINCT ON (FilenameId, PathId, DeltaSeq) JobTDate, JobId, FileId, FileIndex, PathId, FilenameId, LStat , DeltaSeq FROM (SELECT FileId, JobId, PathId, FilenameId, FileIndex, LStat ,DeltaSeq FROM File WHERE JobId IN (3,5) UNION ALL SELECT File.FileId, File.JobId, PathId, FilenameId, File.FileIndex, LStat , DeltaSeq FROM BaseFiles JOIN File USING (FileId) WHERE BaseFiles.JobId IN (3,5) ) AS T JOIN Job USING (JobId) ORDER BY FilenameId, PathId, DeltaSeq, JobTDate DESC ) AS T1 JOIN Filename ON (Filename.FilenameId = T1.FilenameId) JOIN Path ON (Path.PathId = T1.PathId) WHERE FileIndex > 0 ORDER BY T1.JobTDate, FileIndex ASC
... (0): vbackup.c:508-15 Found 0 files to consolidate.
... (100): vbackup.c:373-15 Enter backup_cleanup 69 E
... (100): vbackup.c:458-15 Leave vbackup_cleanup()

The message: 'Found 0 files to consolidate.' can be found in vbackup.c at line 508.

The offending check is on line 510 where it checks the expected files and when the jcr->ExpectedFiles == 0 it returns false.

The query as seen in the output above returns 0 rows in our test.

The solution for us is now to keep the regular jobs running and when there are 'ExpectedFiles' then it will consolidate the jobs.

Hopefully this will help in resolving this issue.
TagsNo tags attached.
bareos-master: impact
bareos-master: action
bareos-17.2: impact
bareos-17.2: action
bareos-16.2: impact
bareos-16.2: action
bareos-15.2: impact
bareos-15.2: action
bareos-14.2: impact
bareos-14.2: action
bareos-13.2: impact
bareos-13.2: action
bareos-12.4: impact
bareos-12.4: action
Attached Files

- Relationships

-  Notes
(0002702)
miniskipper (reporter)
2017-08-09 06:25

Would also like to know how to solve this problem with changes of the configuration.

- Issue History
Date Modified Username Field Change
2017-03-06 14:47 matthijs New Issue
2017-08-09 06:25 miniskipper Note Added: 0002702


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker