Con recursos de conmutación por error y equilibrio de carga, Bacula Enterprise permite a las organizaciones minimizar el tiempo de inactividad, asegurando la continuidad de las operaciones incluso en caso de fallas de hardware, software u otros eventos imprevistos. Además, su arquitectura distribuida y escalable proporciona redundancia y resiliencia, permitiendo la recuperación rápida de sistemas y datos críticos. Con la capacidad de crear entornos altamente disponibles, Bacula Enterprise se destaca como una solución confiable para empresas que buscan proteger sus activos de datos de manera efectiva y constante.
Para implementar una arquitectura de alta disponibilidad de Bacula, es necesario tener en cuenta todos los servicios que pueden ser un punto único de falla, como se indica a continuación.
- Trabajos de copia de seguridad almacenados
- Storage Daemon
- Director (gestor) y Catálogo
Dicho esto, evaluaremos las posibles funcionalidades para proporcionar más resiliencia ante desastres para cada uno de los componentes.
Trabajos de Copia de Seguridad
Los trabajos de copia de seguridad de Bacula se almacenan en discos, cintas y almacenamiento en la nube, siempre grabados por un Storage Daemon. De esta manera, la protección contra pérdidas o fallas pasa por uno o más de los siguientes métodos.
Protecciones Físicas
Para los discos, la protección RAID6 para los volúmenes de copia de seguridad es la más recomendada y común en el mercado, admitiendo la tolerancia de hasta dos discos con fallas. Para las cintas, algunas bibliotecas de cintas tienen la funcionalidad de «espejo» que permite la grabación simultánea en dos cintas con contenido idéntico. Para la nube, se pueden utilizar las protecciones proporcionadas por cada proveedor y la replicación de almacenamiento de objetos, incluso en múltiples regiones. Todo esto sin perjuicio de otras técnicas posibles.
Funcionalidades de Copia y Clonación
A través de Bacula, es posible configurar trabajos del tipo Copia secuencialmente después de que se complete el trabajo de copia de seguridad o trabajos de Clonación que se ejecutan de manera simultánea (Directiva Run del Trabajo). De esta manera, las copias entre dispositivos del mismo Storage Daemon (por ejemplo, disco a cinta) y entre dispositivos de diferentes Storage Daemons permiten la restauración de datos en caso de pérdida de uno de los medios de copia de seguridad.
Storage Daemon
Un Director de Bacula puede administrar virtualmente un número infinito de Storage Daemons como almacenamiento en el backend de copia de seguridad. Estos almacenes pueden utilizarse de forma independiente o agruparse para fines de equilibrio de carga y conmutación por error a través de un Grupo de Almacenamiento de Bacula. En este caso, múltiples Almacenamientos pueden separarse por comas para su uso en el Pool o Trabajo de copia de seguridad, y pueden utilizarse diferentes políticas de equilibrio de carga, como se muestra en los ejemplos de configuración a continuación, mediante texto y Bweb (Figura 1).
Pool {
...
Almacenamiento = File4, File5, File6
PolíticaGrupoAlmacenamiento = MenosUtilizado
...
}
Figura 1. Configuración del Grupo de Almacenamiento en el recurso Pool de Bacula (Bweb).
Director (gestor) y Catálogo
Para este tema, existen dos modelos de arquitectura que pueden utilizarse: uno multi-master (o multi-Director) y otro de Director principal-standby.
Multi-Director
En esta arquitectura, se implementan múltiples Directores, generalmente en sitios diferentes. Los Storage y File Daemons, si se desean, pueden ser gestionados por más de un Director. Esta arquitectura se puede utilizar típicamente en bancos, donde los centros de datos se replican por completo. En esta arquitectura, cada Director tiene su propio Catálogo, que eventualmente puede compartirse entre los administradores.
Sin embargo, la administración puede ser más laboriosa, ya que se deben administrar más de una instancia del sistema de copia de seguridad.
Director Principal-Standby
En este modo, en un momento dado, solo una instancia del Director debe estar activa. Las réplicas inactivas del Director se instalan y reciben réplicas periódicas de las configuraciones. En caso de un desastre en el Director principal, una de las réplicas inactivas asume el control para reanudar los trabajos de copia de seguridad y restauración.
Como se muestra en la Figura 2, el Catálogo de PostgreSQL de Bacula puede seguir la misma lógica principal-standby que las máquinas de los Directores o puede tener un conjunto de máquinas separadas con acceso externo. 
Figura 2. Replicación Principal-Standby de PostgreSQL
Sea cual sea el modelo adoptado, aquí hay ejemplos de Trabajos de Administración para la replicación del Director y la configuración de PostgreSQL para la replicación del Catálogo de Bacula.
Replicación de las Configuraciones del Director
Configurar la clave ssh del usuario bacula en Linux – Director Primario:
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 # guardar el contenido para más tarde.
Configurar la clave ssh del usuario bacula en Linux – Director Secundario:
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 el contenido de rsa_id.pub de la máquina primaria /opt/bacula/working/.ssh/id_rsa.pub y péguelo en el archivo /opt/bacula/working/.ssh/authorized_keys. Guarde y salga.
Ref.: https://www.hostinger.com.br/tutoriais/como-configurar-chaves-ssh
Crear un Trabajo de Administración que Ejecute un Script de copia de las configuraciones al entorno secundario (Ejecutar Script Antes del Trabajo):
Trabajo={
Tipo=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
}
Replicación del Catálogo PostgreSQL Principal-Standby
En el Nodo Principal:
# Crear un usuario con permisos de replicación. Establecer una contraseña. 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/ # Agregar permisos de conexión para el nodo secundario. IP pasiva del clúster 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 = '*' # tal vez ya esté 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 # si no funciona, reiniciar, lo que causa una indisponibilidad firewall-cmd --permanent --zone=public --add-port=5432/tcp service firewalld restart
En el Nodo Secundario:
sudo service postgresql stop mv /var/lib/pgsql/data /var/lib/pgsql/data.old # Copiar la base de datos desde el primario (IP del primario) al secundario sudo -u postgres pg_basebackup -h 10.145.19.35 -D /var/lib/pgsql/data -U repuser -v -P -X stream # contraseña repuser - VkR5#64%#n2H vi /var/lib/pgsql/data/postgresql.conf # Agregar: 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 los registros de postgresql en /var/lib/pgsql/data/log para verificar el estado de la replicación.
Ref.: https://cloud.google.com/community/tutorials/setting-up-postgres-hot-standby
Disponível em: 
Português (Portugués, Brasil)
English (Inglés)
Español
