On Sat, Apr 11, 2009 at 8:19 PM, Andreas Schuldei
<schuldei+bacula-users AT spotify DOT com> wrote:
> that is a solution for now since we backup to disk. i did read
> http://www.bacula.org/en/rel-manual/Basic_Volume_Management.html and
> understood nothing, though. the text is not very well written.
>
> soon we want to switch to our new and expensive tape robot though and
> want to backup to tape instead and then concurrency wont work anymore,
> will it? at that point we would need to come back to that "ahead of
> time" backup anyway, right?
>

Concurrency will work great. I have been using it in the way I
described for 5 years with bacula. I mean with a small spool size and
several concurrent jobs.  At one point I was doing this with a single
DLT-IV drive but now I have a 2 drive 24 slot LTO2 autochanger. It
works great for me with a small spool size. Basically each job works
to fill its 5GB spool and then these 5GB spools go to tape when they
are ready. With concurrent jobs this means both the jobs and the tape
drive is pretty busy even though the clients generally can not backup
at 30 to 40MB/s (tape drive speed) the drive keeps busy when 3 or more
jobs are run simultaneously. BTW, I backup 40 machines nightly with
this and I have 20TB on tape with a bacula postgres 27GB database.

John

------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users