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.

 >  It seems that the logic was to do something like this?

> job {
>    name "client1-backup"
>    client "client1"
> }
> job {
>    name "client1-restore"
>    client "client1"
> }
> job {
>    name "client1-verify"
>    client "client1"
> }

No, not at all as far as I know.  You really only need one restore job, 
which can then run manually and adjust as required.  You could literally 
get away with one backup Job, if all you did was run it manually and 
adjust it.  But most people want their backup jobs to run unattended. 
Thus, you create one Job for each backup you want done.  And a given 
Client can have more than one Job run against it.  For example: backup 
this FileSet, backup that FileSet, backup and dump this database.


------------------------------------------------------------------------------
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