It's worth pointing out that you can build a failover pair of bacula directors and FDs with no software modifications, providing you've got shared storage for your data. The Heartbeat project has a mechanism for having a backup server take over a primary server's IP address when the primary goes down. MySQL replication can handle synchronizing a main and backup database, and shared storage (plus GFS or something similar) makes the backup data available to whichever system wants it.
This wouldn't handle the non-realtime, remote backups you were talking about. What you're talking about is a much bigger, more flexible clustering system, which could have a lot more uses. - Andy Rich wrote: > 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. > ------------------------------------------------------------------------- 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
