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 >> > > ------------------------------------------------------------------------- > 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 -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- 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
