Hello, Thanks for your feature request. Unfortunately at the moment no one is collecting these, and so you will probably need to resubmit it later.
Concerning the request itself. This is very unlikely to be implemented any time in the near future unless someone contributes the code, because this is a rather high-end feature, and there are a very large number of other missing features that are much higher in priority (IMO). Regards, Kern On Friday 18 May 2007 15:11, Rich wrote: > this probably is the worst time to submit a request, but given it's > scope it probably won't have huge impact :) > > i am not currently subscribed to -devel - please, cc me or -users (or > force me to subscribe, if the discussion would be limited to that list). > > ps. page http://www.bacula.org/?page=vote doesn't seem to have the > latest results; > page http://www.bacula.org/?page=projects has item description > "Implement a Bacula console, and management tools probably using Qt3 and > C++." - from my reading of list archives, it seems qt4 is used ? > > the projects page also has some typos, that i would have fixed if that > was in a wiki :) > > --------------------------------------------------------------------- > Item 41: Clustered bacula server, including director, storage daemon > and database > Origin: Rihards, [EMAIL PROTECTED] > Date: 18 May 2007 > Status: > > > What: It would be nice to run two (or more) separate backup servers > that would synchronise backups and be able to take over each others > clients in case any server dies. > Clustered servers would each run a director, storage daemon and each > would have a separate database. > > > Why: Disk based backup solutions have become very popular, but > proper offsite backups and distributed servers are cumbersome and > requires too much of hacking and manual interventions. > > Currently, failed primary server would require manual reconfiguring of > all clients (setting identical director names welcomes mistakes later > on), and it also requires syncing data separately from bacula. > Configuring and restoring from a secondary system is far from > straightforward. > > In case of geographically distributed servers there also is no way to > tell backup jobs to go to a particular server first, so there's > increased network traffic as well. > For example, if organisation has two locations that both have services > to backup, each site could have a separate backup server with simple > failover to the remote server. > > > Notes: > * File daemons would have access for all servers in the cluster; > * It should be possible to set preferred server for each client; > * How should sharing of the configuration be implemented ? Would it be > enough to configure one server and get the changes propagated to all of > them ? > * Would it make sense to back up to one server only ? For example, some > jobs could be configured to back up, but not sync to other servers. In > case of the primary server failure secondary server would take the > backup, but move it to the primary when it comes back. > -- > Rich > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Bacula-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/bacula-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
