View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001612 | bareos-core | director | public | 2024-04-17 16:09 | 2024-04-25 14:51 |
Reporter | hostedpower | Assigned To | bruno-at-bareos | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Summary | 0001612: Allow Higher Duplicates = Yes not working | ||||
Description | Hi, 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" | ||||
Tags | No tags attached. | ||||
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 https://docs.bareos.org/Configuration/Director.html#config-Dir_Job_AllowDuplicateJobs 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. |
|
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. | |
PS: Next time I'll open on github :D | |
Before closing did you try the other duplcate parameter like https://docs.bareos.org/bareos-23/Configuration/Director.html#config-Dir_Job_CancelLowerLevelDuplicates https://docs.bareos.org/bareos-23/Configuration/Director.html#config-Dir_Job_CancelRunningDuplicates I usually go for { AllowDuplicateJobs = No CancelLowerLevelDuplicates = Yes CancelQueuedDuplicates = Yes } |
|
Parameter will be deprecated and removed. | |
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 |