Bacula-users

Re: [Bacula-users] Status of Python api?

2015-02-27 00:53:04
Subject: Re: [Bacula-users] Status of Python api?
From: S McGraw <smcg2297 AT frii DOT com>
To: bacula-users AT lists.sourceforge DOT net
Date: Thu, 26 Feb 2015 22:44:59 -0700
On 02/26/2015 07:19 PM, Heitor Faria wrote:
>> 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.
 >
> echo "estimate job=BackupClient1 level=${Level}" |bconsole |grep -o -P 
> 'bytes.{0,16}'
>
> Just an idea: you could use a RunBeforeJob Shell Script to create the number 
> of volumes needed to complete a job. Something like that:
>
> echo "estimate job=BackupClient1 level=${Level}" |bconsole |grep -o -P 
> 'bytes.{0,16}'
>
> Then clear the bytes= from the result, divide per 4.4Gb (?) and than create 
> the needed volumes:
>
> echo "label pool=${Pool} storage=${Storage} volume=xxxx-shell-variable" 
> |bconsole
>
> The full solution requires shell script knowledge that I don't have, but I 
> think it's the closest thing to the Python script you had.
> Good luck.

That's an interesting suggestion.  I was worried the "estimate"
command might be very slow but it seemed quick enough.  Perhaps a
potential problem might be a difference between the estimate and
actual bytes, perhaps because a large file was created in the
interim.

Another possibility occurred to me prompted by your idea... again
in a RunBeforeJob script, label a fixed number of volumes (I can
put a fairly accurate upper bound on the backup data size for each
client) and after the job delete the volumes that were not used.
I'm not immediately sure the best way to determine which weren't
used but I think that won't be too hard.  I guess the risk here
is that if the after job failed for some reason, the unused volumes
would be left in the pool and would be used the next night.

I'll look into both of these ideas more next week, 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