Como posso configurar um Daemon de armazenamento de site duplo no Bacula (espelhar o backup)

Question

No site A, eu configurei com sucesso um diretor bacula em um host, vários Daemons de arquivo nos hosts que eu quero fazer backup e, finalmente, um Daemon de armazenamento onde o backup realmente é armazenado.

Se um desastre ocorreu no site de construção A, eu quero um segundo Storage Daemon em outro site, o Site B.

Os conjuntos de arquivos, o diretor etc seriam os mesmos, exceto que os trabalhos também serão armazenados no outro daemon de armazenamento.

Há alguma melhor prática sobre isso?

    

Answer 1

Você pode migrar ou copiar o trabalho do volume de trabalho para o final:

... 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 ...

link

Editar:

Caso você esteja usando a compactação de software, seria melhor copiar os arquivos de volume de um site para outro (usando a migração, ele será descompactado e compactado novamente).

Você pode usar o RunScript no recurso de trabalho para executar um rsync, ftp, scp ou qualquer outro método de cópia disponível após o backup ser feito.

Não se esqueça de copiar o banco de dados do catálogo, caso contrário, você precisará usar o bscan ou alguns para recuperar as informações. Você pode usar a replicação do MySQL também.

    

Answer 2

Fazer o que você quer efetivamente significa executar os backups duas vezes (dois trabalhos, um voltando para o SD no Site A, o outro para o SD no Site B) - Uma abordagem melhor (supondo que você faça backup de arquivos em disK) pode ser usar algo como DRBD (Linux) ou GEOM gates (FreeBSD) para duplicar o armazenamento de back-end que seu daemon está usando: Isso fornece replicação dos dados sem requerer um segundo trabalho de backup (embora tenha seus próprios problemas se o seu link de rede não for confiável).

Outras opções incluem rsync ing seus arquivos de fita para um provedor externo (por exemplo, rsync.net , ou seu próprio secundário datacenter se você tiver um) que forneça uma cópia local e remota no caso de ocorrer um desastre no datacenter principal. A grande ressalva aqui é que sua cópia "remota" está sempre fora de sincronia, desde que o sistema transfira os arquivos.

Por que vale a pena, minha implementação é uma variação do segundo método que descrevi: Como parte dos scripts de montagem / desmontagem do Bacula, o servidor rsyncs os arquivos de fita virtual (na montagem, ele obtém quaisquer alterações do site remoto. ele empurra as mudanças).
Isso faz com que as fitas de montagem / desmontagem demorem mais, o que aumenta o tempo de backup (backups aguardando a desmontagem da "fita" durante a execução do rsync), mas com largura de banda suficiente entre sites (e deltas inteligentes do rsync) sobrecarga não é tão ruim.