In looking at doing this out of band (not pruning feature) I've run into
a tracking snag. We tend to purge volumes manually after a year when we
want to reuse them, but it looks like purging volumes does not change
the PurgedFiles column in the Job table for the Job's that have had
their Files Purged. It appears that only happens if the Files are
purged at the Job level.
Can anyone confirm that is expected behaviour?
I may need to purge all the Jobs on a volume, before I purge the volume,
in order to get the flags set properly, so that I can more easily track
which Job's have had their Files purged and which have not.
Stephen
On 04/11/2018 06:25 AM, Stephen Thompson wrote:
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.
Stephen
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,
Kern
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.
Ideas?
thanks,
Stephen
--
Stephen Thompson Berkeley Seismo Lab
step...@seismo.berkeley.edu 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, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
