On Sat, Jul 4, 2026 at 10:50 AM Arno Lehmann via Bacula-users < [email protected]> wrote:
> ... > > Keeping in mind that Pools are essentially for free, and Job definitions > too, what keeps you from using Copy Jobs with the PoolUncopiedJobs > selection scheme? Phil said: > > ... I imagine it amounts to much the same thing. I can think of exactly one scenario where a time-limited SQL query could be better than the 'PoolUncopiedJobs' selection method. There could be other advantages, but I am not aware of them. If the local job has a longer retention period than the cloud job, you can get to a state where nightly an old job is pruned from the cloud storage, then the original local job is promptly selected for upload to the cloud again, because it is a job in the pool which does not currently have a copy in the cloud resource. This could be even worse if the cloud storage uses any sort of object lock. This error could be fairly obvious to detect in a simple misconfiguration (local pool retention = 180 days, cloud pool retention = 90 days) Such a problem could be far more tricky to detect if the local job originally had a longer retention duration, local jobs were ran, but no copies were made of those jobs. An admin (say, myself :eyeroll:) could run a local full job while the job resource specifies the longer retention, then lower the local job's retention to a shorter value before setting up copy jobs / pools with matching retention. Because the copy pools will have shorter retention than the instance of the local job which was ran early on in the bacula installation's lifetime, the copies of the early local jobs will be pruned from the cloud storage, but kept in the local storage. Every time the copy control job is invoked while the longer-retention jobs exist on the local storage but not on the cloud storage, the jobs will be uploaded again. When the routine prune and truncate operations are ran against the cloud storage, the cloud copies of these older jobs will be deleted again, and the cycle begins anew. If object locking was enabled, as was in my case, the cloud storage usage could balloon dramatically. So for a copy job, it is very important that the retention periods used in the copy pools match those specified in the local pools. Even if you are not using object locking, this would be a waste of bandwidth and system resources. The main downside I can think of when using a time-bounded SQL query, is the risk that something has gone wrong with cloud uploads for some reason, and some older jobs which were never uploaded are not copied because the SQL query excludes them because they are too old. This could break the backup chain. If using a time-limited SQL query like suggested by Phil, I do think it could be wise to set up an admin job running an inverse query (select only jobs which are OLDER than x days), and if any are found, report the job IDs and exit 1 so the bacula admin job will show an error status to bring this situation to an admin's attention. I will reply with more information about my cloud copy jobs shortly. Regards, Robert Gerber 402-237-8692 [email protected]
_______________________________________________ Bacula-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
