Arno Lehmann wrote: > Hi, > > 23.08.2007 01:18,, Maria McKinley wrote:: >> <snipped a bit> > ... snipped some more bits ... >>>> I'm a bit confused as to why you would ever need to >>>> change things in the dir config file, if the volumes still show up in >>>> list volumes. >>> In your case, just to ensure the job files are not pruned. >>> >>> Arno >>> >>> >> Thanks a bunch Arno. Unfortunately, I'm still a bit confused. Doesn't >> the fact that the restore command comes up with zero files mean that the >> job files have already been pruned > > Yes, that's what this means. > > (By the way - you could restore the complete job now, it's only > impossible to select files now.) > >> or do you just mean to ensure the job >> isn't pruned? > > That was included in my original proposal, but it doesn't apply to > your situation. > >> I was confused earlier on the distinction between the job >> and the files, and I think I mispoke. I have the job still, but not the >> files. This does bring up an interesting question. From what you said >> earlier I got the idea that if you have the job info, and know the >> volumes you need, you could get the job files back without too much >> trouble using bscan. > > No need to use bscan, you can restore the whole job. >
Thanks Arno, once again very helpful, and I think I am just about there. My problem is that the whole job is probably close to 300 GB, and I really just want a small chunk. I should be able to do this if I use bscan first, I think, and it will essentially just re-create the old file list. It is a bit confusing, because the manual seems to assume that if you want to use bscan it is because you have screwed up your database, rather than just trying to restore really old files from backup where the file list doesn't exist in the database anymore. Which sort of makes me feel like I am going about this wrong... >> Well, I guess I'm about to find out. Long term >> though, if my interpretation of the situation is correct, I think what I >> would like to be able to do is have at least the job info around as long >> as the corresponding volumes are around. > > No problem, just set your retention times accordingly, i.e. the jobs > need a retention time longer than the volumes. Thus, the jobs will > only be purged from the catalog when the volumes expire and are pruned. > >> I assume that it is not pruning >> files that causes the database to grow out of control, > > That's usually a correct assumption :-) In all the installations I > know, the table holding the files is by far the biggest one, and I > have problems imagining a setup where this would be different. > >> and that the job >> info (were talking saving one job a month, and after 6 months, 4 jobs a >> year) shouldn't be too bad. I have plenty of space. So, if this is >> correct, is there a way to tell bacula to hold on to job directives as >> long as the corresponding volumes are around? > > See above - retention times are the key here. > >> Btw, is there a reason >> that the volume names aren't included in the job info? > > I don't know what info you refer to, but you can use a query to find > the volumes for a specified job. > I just meant that when you do "llist jobid=123", it doesn't list the volumes that are associated with that particular job. (Or at least in the older bacula version, I'm having difficulties getting my new bacula director restarted at the moment.) Just seemed odd to me it wasn't there. thanks again, maria > Arno > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
