[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bacula-users
Subject:    Re: [Bacula-users] Multiplexing multiple jobs to tape
From:       Chris Howells <chris+bacula () chrishowells ! co ! uk>
Date:       2007-08-31 13:44:20
Message-ID: 46D81B34.3070600 () chrishowells ! co ! uk
[Download RAW message or body]

Hi,

Arno Lehmann wrote:
> First you need to enable job concurrency. That will require you to add 
> "Maximum Concurrent Jobs" in several places, which are well 
> documented. Furthermore, you might have to change the jobs and 
> schedules so that jobs actually run in parallel. The schedules are 
> clear, I think, but keep in mind that Bacula only runs jobs of the 
> same priority at once.

Ah, I see, I will give that a go, thank you.

> Then you've got to decide how Bacula should multiplex.
> 
> The simple solution requires no further configuration; jobs will write 
> their blocks to tape as they arrive. This is simple, but restoring can 
> take lots of extra time due to many unneccessary tape positionings and 
> possibly reading unnecessary data.
> 
> The (almost always) better solution is to enable spooling with a 
> reasonable spool space - a few hundred GB, preferrably. This costs 
> more disk space (which is comparable cheap), but then, Bacula will 
> spool as much of a job as is possible and write that en block to tape.

Make sense.

At the moment there are two backup servers. These are connected to each 
other via a GigE switch. Currently we have two LTO 2 drives connected to 
one, and one backup server will happily pull data off itself, and the 
other server, and write to both tapes simultaneously at 25MB/s or so.

I really doubt we'll get anything like reasonable performance from LTO 4 
from that however (simply replacing the LTO 2 with LTO 4). The machine 
specs aren't ludicrously high. 120MB/s is a silly amount of data ;)

> The time it takes for a single backup can increase, but the overall 
> throughput of several jobs will be better, and data from each job is 
> kept more or less together on tape, allowing faster restores.
> 
> In this scenario, the speed of your spooling file system will probably 
> be the limiting factor for tape speed, so you better implement a fast 
> RAID for spool space. Imagine one job is despooling data, while 
> several others write data from the client to the spool area and you 
> get an impression of the kind of disk subsystem you need.

Sure. We have a ridiculously fast SAN which is quite under utilised at 
the moment, so I will see how that goes :)

Thanks.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
[prev in list] [next in list] [prev in thread] [next in thread]