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

Reply via email to