On Tuesday 21 August 2007 19:43, Steven Shoemaker wrote:
> Kern,
>
> We are not that big a site (~270 clients, data ~6TB, tapes LTO3) but are
> considering testing bacula to see if it would meet our needs.
> We currently do a GFS rotation schedule with a temporary injunction
> against recycling.
>
> I would vote for the following:
> Item 7: Implement creation and maintenance of copy pools
> Item 37: Add an item to the restore option where you can select a pool
> Item 41: Enable to relocate files and directories when restoring
It looks like you are working off an older projects file. Item 41 is already
implemented in 2.2.0. :-) In fact, there are also directive/commands that
allow a limited relocation of directories during the backup, which helps a
lot with migrating from a different vendor.
>
> But after I have gotten the chance to install and test bacula this may
> change;-)
Thanks,
Kern
>
> Steven
>
> On Mon, 2007-08-20 at 20:42 +0200, Kern Sibbald wrote:
> > Thanks. That seems pretty straight forward and gives me enough to chew on
> > for now. :-)
> >
> > One additional question:
> >
> > Of all the projects on the projects list, which 2 or 3 do you think are
> > most important from an enterprise standpoint?
> >
> > I ask because I haven't decided which project (singular) I am going to
> > work on.
> >
> > Best regards,
> >
> > Kern
> >
> > On Monday 20 August 2007 16:38, David Boyes wrote:
> > > > Item 8: Implement Copy pools
> > > > Date: 27 November 2005
> > > > Origin: David Boyes (dboyes at sinenomine dot net)
> > > > Status:
> > > >
> > > > What: I would like Bacula to have the capability to write copies
> > > > of backed-up data on multiple physical volumes selected
> > > > from different pools without transferring the data
> > > > multiple times, and to accept any of the copy volumes
> > > > as valid for restore.
> > > > [snip]
> > > >
> > > > Notes: I get the idea, but would like more details on the precise
> > > > syntax of the necessary directives and what they would do.
> > >
> > > I think there's two areas where new configuration would be needed.
> > >
> > > 1) identify a "SD mux" SD (specify it in the config just like a normal
> > > SD. The SD configuration would need something like a "Daemon Type =
> > > Normal/Mux" keyword to identify it as a multiplexor. (The director code
> > > would need modification to add the ability to do the multiple session
> > > setup, but the impact of the change would be new code that was invoked
> > > only when a SDmux is needed).
> > >
> > > 2) Additional keywords in the Pool definition to identify the need to
> > > create copies. Each pool would acquire a Copypool= attribute (may be
> > > repeated to generate more than one copy. 3 is about the practical
> > > limit, but no point in hardcoding that).
> > >
> > > Example:
> > > Pool {
> > > Name = Primary
> > > Pool Type = Backup
> > > Copypool = Copy1
> > > Copypool = OffsiteCopy2
> > > }
> > >
> > > where Copy1 and OffsiteCopy2 are valid pools.
> > >
> > > In terms of function (shorthand):
> > >
> > > Backup job X is defined normally, specifying pool Primary as the pool
> > > to use. Job gets scheduled, and Bacula starts scheduling resources.
> > > Scheduler looks at pool definition for Primary, sees that there are a
> > > non-zero number of copypool keywords. The director then connects to an
> > > available SDmux, passes it the pool ids for Primary, Copy1, and
> > > OffsiteCopy2 and waits. SDmux then goes out and reserves devices and
> > > volumes in the normal SDs that serve Primary, Copy1 and OffsiteCopy2.
> > > When all are ready, the SDmux signals ready back to the director, and
> > > the FD is given the address of the SDmux as the SD to communicate with.
> > > Backup proceeds normally, with the SDmux duplicating blocks to each
> > > connected normal SD, and returning ready when all defined copies have
> > > been written. At EOJ, FD shuts down connection with SDmux, which closes
> > > down the normal SD connections and goes back to an idle state. SDmux
> > > does not update database; normal SDs do (noting that file is present on
> > > each volume it has been written to).
> > >
> > > On restore, director looks for the volume containing the file in pool
> > > Primary first, then Copy1, then OffsiteCopy2. If the volume holding the
> > > file in pool Primary is missing or busy (being written in another job,
> > > etc), or one of the volumes from the copypool list that have the file
> > > in question is already mounted and ready for some reason, use it to do
> > > the restore, else mount one of the copypool volumes and proceed.
> > >
> > >
> > > -----------------------------------------------------------------------
> > >-- 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-devel mailing list
> > > [EMAIL PROTECTED]
> > > https://lists.sourceforge.net/lists/listinfo/bacula-devel
> >
> > -------------------------------------------------------------------------
> > 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
-------------------------------------------------------------------------
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
