Com recursos de failover e balanceamento de carga, o Bacula Enterprise permite que as organizações minimizem o tempo de inatividade, assegurando a continuidade das operações mesmo em caso de falhas de hardware, software ou outros eventos imprevistos. Além disso, sua arquitetura distribuída e escalável proporciona redundância e resiliência, permitindo a recuperação rápida de sistemas e dados críticos. Com a capacidade de criar ambientes altamente disponíveis, o Bacula Enterprise se destaca como uma solução confiável para empresas que buscam proteger seus ativos de dados de forma eficaz e constante.
Para implementarmos uma arquitetura de alta disponibilidade do Bacula, é necessário ter em mente todos os serviços que podem um ponto único de falha, como segue.
- Jobs de backups armazenados
- Storage Daemon
- Director (gerenciador) e Catálogo
Isto posto, vamos avaliar as possíveis funcionalidades para prover mais resiliência a desastres para cada um dos componentes.
Jobs de Backup
Os jobs de backup do Bacula ficam armazenados em discos, fitas e storage de nuvem, sempre gravados por um Storage Daemon. Dessa maneira, a proteção contra perda ou falhas passa por um ou mais dos seguintes métodos.
Proteções Físicas
Para disco a proteção de RAID6 para os volumes de backup é o mais recomendado e comum do mercado, suportando a tolerância de até dois disco com falhas. Para fitas, algumas fitotecas possuem a funcionalidade de “espelhamento” que permite a gravação simultânea em duas fitas com igual conteúdo. Para nuvem, proteções de cada provedor e replicação de storage de objetos, inclusive multi-região, podem ser utilizados. Tudo isso sem prejuízo de outras técnicas possíveis.
Funcionalidades do Cópia e Clone
Através do Bacula é possível configurar jobs do tipo Copy sequencialmente após o Job de backup terminado ou jobs de Clone que executam de maneira simultânea (Diretiva Run do Job). Dessa maneira, cópias entre dispositivos do mesmo Storage Daemon (ex.: disco para fita) e entre dispositivos de Storage Daemons diferentes permite a restauração dos dados em caso de perda de uma das mídias de backup.
Storage Daemon
Um Director do Bacula pode administrar virtualmente infinitos Storage Daemons como back-end de armazenamento do backup. Esses armazenamentos podem ser utilizados de maneira independente ou agrupados para fins de balanceamento de carga e fail-over através de um Storage Group do Bacula. Neste caso, múltiplos Storages podem ser separados por vírgulas para uso pelo Pool ou Job de backup, e diferentes políticas de balanceamento podem ser utilizadas, como nos exemplos de configuração a seguir, pelo texto e pelo Bweb (Figura 1).
Pool {
...
Storage = File4, File5, File6
StorageGroupPolicy = LeastUsed
...
}
Figura 1. Configuração do Storage Group no recurso Pool do Bacula (Bweb).
Director (gerenciador) e Catálogo
Para este tópico existem dois modelos de arquitetura que podem ser utilizados: uma multi-master (ou multi-Director), e outra de Director master-standby.
Multi-Director
Nessa arquitetura múltiplos Directors são implementados, tipicamente em sítios distintos. Os Storage e File Daemons, se desejados, podem ser manipulados por mais de um Director. Essa arquitetura pode ser tipicamente utilizada por bancos, nos quais os data center são inteiramente replicados. Nessa arquitetura cada Director possui seu próprio Catálogo, que eventualmente pode ter o acesso compartilhado entre os gerenciadores.
A administração no entanto pode ser mais trabalhosa, na medida que mais de uma encarnação do sistema de backup precisa ser administrada.
Director Master-Standby
Nessa modalidade, em um mesmo tempo, apenas uma instância do Director deve estar ativa. Replicas inativas do Director são instaladas e recebem réplicas periódicas das configurações. Em caso de desastre do Director principal, um dos Directors inativos assume para a retomada dos jobs de backup e restauração.
Conforme exibido na Figura 2, o Catálogo PostgreSQL do Bacula pode seguir a mesma lógica Master-Standby das máquinas dos Directors ou pode ter um conjunto de máquinas à parte com acesso externo.
Figura 2. Replicação Master-Standby do PostgreSQL
Seja como for o modelo adotado, seguem exemplos de Jobs Admin para réplica do Director e configuração do PostgreSQL para a réplica do Catálogo do Bacula.
Réplica das Configurações do Director
Configurar chave ssh usuário bacula no Linux – Director Primário:
mkdir /opt/bacula/working/.ssh/ chown -R bacula /opt/bacula sudo -u bacula ssh-keygen -t rsa cat /opt/bacula/working/.ssh/id_rsa.pub # save contents for later.
Configurar chave ssh usuário bacula no Linux – Director Secundário:
mkdir /opt/bacula/working/.ssh/ chown -R bacula /opt/bacula touch /opt/bacula/working/.ssh/authorized_keys chmod -R 750 /opt/bacula/working/.ssh/ vi /opt/bacula/working/.ssh/authorized_keys
Abra o conteúdo de rsa_id.pub da máquina primária /opt/bacula/working/.ssh/id_rsa.pub e cole no arquivo /opt/bacula/working/.ssh/authorized_keys. Salve e saia.
Ref.: https://www.hostinger.com.br/tutoriais/como-configurar-chaves-ssh
Criar Job Admin que Executa Script copia das configurações para ambiente secundário (Run Script Before Job):
Job={
Type=Admin
...
scp -i /opt/bacula/working/.ssh/id_rsa.pub -r /opt/bacula/etc/conf.d/Director/ bacula@<ip>://opt/bacula/etc/conf.d/
scp -i /opt/bacula/working/.ssh/id_rsa.pub -r /opt/bacula/etc/bacula-dir.conf bacula@<ip>://opt/bacula/etc
}
Réplica do Catálogo PostgreSQL Master-Standby
No nó Primário:
# Crie um usuário com permissões de réplica. Definir senha. sudo -u postgres createuser -U postgres repuser -P -c 5 --replication mkdir /var/lib/pgsql/data/archive chown -R postgres /var/lib/pgsql/data/archive/ # Add permissão conexão nó secundário. IP do passivo do cluster echo "host replication all 10.146.19.65/24 md5" >> /var/lib/pgsql/data/pg_hba.conf vi /var/lib/pgsql/data/postgresql.conf ++ listen_addresses = '*' # talvez já esteja configurado wal_level = hot_standby archive_mode = on archive_command = 'test ! -f /var/lib/pgsql/data/archive/%f && cp %p /var/lib/pgsql/data/archive/%f' :x! service postgresql reload # se não funcionar, restart - que causa indisponibilidade firewall-cmd --permanent --zone=public --add-port=5432/tcp service firewalld restart
No nó Secundário:
sudo service postgresql stop mv /var/lib/pgsql/data /var/lib/pgsql/data.old # Copiar a base do primário (IP do primário) para o secundário sudo -u postgres pg_basebackup -h 10.145.19.35 -D /var/lib/pgsql/data -U repuser -v -P -X stream # senha repuser - VkR5#64%#n2H vi /var/lib/pgsql/data/postgresql.conf # Acrescentar: hot_standby = on promote_trigger_file = '/tmp/postgresql.trigger.5432' restore_command = 'cp /var/lib/pgsql/data/archive/%f %p' recovery_target_timeline = 'latest' archive_cleanup_command = 'pg_archivecleanup /var/lib/pgsql/data/archive %r' ##### sudo -u postgres touch /var/lib/pgsql/data/standby.signal service postgresql start # Consulte os logs do postgresql em /var/lib/pgsql/data/log para verificar o status da replicação.
Ref.: https://cloud.google.com/community/tutorials/setting-up-postgres-hot-standby
Disponível em: 
Português
English (Inglês)
Español (Espanhol)
