Bacula-users

Re: [Bacula-users] Fwd: concurrent backups to one volume?

2009-06-25 12:06:28
Subject: Re: [Bacula-users] Fwd: concurrent backups to one volume?
From: Christian Gaul <christian.gaul AT otop DOT de>
To: Silver Salonen <silver AT ultrasoft DOT ee>
Date: Thu, 25 Jun 2009 18:00:23 +0200
Silver Salonen schrieb:
> On Thursday 25 June 2009 18:28:28 Christian Gaul wrote:
>   
>> Silver Salonen schrieb:
>>     
>>> PS. The limit to be able to write only one job to one disk-based device 
>>>       
> has 
>   
>>> been a bizzare limit that just complicates the configuration, I still 
>>>       
> don't 
>   
>>> understand why we have this limit in disk-based backups (the claim "Bacula 
>>> uses disks as tapes" is just as bizzare).
>>>
>>>   
>>>       
>> I seem to be writing to disk based volumes just fine with multiple (5+)
>> concurrent jobs.
>>
>> Maybe i am misunderstanding something, but the problem isnt N jobs to 1
>> (disk based) volume, it is 1-N jobs to M (>1) volumes at the same time
>> which doesnt work.
>>
>> Also, one pool can only use one volume at one time for one job, and one
>> job can only use one SD at one time,  so that might limit you too.
>>
>> Concurrent jobs (except for me currently, and only to tape) work quite
>> nice. I personally opted to use spooling, in order to not have jobs
>> interleaved on tape.
>>
>>
>> But speaking of configuration complication, for me it complicates things
>> that valid jobs (for comparing with Full, Diffs and Incrementals) are
>> generated out of {Client,Fileset}and there is no way to tell it to use
>> {Client,Fileset,Storage} or {Client,Fileset,Pool}.. for creating offsite
>> backups i basically keep 2 identical filesets for every class of client
>> because i want / need two unrelated backups on 2 different media types
>> (no, copy jobs wont do because they are 2 different SDs)..
>>
>> Anyways, i am rambling, but multiple concurrent jobs to one disk volume
>> work fine, as long as your jobs use the same pool and are allowed to use
>> the same volume. If you try to use different pools ( -> different
>> volumes) for different jobs, then yes, they will wait till the SD can
>> mount a volume in the second pool.
>>     
>
> I meant the limitation from the configuration point of view - you cannot 
> configure a device to accept multiple jobs concurrently. If you want to be 
> able to actually do it, you have to "hack" the configuration - to show one 
> actual device as different devices.
>
>   
I think i understand what you mean, but you actually can accept multiple
jobs to the same device.. just not to different pools. But you are
right, since it's disk volumes, one file based SD could act like a
virtual tape changer with unlimited slots and drives... i guess you
probably could create a virtual changer with like 20 drives, but you are
right, that is kind of hack-isch.

If i find time i might experiment with the current possibilities of
virtual libraries and see if i can work something out that doesnt look
like a hack.

-- 
Christian Gaul
otop AG
D-55116 Mainz
Rheinstraße 105-107
Fon: 06131.5763.310
Fax: 06131.5763.500
E-Mail: christian.gaul AT otop DOT de
Internet: www.otop.de

Vorsitzender des Aufsichtsrats: Christof Glasmacher
Vorstand: Dirk Flug
Registergericht: Amtsgericht Mainz
Handelsregister: HRB 7647 


------------------------------------------------------------------------------
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>