I have now implemented the retention period settings as described in my last email. I am aware that the actual volumes do still have the old volume retention period “baked in”.
Question: At what point in the life cycle of a volume is the volume retention period updated in the volume itself to the current setting in its pool? Best, j/c > On 31. Jan 2023, at 12:59, Antonino Balsamo <a.bals...@officinapixel.com> > wrote: > > this should be correct, but let's see Ana consideration > > Il 31/01/2023 12:50, Justin Case ha scritto: >> so for the backups on tier 1 storage and the copies on tier 2 storage now >> this: >> >> • client resources: >> • file retention: 90 >> • job retention: 90 >> • tier1 pool resources: >> • volume retention 100 >> • tier 2 pool resources: >> • file retention 150 >> • job retention 150 >> • volume retention 160 >> >> correct now? is there a better solution? >> >>> On 31. Jan 2023, at 12:42, Antonino Balsamo <a.bals...@officinapixel.com> >>> wrote: >>> >>> sorry for adding some noise here but if you want to keep backup for 60 days >>> you have to add 30 days to incorporate the full back up. IE you are at 28 >>> March and want to restore files from 28 Jan, you will have to keep the full >>> backup of January, most likely first Sunday of January. >>> >>> Cheers >>> >>> Ant >>> >>> Il 31/01/2023 12:36, Justin Case ha scritto: >>>> Thanks for clarifying this, Ana, >>>> >>>> so if I wanted my tier 1 storage to keep backups for 60 days, and my tier >>>> 2 storage to keep backups for 120 days, would it be the best to set the >>>> retention periods as follows in the different resources:? >>>> • client resources: >>>> • file retention: 60 >>>> • job retention: 60 >>>> • tier1 pool resources: >>>> • volume retention 70 >>>> • tier 2 pool resources: >>>> • file retention 120 >>>> • job retention 120 >>>> • volume retention 130 >>>> >>>> Or what else would you propose? >>>> >>>> Thank you for your time and effort! >>>> j/c >>>> >>>>> On 31. Jan 2023, at 10:56, Ana Emília M. Arruda <emiliaarr...@gmail.com> >>>>> wrote: >>>>> >>>>> Hello Justin, >>>>> >>>>> Sorry for the confusion! >>>>> You are right, we recommend that *VolumeRetention is greater than or >>>>> equal to JobRetention". >>>>> >>>>> So, the Volume will never get pruned before the Job Retention has expired. >>>>> >>>>> Hope it is clear now. >>>>> >>>>> Best, >>>>> Ana >>>>> >>>>> On Tue, Jan 31, 2023 at 10:43 AM Justin Case <jus7inc...@gmail.com> wrote: >>>>> Hi Ana, see below >>>>> >>>>>> On 31. Jan 2023, at 10:16, Ana Emília M. Arruda <emiliaarr...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> Hello Justin, >>>>>> >>>>>> The problem is that you expect the Job doesn't get pruned from the >>>>>> Catalog (Job and File records deleted from the Bacula database) *before* >>>>>> the JobRetention value expires. >>>>>> If you have a lower VolumeRetention and the volume gets pruned by using >>>>>> "prune volume expired yes", your jobs will be pruned before the >>>>>> JobRetention value. >>>>>> >>>>>> And when the volume gets pruned, volstatus=Purged, it can be potentially >>>>>> reused by Bacula or truncated and the job data in the volume gets >>>>>> deleted. >>>>>> >>>>>> This is why we usually recommend: >>>>>> >>>>>> JobRetention greater than or equal to VolumeRetention >>>>> In your earlier mail you recommended the opposite: >>>>> >>>>> >>>>>> On 30. Jan 2023, at 19:02, Ana Emília M. Arruda <emiliaarr...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> I strongly recommend you to set JobRetention less than or equal to >>>>>> VolumeRetention to avoid the volume to be pruned before the Job >>>>>> Retention has expired. >>>>> Which is preferred? >>>>> >>>>> > _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
