On 02/26/2015 03:08 PM, Heitor Faria wrote:
>>>>> [...] I was auto-labeling the volumes for each job like:
>>>>> xxx-1.bac, xxx-2.bac, xxx-<n>.bac, etc where <n> starts at 1
>>>>> for each job. Is there some variable that has that behavior?
>>>>> [...]
>>>
>>> Hey Mr. McGraw: you should try LabelFormat =
>>> "xxx-${NumVols}.bac" What is xxx? If is the client name you can
>>> uses ${Client}. You could check all Bacula Variables via Google:
>>> http://www.bacula.org/5.2.x-manuals/en/misc/misc/Variable_Expansion.html
>>
>> Thanks for that suggestion. I read the Variable Expansion
>> chapter many times but interpreted "current number of Volumes in
>> the Pool" as being a fixed number for a pool with a large number of
>> pre-labeled volumes.
>>
>> I just tried using NumVols but the number it produced was 5177. I
>> guess was wrong about the pre-labeled part but it does seem to be
>> total number of volumes in the pool and not a number for the
>> volumes used in the current job so far which is what I need.
>
> 1. Sorry for misunderstanding it. I really don't see the need of
> associating volumes names with their jobs and it can be very messy
> when they are recycled, since a Job can take a variable amount of
> volumes and Bacula already provide that association (e.g: list
> jobmedia, restore job..., etc.).
I agree it is messy (I would say unworkable) when recycling is
used but I don't do recycling.
I backup to smaller-than-DVD sized disk volumes and write those
to DVD. In such an environment, volume recycling is pointless.
All post-bacula handling (write to DVD, off-siting, moving
storage locations around to fit varying storage needs/capacities,
etc) are done by hand or with the help of scripts since Bacula
provides no support for DVD as a storage medium. I find it
easier to manage those tasks when I can look at filename and
be able to determine information about what is in the volume
than to have to go though a level of indirection for that information,
either by asking Bacula or querying the catalog database directly.
And of course the current labeling scheme is baked into the
scripts that I have to help with the post-bacula volume management.
I've been using the current labeling scheme successfully for
5 years, including disaster recovery simulation so I don't see
a strong reason to change now unless I have to.
> 2. Anyway I'm on a deadlock here: if you submit all jobs for a same
> pool you can't guarantee the job will occupy only the volumes with
> respective name on it, and a more secure way would be have them in
> different pools, where ${NumVols} would work if you are recycling
> them.
Yes, I have a separate pool for each client machine.
> 3. You could use variables like ${JobId} plus time (Month, Day, Hour,
> Minute, Second) in order to create unique volume names in a
> chronological order, similar to what you want, providing that you are
> always are creating new volumes for each job.
Yes, that was my fallback plan if I couldn't get a volume number.
My 2nd level fallback was to give up and just use VOL0001, VOL0002,
etc and live with the inconvenience of having the post-bacula
tools query the catalog database for info rather than getting
it from the filenames.
> However the volume
> contains important statistic data like error / mount times, and you
> would be giving up on that if always creating new ones instead of
> recycling them.
Important statistics for tape volumes, meaningless for disk
volumes.
For now, using per-pool counters and restarting the director
each night right before the backups start seems to be a usable
if un-aesthetic work-around. I will think about your comments
and ponder if it might be worthwhile to rethink the way I am
doing backups. Thanks.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
