Arno Lehmann wrote: > Hi, > > 23.08.2007 10:41,, Maria McKinley wrote:: > >>Arno Lehmann wrote: >> >>>>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. > > > Good, so not wanting to restore the whole job is understandable. > > >>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... > > > Good point. The manual might need an update then. > > (Of course, the fact that I, too, would do this using bscan does not > necessarily mean there aren't better solutions... but as no one > intervenes, I'll assume no one knows :-) > > The manual is written with a perfect setup and perfect and stable > operations in mind, where you never notice afterwards that a different > configuration would have been better later. At least that's what I > assume ;-) > > Reality always interferes with long-term projects like data storage, > so I think it's more or less normal to find yourself in need of job > files after they were purged. Just don't believe that the manual > describes all the things that can possibly go wrong :-) > > ... > >>>>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. > > > Now I see your point, thanks. > > My answer is that this is an artifact of the way Bacula was developed, > i.e. a smooth user interface wasn't one of Kerns top priorities (until > recently). > > the llist commands give rather simple but - sometimes - vital > information about objects. The queries handle the more complex stuff, > but for easier development and simple modification, they are invoked > differently. > > At least that's what I assume and observe and Kern might explain > things completely different. > > Arno > > > >>thanks again, >>maria >> >> >>>Arno >>>
Thank you Arno for being patient and explaining stuff. I now have a much better handle on what I want from my configuration, how to get it, and how to deal with stuff like this in the future. And maybe this thread will help others too. cheers, maria ------------------------------------------------------------------------- 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
