Thanks for that advise. I'll adjust the retentions and see if I can achieve what you described. Provided I make sure the full backups definitely run every month, this should be an adequate solution.
Thanks.
> Date: Sat, 30 Jul 2011 23:07:51 +0400
> From: flatworm AT users.sourceforge DOT net
> To: gmjs AT hotmail.co DOT uk
> CC: drescherjm AT gmail DOT com; bacula-users AT lists.sourceforge DOT net
> Subject: Re: [Bacula-users] FW: Pruning/Purging and Volume Retention
>
> On Sat, Jul 30, 2011 at 06:34:47PM +0100, Graham Sparks wrote:
>
> > It's a real shame that the pruning takes effect across pools. If it
> > only affected volumes in the same pool as the job, and didn't happen
> > if the job failed (I think the latter's the case anyway), that would
> > be great for cases where the client may not always be accessible.
> Well, I think I see this situation from a different angle.
> Job/file retention period is supposed to keep your catalog from
> overgrowing, but there are other ways of pruning job and file records.
> For instance, you can set job/file retention periods for your client
> higher than the volume retention period on the pool(s) used to back up
> that client--in this case the file/job records will only be pruned when
> Bacula will "expire" a volume in a pool, when needed.
> If you're backing up to a pool with a fixed number of voulmes, you can
> even set the
> Purge Oldest Volume = yes
> on that pool which will unconditionally zap file/job records bound to
> the oldest volume in the pool when Bacula will need a fresh one. If
> job/file retention periods for your client will be greater than a
> typical lifetime of a volume in the pool this client is backed up to,
> the lifetime of the file/job records will be effectively controlled by
> expiration of the volumes in that pool.
>
