On May 4, 2015, at 10:57 AM, Josh Fisher <[email protected]> wrote:
> 
> On 5/4/2015 10:02 AM, Dan Langille wrote:
>>> On May 4, 2015, at 4:14 AM, Luc Van der Veken <[email protected]> 
>>> <mailto:[email protected]> wrote:
>>> 
>>> This approach can help too: besides doing them in parallel (limited to 5 
>>> concurrent jobs because ultimately it all winds up on the same disks), I 
>>> also divided them into 4 groups.
>>> >From the 1st to 4th Friday night each month, a full backup is done of one 
>>> >group and differential of the other three. If there's a fifth Friday, it's 
>>> >differential for all.
>> I plan to create one device per client.
> 
> Then there are a few things to consider regarding pools and organization of 
> volume files. Basically, all volumes used by a client, regardless of pool, 
> must be in the same directory. If the devices for two clients use different 
> directories but the same pool(s), then their devices must have a different 
> MediaType. This is because Bacula will assume that it can load a volume with 
> a particular MediaType into any device having that same MediaType..

I plan to have all Volumes in the same directory.  At present, all 
backups-to-disk use this device:

Device {
  Name           = CreyFile
  Media Type     = File
  Archive Device = /usr/local/bacula/volumes
  LabelMedia     = yes
  Random Access  = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen     = no
}

I plan to create a new device for each client, much like this:

Device {
  Name           = CreyFile-bast
  Media Type     = File
  Archive Device = /usr/local/bacula/volumes
  LabelMedia     = yes
  Random Access  = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen     = no
}

... where bast is a client name (i.e. bast-fd is a Client).

FYI:

# ls /usr/local/bacula/volumes | wc -l
    2520

# du -ch /usr/local/bacula/volumes
3.4G    /usr/local/bacula/volumes/wocker
 10T    /usr/local/bacula/volumes
 10T    total

> As pointed out offline, attribute spooling can be important for parallel 
> (i.e. concurrent) jobs. The theory being: database access while writing files 
> slows down both processes.
>> 
>> In my case, the database server is on another machine.
>> 
>>> I am using only one pool and device for all, just raised 'Maximum 
>>> Concurrent Jobs' above 1.
>>> That causes interleaving, but on disk that should be no problem.
>> I'm not sure I want interleaving.
> 
> If each client has its own device, then there will never be interleaving 
> unless multiple jobs for the same client are running simultaneously.

I doubt I will be doing that. I think I will allow concurrent jobs at the SD 
though, not at the client.
—
Dan Langille
http://langille <http://langille/>.org/





Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to