Steve Costaras wrote:
> 
> On 01/28/2010 06:10, Dan Langille wrote:
>> Steve Costaras wrote:
>>> On 01/27/2010 22:37, Phil Stracchino wrote:
>>>> On 01/27/10 22:32, Steve Costaras wrote:
>>>>> On 01/26/2010 22:34, Dan Langille wrote:
>>>>>> Issue the run command.  Use the mod option, then alter the job
>>>>>> parameters to suit.
>>>>>>
>>>>>> What do you mean by NEVER match?  You're running the Job, and 
>>>>>> altering
>>>>>> the items on the fly.  It's still the same job.  It is the Job Name
>>>>>> that counts here.
>>>>> So then I am a bit confused as to why bacula hints at having a Client
>>>>> field and a Name field in the Job resource.  I'll give this a try as
>>>>> from what you're saying that's how it's coded.   However to me this
>>>>> looks like just wasteful duplication.   If the job name is an index 
>>>>> and
>>>>> the client name is an index to the same data (won't even go into the
>>>>> file set being an index that I found out before) then why have both 
>>>>> (job
>>>>> name&  client)?
>>>> Uhhh ...  No.  Creating different jobs (and therefore different
>>>> schedules, if you think about it) for every level of every client's
>>>> backups would be wasteful duplication.
>>>>
>>>> I think you'll agree that the Name field needs to exist in the Job
>>>> record so that the Director can tell one job from another.  The Client
>>>> field is needed so that Bacula knows which client it's supposed to back
>>>> up.  I'm baffled as to how you think Bacula could possibly operate if
>>>> jobs had no name to distinguish them and didn't specify which client
>>>> they were supposed to operate on.
>>>>
>>> No, I was suggesting that if you only had one job per client (i.e. 
>>> both job name and client in the job resource) then the job name and 
>>> client would be the SAME that seems to be duplication.
>>>
>>> job {
>>>   name "client1"
>>>   client "client1"
>>> }
>>>
>>> is duplication you could just do
>>>
>>> job {
>>>   client "client1"
>>> }
>>>
>>> for the same effect.   Why have both name & client?
>> For starters, one reason: so you *can* have more than one Job per Client.
>>
> 
> And that brings this full circle.   That's what I did have (multiple 
> jobs per client) however when you do that each time you run a different 
> job there does not appear to be any logic to track that it's for the 
> same client so you get upgraded to fulls for each job of a different 
> name (and the reason for this thread.  ;)  )   So if you are supposed to 
> be able to do that, then there's something amiss.  From what I am seeing 
> it does not appear to work that way.

Steve: If you have two jobs for the same client, each with the SAME 
FileSet, they are still DIFFERENT Jobs.  Hence, Bacula treats them as 
individuals.

When you have different Jobs for the same Client, you would usually have 
different FileSets in each Job.

This is really quite straight forward.  Your expectations regarding what 
Bacula should do in a given set of circumstances is incorrect.  Please 
adjust accordingly. :)



------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users