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
