Justin, I don't have answers to all your questions (really, to any of your specific questions, anyhow). I do have some thoughts, though.
Please keep in mind that compared to many on this list, I'm a bacula novice. I might get something wrong. I also haven't entirely understood the problems you're facing, so maybe some of this might sound irrelevant. Please ignore if so. However, I think there might be a few things I can help with here. 1. I know that bacula can define 3 kinds of retention: File, Job, and Volume. File retention means "how long should I keep records about these files in the catalog", NOT "how long should I keep these files in the bacula backup volumes". So if you prune file retention records you will delete information about which files are in a job, but will still be able to restore that job later. Maybe you want to save catalog space for older backup jobs. The consequences of pruning job and volume records are different. A previously used volume with no jobs in the catalog is subject to recycling and reuse. 2. There are default retention periods coded into bacula that will be used if the administrator does not specify their own retention periods. I don't know what they are, but you can look them up. I think maybe 60 days? Not sure. 3. To my knowledge, bacula stores File, Job, and Volume retention time periods in the director configuration file (bacula-dir.conf). The manual can be more specific about this, but at minimum you should be able to specify these options under either the jobdef, job, or pool resource (I think pool resource maybe can't use file retention, only job or volume retention?). Maybe you can also specify retention periods at the FD level, but I haven't used that and am not sure if it's possible or how it works. I would think that the FD probably wouldn't be able to specify, say, volume retention time since I imagine that's outside the scope of the FD. ****Retention periods specified in the pool over-ride all other retention periods!**** 4. If bacula doesn't store any file, job, or volume retention times in the catalog, it's probably to save on database space. From a programming perspective, there's no reason to store retention times in the catalog. Bacula can simply look at the relevant configuration files, check the current time/date, and then check the catalog for file, job, or volumes that are older than the specified retention period for those items. This wouldn't save a lot of database space for jobs or volumes, but file retention... oh boy. Yeah, for file retention it'd save a LOT of database space. Think of all the posix compliant time/date codes, one for every copy of a file ever backed up. Those bytes add up over millions and billions of file entries. Regards, Robert Gerber 402-237-8692 r...@craeon.net On Sun, Oct 20, 2024 at 6:15 AM Justin Case <jus7inc...@gmail.com> wrote: > I have browsed the catalog database a bit more and I saw one thing that > might explain the problem I am having, but I don't have sufficient > technical background on the Bacula implementation details of different > versions. > > I am running bacula-dir 15.0.2 and bacularis 3.1.0. The Bacula manual and > Bacularis offer “Job Retention” and “File Retention” in the pool resource, > supposedly overriding the same fields in the client resource. I am not > using these fields in the client resource, and in the client table there > are the job and file retention default values. > I am only using the job and file retention fields in the pool resources in > Bacularis. > What irritates me is that in the pool DB table there are no columns for > job and for file retention! > Are these values stored elsewhere or has my DB not been initially set up > or not correctly upgraded? > > If the pool resource retention values for jobs and files are missing in my > DB this would mean that bacula-dir is using the values from the client > resources, which is consistent with what I am seeing (with 2 exceptions): > The oldest jobs are 6 months old (job retention default value). > Exceptions: (a) catalog backup jobs go back to the date when the > installation was set up (b) two other jobs have altogether 4 instances that > are older than 6 months. > > So open questions for me are: > > (1) where are job retention and file retention stored for the pool > resource? > > (2) if in the pool table, why does my pool table not have corresponding > columns for job and file retention? How may I fix this? > > (3) why are there catalog backup jobs older than the default job retention > of 180d in my catalog, they should have been expired? > > (4) why are there 4 other job instances older than 180d? > > Bonus questions: > > (5) it seems that only jobs of types Backup, Copy Job and Copy (Migration > also? I dont use those) are pruned. Is this the correct behavior? > > (6) Is there a builtin mechanism to expire and prune Admin jobs and Verify > jobs? > > > > On 20. Oct 2024, at 12:21, Justin Case <jus7inc...@gmail.com> wrote: > > Hi Bill, > > please find my response inline below: > > On 19. Oct 2024, at 22:59, Bill Arlofski <w...@protonmail.com> wrote: > > On Wednesday, October 16th, 2024 at 06:15, Justin Case < > jus7inc...@gmail.com> wrote: > > I am wondering why I am seeing in my catalog lots of jobs older than the > JobRetention defined in the pools, and also older than the default > JobRetention assumed for the clients. > The volume recycling seems to work fine adhering to the VolumeRetention in > the pools. > > > To me it is a mystery, probably be cause I overlook some dependencies I am > not aware of. > Can someone please help me understanding this. > > > Hello Justin, > > From the rest of this thread, it appears that your prunining is working as > configured/expected. > > > I doubt that, at least no as intended. > > Where are you seeing the old jobs? bconsole? BWeb? Bacularis? > > > Bacularis. > > They could be coming from the `jobhisto` table. > > And you can prove this by querying the `job` and `jobhisto` tables and > compare the results. > > > job has all the jobs > jobhisto is empty > > Still sounds to me like job expiry not work as intended - maybe config is > wrong, but I don’t understand where the mistake is. You find the config > excerpt in my initial post. > > Can you help? > > All the best, > J/C > > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users >
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users