在站点 A 上，我已在一台主机上成功设置了 bacula 导向器，在我想要备份的主机上设置了几个文件守护进程，最后设置了一个实际存储备份的存储守护进程。
如果灾难袭击了建筑物站点 A，我希望在另一个站点（站点 B）上安装第二个存储守护进程。
文件集、Director等将是相同的，只是作业也将存储在其他存储守护进程上。
这方面有没有什么最佳实践？
答案1
您可以将作业从工作卷迁移或复制到最终卷：
... 在 Bacula 上下文中使用的术语“迁移”是指将数据从一个卷移动到另一个卷。具体来说，它指的是读取先前备份到卷的数据并将其写入另一个卷的作业（类似于备份作业）...
... 复制过程基本与迁移功能相同，只是复制的作业保持不变......
http://www.bacula.org/manuals/en/concepts/concepts/Migration_Copy.html
编辑：
如果您使用软件压缩，最好将卷文件从一个站点复制到另一个站点（使用迁移它将解压缩并再次压缩）。
备份完成后，您可以使用作业资源中的 RunScript 来运行 rsync、ftp、scp 或任何其他可用的复制方法。
不要忘记复制目录数据库，否则您将需要使用 bscan 或某些工具来恢复信息。您也可以使用 MySQL 复制。
答案2
有效地执行您想要的操作意味着运行两次备份（两个作业，一个备份到站点 A 的 SD，另一个备份到站点 B 的 SD）——更好的方法（假设您备份到磁盘上的文件）可能是使用类似DRBD（Linux）或GEOM 门（FreeBSD）复制守护进程正在使用的后端存储：这提供了数据复制而不需要第二个备份作业（尽管如果您的网络链接不可靠，它也有自己的问题）。
其他选项包括rsync将磁带文件传输到异地提供商（例如rsync.net或您自己的辅助数据中心（如果有的话），当灾难袭击您的主数据中心时，它将为您提供本地和远程副本。这里最大的警告是，只要您的系统需要传输文件，您的“远程”副本就会始终不同步。
不管怎么说，我的实现是我描述的第二种方法的变体：作为 Bacula 挂载/卸载脚本的一部分，服务器 rsync 虚拟磁带文件（挂载时，它会从远程站点提取任何更改。卸载时，它会推送更改）。
这确实会使磁带的挂载/卸载时间更长，从而增加备份完成所需的时间（备份挂起，等待 rsync 运行时“磁带”卸载），但如果站点之间有足够的带宽（以及 rsync 的智能增量），开销就不会太糟糕。