Bacula-users

Re: [Bacula-users] Moving from serial jobs to parallel jobs.

2015-05-04 15:56:17
Subject: Re: [Bacula-users] Moving from serial jobs to parallel jobs.
From: Dan Langille <dan AT langille DOT org>
To: Josh Fisher <jfisher AT pvct DOT com>
Date: Mon, 4 May 2015 15:52:53 -0400
On May 4, 2015, at 10:57 AM, Josh Fisher <jfisher AT pvct DOT com> wrote:

On 5/4/2015 10:02 AM, Dan Langille wrote:

On May 4, 2015, at 4:14 AM, Luc Van der Veken <lucvdv AT wimionline DOT com> 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





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
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users