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.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
