 |
For anybody else that may be facing this issue, I wrote a shell script that I run in an admin job after running consolidate that changes the newly 'promoted' backups to copies. Note in the script below that the pool where the copies reside is named 'FileCopy'. Here's the content ... #!/bin/bash # grab the database credentials from existing configuration files catalogFile=`find /etc/bareos/bareos-dir.d/catalog/ -type f` dbUser=`grep dbuser $catalogFile | grep -o '".*"' | sed 's/"//g'` dbPwd=`grep dbpassword $catalogFile | grep -o '".*"' | sed 's/"//g'` # Make sure all DR-Copy jobs that are in the FileCopy pool are properly set in the database as Copy (C) jobs. /usr/bin/mysql bareos -u $dbUser -p$dbPwd -se "UPDATE Job J SET J.Type = 'C' WHERE J.Type <> 'C' AND EXISTS (SELECT 1 FROM Media M, JobMedia JM WHERE JM.JobId = J.JobId AND M.MediaId = JM.MediaID AND M.MediaType = 'FileCopy');" |
|
|
I can confirm this issue still exists and is not documented as a limitation in 18.2.5 As far as can tell this directly conflicts with: https://docs.bareos.org/TasksAndConcepts/AlwaysIncrementalBackupScheme.html |
|
|
This can be worked around as described in https://docs.bareos.org/TasksAndConcepts/AlwaysIncrementalBackupScheme.html#virtual-full-jobs "To make sure the longterm Level (Dir->Job) = VirtualFull is not taken as base for the next incrementals, the job type of the copied job is set to Type (Dir->Job) = Archive with the Run Script (Dir->Job)." If you think the documentation needs a change to document this better, feel free to suggest something. Otherwise I'd like to close this issue. |
|
|
@arogge - The issue I have reported here is different. I do have VirtualFull backups configured for long term archiving and I do set those VirtualFull jobs to Archive via script as described in your reference link. The issue that I am describing is specific to Copy jobs. I prepare an offsite copy every night of each of the day's backups to allow me to perform an accurate recovery in the event of a complete site disaster. The problem that I've described is that when a primary AI job is consolidated and removed from the catalog, Bareos promotes the copy job to a primary job. On the next cycle that new 'primary' (used to be copy) job is consolidated again. Once that new 'primary' (used to be copy) job is consolidated it will get deleted from the catalog, making my offsite copies incomplete ;-0 |
|
|
The term copy here is misleading. For your purpose, you want to do a copy but then this one needs to be similar to what virtual full is, an archive, so it never interfere with AI |
- Anonymous
