On Thu, Oct 1, 2015 at 2:41 PM, Georg Altmann <geo...@george-net.de> wrote:
> > > > On Thu, Oct 1, 2015 at 11:17 AM, Ana Emília M. Arruda > > <emiliaarr...@gmail.com <mailto:emiliaarr...@gmail.com>> wrote: > > > > Hello Georg, > > > > An unmount will not solve this for you. Maybe a Run After Job > > directive that in the case of a Job fail a script could delete the > > volume from catalog and the volume file in your archive device (if > > you're using tapes, this will be a little complicated...). This way > > another volume for the next job will be labeled correctly, but I'm > > affraid you will have a very large MediaId number in the case you > > have a large number of job failures... > > Oh, yes, my mistake again. I am only considering per job volume labeling > for file based storage. For tapes this does not make sense of course. > Using a Run Before directive, I could mark a mounted volume used and > this would trigger a new volume to be labeled, right? > Well, you mean use a Run After Job directive (with Runs On Failure set to yes) to mark the volume as Used. Yes, this should work. I would take care with this since it is possible that lots of unused volumes will occupy your catalog. > If a job writes to a volume this is already covered by max volume jobs > =1. So far this has worked fine, with the exception of failed jobs. > In the case of failed jobs, the job do not write anything into the volume. So the volume remains in append status. > > > > > > You can also have a few pools and your volume labels without > > client/date/job information. Bconsole have a few commands very > > usefull to find out where is specific data for a job/client or > > whatever you are looking for. The restore command lets you choose > > some ways to find out what you want to restore. There is also a > > "query" command with some useful SQL queries and you can have your > > own queries too. You can formulate them and include in the query.sql > > file. > > Yes, I know this, but AFAIK this does not apply in a disaster recovery > situation where you have to scan volumes with bscan. > In this situation I figure it would be very useful to find the last > backups of the catalog and the bacula server to feed them to bscan. > With large volumes bscan will sit there for a long time, scanning all > volumes. > > > Regars, > Georg > > -- > PGP-Key: 0x1E320E65 > D150 7783 A0D1 7507 1266 C5B3 BBF1 9C42 1E32 0E65 > > I don't like the idea of secret agencies to analyse and archive > personal communication. GnuPG is available as open source, free as as in > freedom, as a countermeasure. I use http://www.enigmail.net/ for Mozilla > Thunderbird. If you can, please use a frontend of your choice to send me > encrypted e-mail. See http://www.gnupg.org/ for an overview. > >
------------------------------------------------------------------------------
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel