Thanks Kern.

I think given the limited nature of his need, I may use a postrun script to simply wipe database records out of band.

Also if I did use multi-client definitions, I would need to use the same pool as they all go to the same monthly tapes.


On 4/10/18 11:59 PM, Kern Sibbald wrote:
Hello Stephen,

What you are asking for, as you suspect, does not exist and implementing it would be a bit problematic because every Job would need to keep it's own retention period.  For one client, there can be any number of Jobs -- typically thousands.  Thus the catalog would grow faster (more data for the File table having the most records), and the complexity of pruning including the time to prune would probably explode -- probably thousands of times slower.

I have never used two Client definitions to backup the same machine, but in principle it would work fine.  If you name your Clients appropriately it might be easier to remember what was done.  E.g. Client1-Normal-Files, Client1-Archived-Files, ... Also, if you put clear comments on the resource definitions, it would help.  Note two things, if you go this route:

1. Be sure to define each of your two Client1-xxx with different Pools with different Volume retention periods 2. I would appreciate feedback on how this works -- especially operationally

Best regards,

PS: At the current time the Enterprise version of Bacula has a number of performance improvements that should significantly speed up the backups of 50+million files.  It does this at a small extra expense (size) of the catalog.

On 04/07/2018 06:21 AM, Stephen Thompson wrote:

I believe the answer is no, but as a happy bacula user for 10 years I am somewhat surprised at the lack of flexibility.

The scenarios is this:  A fileserver (1 client) with dozens of large (size-wise) filesystems (12 jobs), but a couple of those filesystems are large (filecount-wise).  We would really like to set different file retention periods on those high-filecount jobs (50+million), because they are forcing the Catalog to go beyond our size constraints. However, we also don't want to lose the file retention longevity of that client's other jobs (5 years).  The only hack I can think of is to define 2 clients for 1 actual host, but I'd rather not go down that route, because tracking jobs and associating them, especially over multiple years, will get that much more tricky.



Stephen Thompson               Berkeley Seismo Lab    215 McCone Hall
Office: 510.664.9177           University of California
Remote: 510.214.6506 (Tue)     Berkeley, CA 94720-4760

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Bacula-users mailing list

Reply via email to