View Issue Details

IDProjectCategoryView StatusLast Update
0001612bareos-coredirectorpublic2024-04-25 14:51
Reporterhostedpower Assigned Tobruno-at-bareos  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Summary0001612: Allow Higher Duplicates = Yes not working

We created a job with these properties:

JobDefs {
    Name = "FullRJob"
    Type = Backup

    Level = Full

    Client = xxx
    Write Bootstrap = "/var/lib/bareos/%c.bsr"

    Accurate = No
    Messages = Standard

    # Be careful not to start double jobs (since ran every hour by default)
    Allow Duplicate Jobs = No
    Allow Higher Duplicates = Yes

    Allow Mixed Priority = True
    Priority = 10

    Pool = R-Full

    Incremental Backup Pool = R-Incremental
    Full Backup Pool = R-Full

    Run Script {
        RunsWhen = After
        RunsOnFailure = No
        FailJobOnError = No
        RunsOnClient = No
        console = ".bvfs_update jobid=%i"

JobDefs {
    Name = "PITRJob"
    JobDefs = "FullRJob" # Use job defaults from FullRJob

    Level = Incremental

Then we have a job of type PITRJob , this job is using the postgreSQL PITR plugin from Bareos and is using this schedule

Schedule {
    Name = "pitr-cycle-standard"

    Run = Incremental hourly at 00:02 # First pick up all last changes
    Run = Full 1/3 at 23:04 # Create new full every 3 days

However this Full job is always cancelled, even when it's a "Higher Duplicate".

JobId 281517 already running. Duplicate job not allowed.

What we want is to have all last changes from the database incremental synced, and as fast as possible start a full job after that.

Say we first start the full, then the incremental, we would lose up to 1 hour of incremental data as far as I understand ...

Is there any solution for this? And why is this Higher Duplicate cancelled, it looks like bug because of this setting: "Allow Higher Duplicates = Yes"
TagsNo tags attached.




2024-04-18 17:00

manager   ~0005898

Hello, you've missed our announcement about Mantis going to be deprecated in the benefit of github issues.

I'm not sure the parameter combination you're using will work as you want
When I'm referring to I don't see any usage of "Allow Higher Duplicates"
When I'm grepping the source code for that config parameter, beside its declaration in the config code of the director, it doesn't look like it is use somewhere else.

So finally the Allow Duplicate = no win in your case.

So look like we have dead cat parameter that can be deprecated and removed.


2024-04-18 18:42

reporter   ~0005900

Hi Bruno, thanks a lot, is there any way then to accomplish what we want? Because incremental is running quite often, duplicates of the incremental must be avoided. However a full should never be missed.


2024-04-18 18:42

reporter   ~0005901

PS: Next time I'll open on github :D


2024-04-25 14:51

manager   ~0005906

Before closing did you try the other duplcate parameter like

I usually go for
  AllowDuplicateJobs = No
  CancelLowerLevelDuplicates = Yes
  CancelQueuedDuplicates = Yes


2024-04-25 14:51

manager   ~0005907

Parameter will be deprecated and removed.

Issue History

Date Modified Username Field Change
2024-04-17 16:09 hostedpower New Issue
2024-04-18 17:00 bruno-at-bareos Note Added: 0005898
2024-04-18 18:42 hostedpower Note Added: 0005900
2024-04-18 18:42 hostedpower Note Added: 0005901
2024-04-25 14:51 bruno-at-bareos Note Added: 0005906
2024-04-25 14:51 bruno-at-bareos Assigned To => bruno-at-bareos
2024-04-25 14:51 bruno-at-bareos Status new => closed
2024-04-25 14:51 bruno-at-bareos Resolution open => fixed
2024-04-25 14:51 bruno-at-bareos Note Added: 0005907