On site A, I have sucessfully set up a bacula director on one host, several File Daemons on the hosts I want to backup, and finally one Storage Daemon where the backup actually is stored.
If disaster struck the building Site A, I want a second Storage Daemon on another site, Site B.
The Filesets, Director etc would be the same, except the jobs will be stored on the other Storage Daemon as well.
Are there any best practises on this?
You could either migrate or copy the job from the working volume to the final one:
... The term Migration, as used in the context of Bacula, means moving data from one Volume to another. In particular it refers to a Job (similar to a backup job) that reads data that was previously backed up to a Volume and writes it to another Volume ...
... The Copy process is essentially identical to the Migration feature with the exception that the Job that is copied is left unchanged ...
http://www.bacula.org/manuals/en/concepts/concepts/Migration_Copy.html
Edit:
In case you are using software compression, it would be better to copy the volume files from one site to another (using migration it will decompress and compress again).
You can use RunScript in the job resource to run an rsync, ftp, scp or any other available copy method after the backup is done.
Don't forget to copy the catalog database, otherwise you'll need to use bscan or some to recover the information. You could use MySQL replication too.
Doing what you want effectively means running the backups two times (two jobs, one backing up to the SD at Site A, the other to the SD at Site B) -- A better approach (assuming you back up to files on disK) might be to use something like DRBD (Linux) or GEOM gates (FreeBSD) to duplicate the back-end storage your daemon is using: This provides replication of the data without requiring a second backup job (though it has its own problems if your network link isn't reliable).
Other options include rsyncing your tape-files to an off-site provider (e.g. rsync.net, or your own secondary datacenter if you have one) which provides you with a local and remote copy in the event disaster strikes your main datacenter. The big caveat here is that your "remote" copy is always out of sync by as long as it takes your system to transfer the files over.
For what it's worth, my implementation is a variation on the second method I described: As part of the Bacula mount/unmount scripts the server rsyncs the virtual tape files (on mounting it pulls any changes from the remote site. On unmounting it pushes the changes).
This does make mounting/unmounting tapes take longer, which increases the time it takes a backup to complete (backups hang waiting for the "tape" to unmount while rsync is running), but with sufficient bandwidth between sites (and rsync's intelligent deltas) the overhead is not too bad.
