View Issue Details

IDProjectCategoryView StatusLast Update
0001065bareos-core[All Projects] directorpublic2019-03-13 19:15
ReporterUnoriginalAssigned Toarogge 
PriorityhighSeverityminorReproducibilityN/A
Status closedResolutionreopened 
PlatformLinuxOSUbuntuOS Version16.04
Product Version17.2.4 
Target VersionFixed in Version 
Summary0001065: Bareos is not relabelling recycled volumes
DescriptionMy backup strategy consists of Bareos for local backups and cloud storage for offsite backups. I use an external program to select files based on a wildcard search using their filename to determine which to upload to the cloud. This follows best practice of having a 321 backup strategy.

I have three pools for backups; daily, weekly and monthly all with their own individual retention settings. These pools have the following label formats:
Label Format = "$JobId-$Day$Month$Year-DInc-$Client"
Label Format = "$JobId-$Day$Month$Year-WFull-$Client"
Label Format = "$JobId-$Day$Month$Year-MFull-$Client"

As per the Bareos documentation, 17.3.3 Recycling Algorithm (http://doc.bareos.org/master/html/bareos-manual-main-reference.html#QQ2-1-461), it states the following: After all Volumes of a Pool have been pruned (as mentioned above, this happens when a Job needs a new Volume and no appendable Volumes are available), Bareos will look for the oldest Volume that is Purged (all Jobs and Files expired), and if the Recycle = yes for that Volume, Bareos will relabel it and write new data on it.

I am not experiencing the documented process for relabelling volumes that are marked as recycled. Instead I have experienced that the volume that is marked as recycled will be recycled however will its label will remain the same as when the volume was first created. This creates the following issues for me:
- Volumes may not have the same clients' backup or a differing job as the labelled volume causing confusion
- I cannot confidently copy these volumes to the cloud due to this

The configuration for one of the pools is as follows:

Pool {
        Name = "Daily-Incremental"
        Pool Type = Backup
        Recycle = yes
        AutoPrune = yes
        Volume Retention = 14 days
        Maximum Volume Jobs = 1
        Label Format = "$JobId-$Day$Month$Year-DInc-$Client"
}

It is my opinion that from the documentation, the fact that unique label names can be specified using variable expansion, and the fact that volumes can be set to only have one job one could be forgiven for thinking that Bareos will relabel recycled volumes using the defined label format used within the pool configuration.

As a result the only way I can ensure that each job labels the volume as per the documentation is to set each pool not to recycle any volumes. This then creates issues in itself whereby volumes are not removed from the catalogue or from storage. There are, of course, ways to get around this by involving scripting outside of Bareos however this goes against the documentation and what it states Bareos should be doing by default for volumes marked as recycled.
Steps To ReproduceDefine a pool in the following format:
Pool {
        Name = "Daily-Incremental"
        Pool Type = Backup
        Recycle = yes
        AutoPrune = yes
        Volume Retention = 14 days
        Maximum Volume Jobs = 1
        Label Format = "$JobId-$Day$Month$Year-DInc-$Client"
}

This will create a volume with the label 1-03032019-DInc-Client once the first job runs.

Once the volume retention period for that pool has been exceeded volume 1-03032019-DInc-Client will be recycled for use by another job, as per the documentation it should then be relabelled as 15-18032019-DInc-Client, however the label will remain as 1-03032019-DInc-Client however will contain job 15.
Additional InformationPriority has been set to high because this issue is preventing external backup and to workaround the issue I have had to set volumes not to recycle which can cause issues with storage running out of space unless external scripting is employed to manage the situation.
Tagslabel, labelling, recycle, recycled, recycling, relabel, volume
bareos-master: impact
bareos-master: action
bareos-18.2: impact
bareos-18.2: 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

Activities

arogge

arogge

2019-03-13 18:23

developer   ~0003281

Where does it say that recycling does apply the label format? The docs clearly state that "If the volume is reused, it is relabeled with the same Volume Name".
The docs for Label Format are quite clear, too: "The format directive is used as a sort of template to create new Volume names during automatic Volume labeling."

Also, for support requests please use the bareos-users mailinglist (https://groups.google.com/forum/#!forum/bareos-users) or open a support ticket if you have a support contract.
Thank you!
Unoriginal

Unoriginal

2019-03-13 18:54

reporter   ~0003287

Where does it say that recycling does apply the label format?
It says this at the link I provided (http://doc.bareos.org/master/html/bareos-manual-main-reference.html#QQ2-1-461) section 17.3.3 - "After all Volumes of a Pool have been pruned (as mentioned above, this happens when a Job needs a new Volume and no appendable Volumes are available), Bareos will look for the oldest Volume that is Purged (all Jobs and Files expired), and if the Recycle = yes for that Volume, Bareos will relabel it and write new data on it."

Specifically "if the Recycle = yes for that Volume, Bareos will relabel it and write new data on it."

I can see where it says "If the volume is reused, it is relabeled with the same Volume Name" which is directly above where I am referencing.

Either way the documentation contradicts itself.

This wasn't a support request. This was a bug filing due to the documentation advising "if the Recycle = yes for that Volume, Bareos will relabel it and write new data on it." as this wasn't what I was experiencing; therefore a bug.
arogge

arogge

2019-03-13 19:15

developer   ~0003288

I'm sorry that your expectation was not met, but I cannot see any contradiction here.

The documentation can always be improved, so feel free to provide a patch for the documentation making the behaviour more clear.

Issue History

Date Modified Username Field Change
2019-03-03 21:56 Unoriginal New Issue
2019-03-03 21:56 Unoriginal Tag Attached: label
2019-03-03 23:37 Unoriginal Tag Attached: volume
2019-03-03 23:37 Unoriginal Tag Attached: recycling
2019-03-03 23:37 Unoriginal Tag Attached: recycle
2019-03-03 23:37 Unoriginal Tag Attached: labelling
2019-03-03 23:37 Unoriginal Tag Attached: relabel
2019-03-03 23:37 Unoriginal Tag Attached: recycled
2019-03-13 18:23 arogge Assigned To => arogge
2019-03-13 18:23 arogge Status new => closed
2019-03-13 18:23 arogge Resolution open => no change required
2019-03-13 18:23 arogge Note Added: 0003281
2019-03-13 18:54 Unoriginal Status closed => feedback
2019-03-13 18:54 Unoriginal Resolution no change required => reopened
2019-03-13 18:54 Unoriginal Note Added: 0003287
2019-03-13 19:15 arogge Status feedback => closed
2019-03-13 19:15 arogge Note Added: 0003288