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
But after I have gotten the chance to install and test bacula this may
change;-)
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
