>>>>> On Thu, 13 Dec 2007 11:40:59 +0100, Kern Sibbald said: > > > > > > [...] > > > If you want to trigger pruning, you will need to use the prune command. > > > Then you can check with the status command. > > > > I found some references regarding the 'list nextvol' command on the user > > list. This command still purges volumes as the 'status dir' command did > > before. This is fine for me, I'm just wondering if this is still the > > desired behaviour now that 'status dir' doesn't purge volumes in 2.2.x? > > Yes, thanks for pointing this out. I had forgotten about that command when I > was answering you. Yes, it does prune, and I think it is appropriate for it > to prune (though this could be a point of discussion) because you are > explicitly asking what the next volume will be. > > One thing that I have noticed and have been tracking is that since I modified > the pruning algorithm when Bacula is looking for a Volume (i.e. the SD asks > for the next volume) so that it does a minimum pruning, and since I modified > the status command not to prune (correct behavior IMO), my databases have > been growing. This is explained by the fact that there is no longer any > Bacula mechanism that "automatically" forces pruning. > > Within Bacula's philosophy of keeping everything as long as possible (which > was by the way, not previously the case), this is correct behavior. However, > it does mean that there are a lot of records in databases that are expired > and are not pruned. Some users have complained that this is not logical, but > within the Bacula design it *is* logical and the desired behavior. > > The problem I have is that there are probably some of you out there (like > myself) who might want Bacula to more strictly adhere to the retention > periods that you have setup. In principle, there is the "prune" command that > does this, but at the moment, that needs to be manually done -- i.e. there is > no fully automatic way to get Bacula to keep the database fully pruned to the > retention periods ... > > I'm thinking about how to resolve this but have not yet found a solution that > I consider ideal (some way of doing it via a directive or script within an > Admin Job). In the mean time, I suggest that you all monitor your databases > if you are running 2.2.x and if it is growing larger than you want, either > you schedule a job that explicitly does a prune command or does a "list > nextvol" command. > > I'll probably have more on this subject once I have had a bit more time to > investigate all the angles ...
Another angle is per-job configuration for pruning of the jobs and files. Currently this is not possible because the Job Retention and File Retention is part of the client config, so it gets applied to all jobs for that client. For example it would be useful if you want to make a job for archiving unused files and keep the catalog information about that job forever. __Martin ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
