-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Schuldei wrote:
> On Sat, Apr 11, 2009 at 11:48 PM, John Drescher <[email protected]> wrote: >> On Sat, Apr 11, 2009 at 5:29 PM, Andreas Schuldei >> <[email protected]> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
