-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Schuldei wrote:
> On Sat, Apr 11, 2009 at 11:48 PM, John Drescher <drescherjm AT gmail DOT com>
> wrote:
>> On Sat, Apr 11, 2009 at 5:29 PM, Andreas Schuldei
>> <schuldei+bacula-users AT spotify DOT com> wrote:
>>> hi!
>>>
>>> Currently our bacula system cycles through our servers and for each it
>>> initiates the respective backup shell script, waits for its
>>> completion, transfers the data and continues on to the next box.
>>>
>>> This cycle is rather predictable and repetitiv. On some servers, where
>>> time consuming finds and tars are executed the system spends a lot of
>>> time waiting on the completion of those, until it can start
>>> transferring the resulting tar files.
>>>
>>> I would like to speed up the process by preparing these backups ahead
>>> of time, so that they finish just in time for the bacula director to
>>> come by and pick up the new tar files, so that only little or no time
>>> would be spend waiting. Ideally i would like it to be adaptive. the
>>> longer it takes to prepare the backup the earlier it would start to
>>> prepare it. if for some reason the datavolumes shrinks and the
>>> preparation would take less time, gradually move the start backwards.
>>> Should the preparation of the backup not have started when the bacula
>>> director comes by the backup is made the old fashioned way with the
>>> director waiting for completion.
>>>
>>> Has someone build a system like this?
>>>
>> I would just enable concurrency. Use a small spool file (less than 10
>> GB) and let several machines run their backups simultaneously.
It is easier to follow the conversation if you reply inline.
> 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.
We are always looking for people to submit improvements.
> 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?
If you have more than one tape drive, then yes, you can still do
concurrency.
I'm also thinking: you could backup to local disk with high concurrency,
then migrate/copy the job to tape later. For this, Bacula 3.x would be
better I think.
- --
Dan Langille
BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon - The PostgreSQL Conference: http://www.pgcon.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknhNewACgkQCgsXFM/7nTwwIQCfbiM4QgA5HOph7c1gN6fFvi++
C7cAn1f96iMJR6TjsjG0Ny0WTmxB2/BI
=QUlE
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
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
|
