On 2/25/22 08:05, Marcelo Slon wrote: > Hi, > > I have configured a copy job with the Selection Type = PoolUncopiedJobs > directive. > Is there a way to list the jobs that have not yet been copied before running > this job in the console or by SQL query? Where > is this information stored in the database? > > Thanks, > Marcelo Slon
Hello Marcelo, The information about copy jobs can be found in two places in the database. 1. In a job's "priorjobid' field. When a job is copied, the new (Copy) job has it's 'type' field set to 'C' (copy), and it gets the original Backup job's jobid entered into its 'priorjobid' field. You'll notice in the SQL query in Josip's email that this 'PriorJobId' field is part of the query. This is why. Since a backup Job may be copied more than one time, it is possible that more than one 'C'opy job will have the same 'priorjobid'. 2. In the Summary of a Copy 'c'ontrol job. In these Copy 'c'ontrol jobs, there will be a three extra lines dealing with JobIds: ----8<---- - Prev Backup JobId: The Backup jobid being copied - New Backup JobId: The jobid the new 'C'opy job will have - Current JobId: The current Copy 'c'ontrol job that is performing the copying ----8<---- If you have not seen it yet, the baculabnackupreport.py script I wrote takes all of this into consideration when it generates the HTML email report. You can always find the latest version here: https://github.com/waa/bacula It ties together Copy Control jobs with the Backup Job they copied, and the new Copy job it was copied to. Additionally, it shows you all the jobids that a Backup job was Copied to, and conversely, it also shows the original backup jobid that a Copy job was copied from. It does the same for Migrated jobs too. When customers start doing copy jobs and want to use the convenient "PoolUncopiedJobs" feature, I usually recommend to start by using a series of SQL queries instead. The idea is to configure the Copy job to select jobs between two old dates, then once that batch is done being copied, adjust the SQL query to the next range of dates and continue this process until the current date is reached. Then, the Copy job can be changed to use the PoolUncopiedJobs feature and only the jobs that have not been copied yet will be copied moving forward. The other suggestion I make is, create a new pool and start sending all of your backups there. Then, you can immediately start using the PoolUncopiedJobs feature since only these new jobs will need to be copied. This second idea is OK, only if it is not necessary to copy all the old jobs and you'd like to implement Copy jobs, starting now... And, for testing, just to make sure your Copy jobs are configured correctly, you can make the Copy job select just one specific jobid with the SQL query being simply: SELECT '1234' (where 1234 is the small backup job you want to test your Copy job configuration with. Hope this helps, Bill -- Bill Arlofski w...@protonmail.com _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
