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...
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. Best regards, Ana On Thu, Oct 1, 2015 at 10:52 AM, Georg Altmann <geo...@george-net.de> wrote: > Hello Ana, > > that makes perfect sense. I overlooked this. Thanks for clearing it up! > > My intention here is to ease the search for a recent backup in a > emergency / recovery situation with bacula command line tools. Maybe I > can force a volume umount with a Run Before Job directive. > > Creating a separate pool for each client or job seems to cause a lot of > maintenance work and complicates the setup a lot. I don't think this is > a good solution. > > Regards, > Georg > > Am 30.09.2015 um 18:45 schrieb Ana Emília M. Arruda: > > Hello Georg, > > > > IMHO, this is not a bug, but the expected bacula behaviour. > > > > Before running a job, bacula tries to reserve a volume (according to its > > volume recycling algorithm). If it did not find one, it labels one. If > > the job fails, the volume will be in the pool available for other jobs > > that uses this pool for its backups. > > > > I particularly do not like base a volume label in a job or date if it > > can be used/recycled by other jobs in any other moments. If you want to > > have specific volumes to be used by specific jobs/clients, I would > > recommend you to have specific pools for these clients/jobs. > > > > Best regards, > > Ana > > > > On Wed, Sep 30, 2015 at 1:14 PM, Georg Altmann <geo...@george-net.de > > <mailto:geo...@george-net.de>> wrote: > > > > Hi, > > > > > > there seems to be a problem with variable expansion in > Pool/LabelFormat > > after failed jobs. I randomly get expansions that do not have the > > expected value. > > > > Pool { > > Name = Disk3Pool > > Pool Type = Backup > > Recycle = no > > AutoPrune = Yes > > Volume Retention = 500 years > > Maximum Volume Jobs = 1 > > Label Format = > > > > "disk3-${Disk3VolNum+:p/6/0/r}-${Year}-${Month:p/2/0/r}-${Day:p/2/0/r}-${Job}-${Level}" > > } > > > > >From the log, with expected volume name: > > > > Build OS: x86_64-unknown-linux-gnu archlinux > > Job: gurke-arch-linux.2015-09-30_17.17.01_08 > > Backup Level: Incremental, since=2015-09-15 08:55:26 > > Client: "gurke-arch-linux-fd" 7.0.5 (28Jul14) > > x86_64-unknown-linux-gnu,archlinux, > > Pool: "Disk3Pool" (From Job resource) > > Volume name(s): > > disk3-000616-2015-09-30-gurke-arch-linux-Incremental > > > > But then the label is often incorrect / unexpected: > > > > Job: BackupCatalog.2015-09-30_17.17.01_16 > > Backup Level: Full > > Client: "gurke-arch-linux-fd" 7.0.5 (28Jul14) > > x86_64-unknown-linux-gnu,archlinux, > > FileSet: "Catalog" 2011-11-13 17:21:08 > > Pool: "Disk3Pool" (From Job resource) > > Volume name(s): > > disk3-000618-2015-09-30-georgtp-arch-Incremental > > > > Another incarnation of the same job with correct volume label: > > > > Job: BackupCatalog.2015-09-15_08.55.24_39 > > Backup Level: Full > > Client: "gurke-arch-linux-fd" 7.0.5 (28Jul14) > > x86_64-unknown-linux-gnu,archlinux, > > FileSet: "Catalog" 2011-11-13 17:21:08 > > Pool: "Disk3Pool" (From Job resource) > > Volume name(s): > > disk3-000615-2015-09-15-BackupCatalog-Full > > > > > > This problem seems to occur when a previous run job fails. In fact > the > > unexpected label > > disk3-000618-2015-09-30-georgtp-arch-Incremental > > for the job > > BackupCatalog.2015-09-30_17.17.01_16 > > would have been the correct label for the first of two failed jobs > that > > were scheduled before BackupCatalog: > > > > Job: georgtp-arch.2015-09-30_17.17.01_12 > > Backup Level: Incremental, since=2015-09-15 09:12:20 > > Client: "georgtp" 7.0.5 (28Jul14) > > x86_64-unknown-linux-gnu,archlinux, > > Volume name(s): > > Volume Session Id: 3 > > Volume Session Time: 1443626168 > > Last Volume Bytes: 0 (0 B) > > Non-fatal FD errors: 1 > > SD Errors: 0 > > FD termination status: Error > > SD termination status: Waiting on FD > > Termination: *** Backup Error *** > > > > Notice the empty Volume name field. > > > > So it seems as if the volume label for a failed job remains in some > kind > > of queue of buffer that is then incorrectly used for a following job. > > > > Can anybody confirm this? > > I did not find a bug report in mantis. May this have been fixed with > > 7.2? > > > > I am running bacula 7.0.5 on Arch Linux: > > % pacman -Q |grep bacula > > bacula-bat 7.0.5-1 > > bacula-common 7.0.5-1 > > bacula-console 7.0.5-1 > > bacula-dir 7.0.5-1 > > bacula-dir-postgresql 7.0.5-1 > > bacula-fd 7.0.5-1 > > bacula-sd 7.0.5-1 > > > > > > Regards, > > 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 > > <mailto:Bacula-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/bacula-devel > > > > > > -- > 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
