[Bacula-devel] feature request : clustered server

[Rich <ri...@hq...>]

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, ri...@hq...
   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