Whitepaper — PodHeitor File Replication (BRC) - PodHeitor — Backup, Replicação e Recuperação de Desastres

Replicación continua entre clusters PodHeitor. Replica jobs cross-site en tiempo real, con filtro de pool, transformación de client, y dedup global compartido entre origen y destino.

Replicación continua entre Storage Daemons — RPO en minutos.
Transformación cross-site — renombrado de Storage, Pool y Client en destino, automático.
Dedup compartida — solo envía chunks nuevos, banda mínima.
Bandwidth throttling adaptativo — no compite con producción, recupera capacidad cuando ociosa.
Verify automático en destino — checksums per-chunk garantizan integridad end-to-end.

Producción en 30 días, al menos 50% más barato. Trial gratuito, RPMs y DEBs firmados, soporte directo con Heitor Faria. Reemplace su licencia Veeam, Commvault o Bacula Enterprise sin romper la ventana nocturna.

Solicitar trial gratuito de 30 días →

Tabla de Contenidos

Resumen Ejecutivo
Descripción del Problema
Descripción General de la Solución
Arquitectura
Casos de Uso
Instalación
Referencia de Configuración
Dimensionamiento y Requisitos
Matriz de Compatibilidad
Opciones de Backup y Restauración
Ejemplos de Configuración
Procedimientos Operativos
Seguridad
Cumplimiento e Informes
Consideraciones de Rendimiento
Resolución de Problemas
Evidencia Validada
Roadmap
Información Comercial

1. Resumen Ejecutivo

PodHeitor BRC (Backup, Replication and Conversion) es un plugin comercial para PodHeitor Backup Edition que transforma el Storage Daemon en un motor de replicación de archivos en tiempo real. Al interceptar los flujos de datos de backup en el nivel del SD, BRC replica los archivos hacia un sistema de archivos de destino mientras se realiza el backup, proporcionando disponibilidad inmediata de los archivos sin la latencia de una restauración tradicional de Bacula.

Beneficios Clave

Beneficio	Impacto
Recuperación instantánea de archivos	Acceda a los archivos replicados directamente — sin necesidad de flujo de restauración
Reducción del RTO	Recuperación en minutos en lugar de horas
Integración nativa con Bacula	Aprovecha la infraestructura de backup existente — sin agentes adicionales
Automatización de cumplimiento	Informes de RPO/RTO para auditoría y gobernanza
Fidelidad de metadatos	Preservación completa de ACLs, xattrs, archivos dispersos, propietario y timestamps
Características empresariales	Cifrado, grupos de consistencia, multi-sitio, failover, snapshots

Cómo Funciona

Se ejecuta un job de backup estándar de Bacula (Full, Incremental o Differential)
El File Daemon envía los datos de los archivos al Storage Daemon de forma habitual
El plugin PodHeitor BRC intercepta el flujo de datos en el SD
Los archivos se escriben en tiempo real en el destino de réplica configurado
El backup finaliza normalmente — los archivos quedan disponibles tanto en el volumen de Bacula como en la ruta de réplica

Resultado: una copia de DR en caliente, siempre sincronizada con el último backup y accesible como archivos regulares en el sistema de archivos.

2. Descripción del Problema

Los flujos de restauración tradicionales de Bacula requieren:

Identificar el conjunto de backup correcto
Iniciar un job de restauración mediante bconsole o Bacularis
Esperar a que los datos sean leídos desde los volúmenes de almacenamiento
Escribir los archivos en la ubicación de destino

Para grandes volúmenes de datos, este proceso puede tardar horas en completarse. En escenarios de recuperación ante desastres, cada minuto de inactividad impacta directamente las operaciones del negocio.

Desafíos Operativos

RTO elevado: el tiempo de restauración es proporcional al tamaño del conjunto de datos
Intervención manual: la restauración requiere la acción de un operador
Sin acceso inmediato: los archivos no están disponibles hasta que se completa la restauración
Validación de DR: es difícil verificar la recuperabilidad sin realizar una restauración real
Carga de cumplimiento: demostrar el cumplimiento del RPO/RTO requiere evidencia manual

PodHeitor BRC aborda todos estos desafíos manteniendo una réplica continuamente sincronizada y siempre lista para su uso.

3. Descripción General de la Solución

Tres Pilares

B — Orquestación de Backup

El plugin opera de forma transparente dentro del flujo de backup existente de Bacula. Admite los tres niveles de backup (Full, Incremental, Differential) y mantiene total fidelidad de metadatos, incluyendo ACLs POSIX, atributos extendidos, optimización de archivos dispersos y propietario/permisos/timestamps precisos.

Una característica distintiva es el modo FIFO, que elimina la sobrecarga de I/O local al hacer que el backend lea los bloques de volumen de Bacula directamente desde un named pipe. Esto significa que el Storage Daemon no escribe en un volumen tradicional — el plugin procesa el flujo de datos en vuelo.

R — Replicación

Están disponibles dos modos de replicación:

Mirror: mantiene una copia 1:1 del origen. En backups Full, los archivos huérfanos (presentes en la réplica pero eliminados del origen) se borran automáticamente.
Retention: mantiene copias versionadas de los archivos, permitiendo la recuperación a un punto en el tiempo desde la propia réplica.

Las características avanzadas de replicación incluyen:

BLAKE3 skip-unchanged: compara hashes del contenido de los archivos para evitar escrituras redundantes
Multi-sitio fan-out: replica a múltiples destinos simultáneamente con límites de bandwidth por destino
Throttling de bandwidth: límites de tasa de transferencia configurables
Grupos de consistencia: coordina la replicación entre múltiples jobs relacionados
Automatización de failover: hooks de verificación de estado, promoción y degradación para la conmutación automática de DR
Integración con snapshots: creación de snapshots pre-replicación en LVM, ZFS o Btrfs

C — Conversión y Normalización

El plugin procesa el flujo de datos de Bacula, gestionando:

Descompresión: los flujos comprimidos con zlib y LZ4 se descomprimen de forma transparente
Cifrado en reposo: cifrado AES-256-GCM opcional para los archivos replicados
Informes de cumplimiento: informes automatizados de RPO/RTO en formatos JSONL, JSON y Markdown

4. Arquitectura

Diagrama de Componentes

┌────────────────────────────────────────────────────────────────────┐
│                    BACULA INFRASTRUCTURE                           │
│                                                                    │
│  ┌──────────┐    ┌──────────────┐    ┌──────────────────┐         │
│  │  File     │───▶│  Storage     │───▶│  Rust cdylib     │         │
│  │  Daemon   │    │  Daemon      │    │  (.so / SD v13)  │         │
│  └──────────┘    └──────────────┘    └────────┬─────────┘         │
│                                                │ canal / FIFO      │
└────────────────────────────────────────────────┼──────────────────┘
                                                 │
                                                 ▼
┌────────────────────────────────────────────────────────────────────┐
│                    PODHEITOR BRC BACKEND (Rust)                     │
│                                                                    │
│  ┌──────────┐  ┌───────────┐  ┌───────────┐  ┌──────────────┐    │
│  │ Record   │─▶│ Pipeline  │─▶│ Policy    │─▶│ File Writer  │    │
│  │ Parser   │  │ (decomp/  │  │ (mirror/  │  │ (Linux/Win)  │    │
│  │          │  │  decrypt) │  │  retention)│  │              │    │
│  └──────────┘  └───────────┘  └───────────┘  └──────┬───────┘    │
│                                                      │            │
│  ┌──────────────────────────────────────────────────┐│            │
│  │ Cross-cutting: Checksum · Manifest · Logging     ││            │
│  │ Throttle · Consistency · Failover · Snapshot     ││            │
│  │ RPO/RTO Reporting · Dashboard                    ││            │
│  └──────────────────────────────────────────────────┘│            │
└──────────────────────────────────────────────────────┼────────────┘
                                                       │
                                                       ▼
                                             ┌──────────────────┐
                                             │   REPLICA TARGET │
                                             │   FILESYSTEM     │
                                             │   (ext4/XFS/     │
                                             │    Btrfs/NFS)    │
                                             └──────────────────┘

Stack Tecnológico

Componente	Tecnología	Propósito
Plugin SD (cdylib)	Rust (edición 2021) — ABI SD Plugin API v13 en clean-room	Integración con SD, canal de comunicación interno, gestión de pipe FIFO
Backend	Rust (edición 2021)	Análisis de registros, procesamiento de flujo, escritura de archivos
Cifrado	AES-256-GCM (autenticado)	Cifrado en reposo
Hashing	BLAKE3	Skip-unchanged por direccionamiento de contenido, verificación de integridad
Compresión	zlib / LZ4	Descompresión de flujo
Serialización	JSON	Informes RPO/RTO, estado del dashboard, manifiesto

Protocolo de Comunicación Interno

El plugin SD y el proceso backend se comunican mediante un protocolo estructurado sobre stdin/stdout:

Fase	Dirección	Contenido
1 — Hello	cdylib → Backend	Versión del protocolo, identificación del plugin
2 — Job Info	cdylib → Backend	Nombre del job, ID, tipo, nivel, timestamp de referencia
3 — Params	cdylib → Backend	Todos los parámetros del plugin (key=value)
4 — Start	cdylib → Backend	Comando `ReplicaStart`
5 — Data	cdylib → Backend	Flujo de registros de Bacula (atributos de archivo + datos)
6 — End	cdylib → Backend	Señal de fin de flujo

En el modo FIFO, las fases 1-4 ocurren mediante el protocolo interno, pero los datos (fase 5) se leen directamente desde un named pipe — evitando el canal interno para maximizar el throughput.

Flujo de Datos — Modo FIFO

┌──────────┐      ┌──────────┐      ┌───────────────┐
│ Bacula   │─────▶│ Named    │─────▶│ BRC Backend   │
│ SD       │      │ Pipe     │      │ (volume       │
│ (writes  │      │ (FIFO)   │      │  block reader)│
│  volume) │      └──────────┘      └───────┬───────┘
└──────────┘                                │
                                            ▼
                                   ┌──────────────────┐
                                   │ Replica Target   │
                                   └──────────────────┘

5. Casos de Uso

5.1 Sitio de DR en Caliente

Escenario: Una organización necesita mantener una copia de DR en caliente de servidores de archivos críticos.

Solución: Configure PodHeitor BRC en modo mirror apuntando a un sistema de archivos de DR (montaje local o NFS). Cada backup sincroniza la réplica automáticamente. En caso de un desastre, los archivos quedan inmediatamente accesibles.

target_base=/mnt/dr_site/replicas
mode=mirror
delete_removed=yes
skip_unchanged=yes

5.2 Recuperación Instantánea de Archivos Near-line

Escenario: Los usuarios solicitan con frecuencia restauraciones individuales de archivos y el proceso tradicional de restauración de Bacula es demasiado lento.

Solución: Use BRC para mantener una réplica actualizada. Cuando un usuario necesite un archivo, simplemente cópielo desde la ruta de réplica — sin necesidad de un job de restauración de Bacula.

target_base=/mnt/fast_recovery
mode=mirror
verify_after=yes

5.3 Actualización de Datos para Desarrollo/Pruebas

Escenario: Los equipos de desarrollo necesitan copias actualizadas regularmente de los datos de producción.

Solución: Apunte BRC a un sistema de archivos accesible por el equipo de desarrollo. Después de cada ciclo de backup, los entornos de dev/pruebas tendrán datos actuales de forma automática.

target_base=/mnt/dev_data
mode=mirror
bandwidth_limit=50M
exclude_patterns=*.log,*.tmp,*.pid

5.4 Evidencia de Cumplimiento y Auditoría

Escenario: Los requisitos regulatorios exigen pruebas de cumplimiento del RPO/RTO.

Solución: Active los informes de cumplimiento de BRC. Cada job genera archivos de evidencia con timestamp en formatos JSONL, JSON y Markdown.

target_base=/mnt/compliant_replica
rpo_report_dir=/var/lib/podheitor/compliance
sla_rpo_secs=14400
sla_rto_secs=3600

5.5 Replicación Multi-sitio

Escenario: Los datos críticos deben replicarse tanto en un SSD local rápido como en una ubicación de DR remota.

Solución: Use el fan-out multi-sitio con límites de bandwidth por destino.

target_base=/mnt/primary_replica
targets=/mnt/fast_ssd;/mnt/remote_dr:bwlimit=10M

5.6 Replicación Cifrada para Datos Sensibles

Escenario: Los archivos replicados contienen datos sensibles que requieren cifrado en reposo.

Solución: Active el cifrado AES-256-GCM.

target_base=/mnt/secure_replica
encrypt_key=0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef

6. Instalación

6.1 Requisitos Previos

PodHeitor Backup Edition 11.x, 14.x o 15.x instalado y en ejecución
Storage Daemon en una distribución Linux compatible
Sistema de archivos de destino de la réplica montado y con permisos de escritura
Para modo FIFO: Device Type = Fifo configurado en el SD

6.2 Instalación mediante RPM (RHEL/Rocky/OEL 8-9)

# Install the package
sudo rpm -Uvh podheitor-replica-sd-2.0.0-1.el9.x86_64.rpm

# Verify installation
ls -la /opt/bacula/lib/bacula/plugins/podheitor-replica-sd.so
ls -la /opt/bacula/lib/bacula/plugins/podheitor-replica-sd-backend

# Create configuration
sudo cat > /opt/bacula/etc/podheitor-replica-sd.conf << 'EOF'
target_base=/mnt/replica_dest
mode=mirror
delete_removed=yes
log_level=info
EOF

# Set permissions
sudo chown bacula:bacula /opt/bacula/etc/podheitor-replica-sd.conf
sudo chmod 640 /opt/bacula/etc/podheitor-replica-sd.conf

# Restart Storage Daemon
sudo systemctl restart bacula-sd

# Verify plugin is loaded
sudo journalctl -u bacula-sd -n 20 | grep -i podheitor

6.3 Instalación mediante DEB (Debian 11-12 / Ubuntu 22.04+)

# Install the package
sudo dpkg -i podheitor-replica-sd_2.0.0_amd64.deb

# Create configuration (same as RPM)
sudo cat > /opt/bacula/etc/podheitor-replica-sd.conf << 'EOF'
target_base=/mnt/replica_dest
mode=mirror
delete_removed=yes
log_level=info
EOF

# Set permissions
sudo chown bacula:bacula /opt/bacula/etc/podheitor-replica-sd.conf
sudo chmod 640 /opt/bacula/etc/podheitor-replica-sd.conf

# Restart Storage Daemon
sudo systemctl restart bacula-sd

6.4 Verificación Post-instalación

# Check the plugin loads
echo "status storage=MySD" | bconsole | grep -i plugin

# Run a test backup
echo "run job=TestBackup yes" | bconsole

# Verify replicated files
ls -la /mnt/replica_dest/

7. Referencia de Configuración

7.1 Archivo de Configuración

El plugin lee los parámetros de /opt/bacula/etc/podheitor-replica-sd.conf y de la directiva Plugin= de Bacula en el recurso Storage.

Formato del archivo de configuración: un key=value por línea. Las líneas que comienzan con # son comentarios.

# PodHeitor BRC Configuration
# /opt/bacula/etc/podheitor-replica-sd.conf

target_base=/mnt/replica_dest
mode=mirror
delete_removed=yes
skip_unchanged=yes
bandwidth_limit=100M
log_level=info

7.2 Tabla Completa de Parámetros — Replicación

Parámetro	Valor predeterminado	Tipo	Descripción
`target_base`	(obligatorio)	ruta	Ruta de destino para los archivos replicados
`mode`	`mirror`	enum	Modo de replicación: `mirror` (copia 1:1) o `retention` (versionado)
`delete_removed`	`yes`	bool	Elimina archivos huérfanos en el backup Full (solo modo mirror)
`skip_unchanged`	`no`	bool	Omite archivos cuyo hash BLAKE3 coincide con la réplica existente
`preserve_acl`	`yes`	bool	Preserva las Listas de Control de Acceso POSIX
`preserve_xattr`	`yes`	bool	Preserva atributos extendidos
`preserve_sparse`	`yes`	bool	Preserva huecos de archivos dispersos (seek-based)
`bandwidth_limit`	`0`	tamaño	Límite de tasa de transferencia. 0 = ilimitado. Admite sufijos K/KB, M/MB, G/GB
`exclude_patterns`	(vacío)	csv	Patrones glob separados por comas a excluir de la replicación
`log_level`	`info`	enum	Nivel de detalle del log: `debug`, `info`, `warn`, `error`
`verify_after`	`no`	bool	Ejecuta verificación de integridad BLAKE3 al finalizar la replicación
`delta_enabled`	`no`	bool	Habilita transferencia delta a nivel de bloque para archivos grandes

7.3 Tabla Completa de Parámetros — Modo FIFO

Parámetro	Valor predeterminado	Tipo	Descripción
`fifo_path`	(vacío)	ruta	Ruta del named pipe para lectura directa de volumen. Requiere `Device Type = Fifo` en el SD de Bacula
`archive_device`	(alias)	ruta	Alias para `fifo_path` — leído automáticamente de la configuración del SD
`fifo_mode`	`no`	bool	Habilita el modo FIFO en la puerta de activación del cdylib

7.4 Tabla Completa de Parámetros — Retention

Parámetro	Valor predeterminado	Tipo	Descripción
`retention_versions`	`0`	int	Número de versiones históricas de archivos a conservar. Establezca > 0 con `mode=retention`

7.5 Tabla Completa de Parámetros — Multi-sitio

Parámetro	Valor predeterminado	Tipo	Descripción
`targets`	(vacío)	string	Destinos adicionales separados por punto y coma. Formato: `/ruta` o `/ruta:bwlimit=10M`

7.6 Tabla Completa de Parámetros — Snapshot

Parámetro	Valor predeterminado	Tipo	Descripción
`snapshot_backend`	`none`	enum	Backend de snapshot pre-replicación: `none`, `lvm`, `zfs`, `btrfs`

7.7 Tabla Completa de Parámetros — Consistencia y Failover

Parámetro	Valor predeterminado	Tipo	Descripción
`consistency_group`	(vacío)	string	Nombre del grupo para replicación coordinada de múltiples jobs
`healthcheck_cmd`	(vacío)	string	Comando externo de verificación de estado. Salida 0 = saludable
`promote_cmd`	(vacío)	string	Comando para promover la réplica al rol primario
`demote_cmd`	(vacío)	string	Comando para degradar el rol primario

7.8 Tabla Completa de Parámetros — Cifrado

Parámetro	Valor predeterminado	Tipo	Descripción
`encrypt_key`	(vacío)	hex	Clave de cifrado AES-256-GCM como cadena hexadecimal de 64 caracteres

7.9 Tabla Completa de Parámetros — Cumplimiento

Parámetro	Valor predeterminado	Tipo	Descripción
`rpo_report_dir`	(vacío)	ruta	Directorio para informes de cumplimiento RPO/RTO. Vacío = `/var/lib/podheitor/rpo`
`sla_rpo_secs`	`14400`	int	Umbral de RPO del SLA en segundos (predeterminado: 4 horas)
`sla_rto_secs`	`3600`	int	Umbral de RTO del SLA en segundos (predeterminado: 1 hora)

7.10 Tabla Completa de Parámetros — Dashboard y Filtro de Job

Parámetro	Valor predeterminado	Tipo	Descripción
`dashboard_enabled`	`no`	bool	Genera estado JSON del dashboard compatible con Bacularis
`job_filter`	(vacío)	string	Prefijo del nombre del job — el plugin se activa solo para jobs coincidentes (puerta cdylib)

Valores Booleanos

Los parámetros booleanos aceptan los siguientes valores:

Verdadero: yes, true, 1, on
Falso: no, false, 0, off (o cualquier otro valor)

8. Dimensionamiento y Requisitos

8.1 Host del Storage Daemon

Recurso	Mínimo	Recomendado	Notas
CPU	4 vCPU	8 vCPU	Más núcleos para cargas de trabajo con cifrado/BLAKE3
RAM	8 GB	16 GB	Adicional para operaciones con archivos grandes y delta
Disco de SO/log	40 GB	60 GB	Incluye espacio de log e informes de cumplimiento
Disco de réplica	Volumen de origen + 20%	Volumen de origen + 50%	En modo retention: multiplique por `retention_versions`
Red	1 Gbps	10 Gbps	Crítico para grandes volúmenes de datos con multi-sitio

8.2 Fórmula de Dimensionamiento de Disco

Disco de réplica (mirror)    = Tamaño de datos de origen × 1,2
Disco de réplica (retention) = Tamaño de datos de origen × retention_versions × 1,1
Informes de cumplimiento     = ~50 KB por job por ejecución

8.3 Dimensionamiento de Red

Escenario	Tasa de Cambio Diaria	Red Recomendada
Pequeño (< 100 GB de origen)	5-10%	1 Gbps
Mediano (100 GB – 1 TB)	5-10%	1 Gbps
Grande (1 TB – 10 TB)	2-5%	10 Gbps
Muy Grande (> 10 TB)	1-2%	10 Gbps + throttling

9. Matriz de Compatibilidad

9.1 Versiones de Bacula

Versión de Bacula CE	Plugin API	Estado
15.0.x	v13	Validado
14.0.x	v13	Compatible
11.0.x	v13	Compatible

9.2 Sistemas Operativos

Distribución	Versiones	Formato de Paquete	Estado
RHEL	8, 9	RPM	Validado
Rocky Linux	8, 9	RPM	Validado
Oracle Linux	8, 9	RPM	Validado
Debian	11, 12	DEB	Compatible
Ubuntu	22.04, 24.04	DEB	Compatible

9.3 Sistemas de Archivos

Sistema de Archivos	ACL	xattr	Disperso	Snapshot	Estado
ext4	Sí	Sí	Sí	No	Validado
XFS	Sí	Sí	Sí	No	Compatible
Btrfs	Sí	Sí	Sí	Sí (nativo)	Compatible
ZFS	Sí	Sí	Sí	Sí (nativo)	Compatible
NFS v4	Parcial	Parcial	No	No	Compatible (destino remoto)

10. Opciones de Backup y Restauración

10.1 Compatibilidad con Niveles de Backup

Nivel	Comportamiento	Efecto de `delete_removed`
Full (F)	Replica todos los archivos del conjunto de backup	Elimina archivos huérfanos de la réplica
Incremental (I)	Replica solo los archivos modificados desde el último backup	Sin eliminación de huérfanos
Differential (D)	Replica los archivos modificados desde el último Full	Sin eliminación de huérfanos

10.2 Modos de Replicación

Modo	`delete_removed`	Manejo de Archivos	Ideal Para
mirror	yes	Copia 1:1, huérfanos eliminados en Full	DR, recuperación instantánea
mirror	no	Copia 1:1, huérfanos conservados	Replicación conservadora
retention	N/A	Copias versionadas (hasta `retention_versions`)	Recuperación a punto en el tiempo

10.3 Procedimientos de Recuperación

Acceso Directo a Archivos (Sin Necesidad de Restauración)

# Files are already available at the replica target
cp /mnt/replica_dest/path/to/needed/file /restore/location/

# Or create a symlink for applications
ln -s /mnt/replica_dest/app/data /app/data

Restauración Tradicional de Bacula (Aún Compatible)

El plugin no interfiere con las operaciones normales de restauración de Bacula. Todos los procedimientos estándar de restauración continúan funcionando de forma independiente.

*restore
Select job=TestBackup
...

10.4 Procedimiento de Recuperación Instantánea

Verifique la integridad de la réplica: compruebe el manifiesto y ejecute la verificación si está configurada
Monte/exponga la ruta de réplica a la aplicación
Inicie los servicios apuntando a la ubicación de réplica
(Opcional) Ejecute la restauración de Bacula en segundo plano para reconstruir el almacenamiento primario

11. Ejemplos de Configuración

11.1 Replicación Mirror Básica

Escenario: Réplica 1:1 simple para recuperación instantánea de archivos.

Archivo de configuración (/opt/bacula/etc/podheitor-replica-sd.conf):

target_base=/mnt/replica_dest
mode=mirror
delete_removed=yes
log_level=info

Recurso Device del Bacula SD:

Device {
  Name = FileStorage
  Media Type = File1
  Archive Device = /mnt/bacula/volumes
  LabelMedia = yes
  Random Access = yes
  AutomaticMount = yes
  RemovableMedia = no
  AlwaysOpen = no
}

11.2 Modo FIFO (Replicación sin Volumen)

Escenario: Eliminar el I/O de volumen local — los datos fluyen directamente a la réplica.

Archivo de configuración:

target_base=/mnt/replica_dest
mode=mirror
fifo_path=/tmp/podheitor_fifo
job_filter=Replicate-
log_level=info

Recurso Device del Bacula SD:

Device {
  Name = ReplicaFIFO
  Media Type = FIFO
  Device Type = Fifo
  Archive Device = /tmp/podheitor_fifo
  LabelMedia = yes
  Random Access = no
  AutomaticMount = no
  RemovableMedia = no
  AlwaysOpen = no
  MaximumOpenWait = 60
}

Recurso FileSet de Bacula:

FileSet {
  Name = "ReplicaFileSet"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
      AclSupport = yes
      XattrSupport = yes
    }
    File = /etc
    File = /home
    File = /var/www
  }
  Exclude {
    File = /etc/shadow
    File = *.tmp
  }
}

Recurso Job de Bacula:

Job {
  Name = "Replicate-DailyFiles"
  Type = Backup
  Client = server-fd
  FileSet = "ReplicaFileSet"
  Storage = SD-Replica
  Pool = ReplicaPool
  Schedule = "DailySchedule"
  Messages = Standard
  Priority = 10
}

11.3 Modo Retention con Versionado

Escenario: Conservar 5 versiones de cada archivo para recuperación a punto en el tiempo.

Archivo de configuración:

target_base=/mnt/versioned_replica
mode=retention
retention_versions=5
skip_unchanged=yes
log_level=info

11.4 Fan-out Multi-sitio con Límites de Bandwidth

Escenario: Replicar a SSD local rápido y DR remoto con throttling.

Archivo de configuración:

target_base=/mnt/fast_local
targets=/mnt/fast_local;/mnt/remote_dr:bwlimit=10M
mode=mirror
skip_unchanged=yes
bandwidth_limit=100M

11.5 Enterprise: Cifrado + Cumplimiento + Failover

Escenario: Entorno regulado que requiere réplicas cifradas, evidencia de cumplimiento y failover automatizado.

Archivo de configuración:

target_base=/mnt/secure_replica
mode=mirror
delete_removed=yes
skip_unchanged=yes

# Encryption (AES-256-GCM)
encrypt_key=a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2

# Compliance reporting
rpo_report_dir=/var/lib/podheitor/compliance
sla_rpo_secs=14400
sla_rto_secs=3600

# Consistency group
consistency_group=critical-data

# Failover automation
healthcheck_cmd=/opt/scripts/check_primary.sh
promote_cmd=/opt/scripts/promote_replica.sh
demote_cmd=/opt/scripts/demote_primary.sh

# Snapshot before replication
snapshot_backend=lvm

# Post-replication integrity check
verify_after=yes

log_level=info

11.6 Configuración de Alto Rendimiento

Escenario: Gran volumen de datos (> 1 TB) con mínima sobrecarga.

Archivo de configuración:

target_base=/mnt/fast_nvme/replica
mode=mirror
fifo_path=/tmp/podheitor_fifo
skip_unchanged=yes
delta_enabled=yes
bandwidth_limit=0
preserve_sparse=yes
log_level=warn

11.7 Ejemplos de FileSet Orientados a la Restauración

Servidor de archivos general:

FileSet {
  Name = "FileServer-Full"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
      AclSupport = yes
      XattrSupport = yes
      OneFS = no
    }
    File = /srv/shares
    File = /home
  }
  Exclude {
    File = *.tmp
    File = *.bak
    File = /home/*/.cache
    File = /home/*/Downloads
  }
}

Archivos de configuración de base de datos (no los datos):

FileSet {
  Name = "DB-ConfigFiles"
  Include {
    Options {
      Signature = SHA256
      Compression = GZIP
    }
    File = /etc/postgresql
    File = /etc/mysql
    File = /var/lib/pgsql/data/postgresql.conf
    File = /var/lib/pgsql/data/pg_hba.conf
  }
}

Aplicación web:

FileSet {
  Name = "WebApp-Assets"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
      AclSupport = yes
      XattrSupport = yes
    }
    File = /var/www
    File = /etc/nginx
    File = /etc/apache2
  }
  Exclude {
    File = /var/www/*/node_modules
    File = /var/www/*/.git
    File = *.log
  }
}

12. Procedimientos Operativos

12.1 Iniciando un Job de Replicación

# Via bconsole
echo "run job=Replicate-DailyFiles level=Full yes" | bconsole

# Check status
echo "status dir" | bconsole

12.2 Monitoreo de la Replicación

# Check backend logs
tail -f /opt/bacula/working/podheitor-replica-sd-backend.log

# Check replicated files
find /mnt/replica_dest -newer /tmp/last_check -type f | wc -l

# Check compliance reports
ls -la /var/lib/podheitor/compliance/
cat /var/lib/podheitor/compliance/*latest*.md

12.3 Verificando la Integridad de la Réplica

# If verify_after=yes (automatic)
grep "VERIFY" /opt/bacula/working/podheitor-replica-sd-backend.log

# Manual verification
diff -r /original/path /mnt/replica_dest/original/path

12.4 Procedimiento de Failover

Automático (si healthcheck_cmd está configurado): el plugin ejecuta la verificación de estado después de cada job. Si el primario no está disponible, el promote_cmd se ejecuta automáticamente.

Manual:

# Verify replica is current
stat /mnt/replica_dest/critical/data

# Promote replica
/opt/scripts/promote_replica.sh

# Update application configuration to point to replica
systemctl restart application

13. Seguridad

13.1 Cifrado en Reposo

PodHeitor BRC admite cifrado AES-256-GCM para todos los archivos replicados:

Algoritmo: AES-256-GCM (cifrado autenticado)
Formato de clave: cadena hexadecimal de 64 caracteres (clave de 256 bits)
Implementación: AES-256-GCM con nonce único por archivo, implementado en Rust para operaciones criptográficas con seguridad de memoria
Alcance: solo el contenido del archivo (los nombres de archivos y la estructura de directorios permanecen visibles)

Gestión de claves:

Almacene la clave en el archivo de configuración con permisos restrictivos (chmod 640)
Archivo de configuración propiedad de bacula:bacula
Nunca confirme claves en el control de versiones
Rote las claves actualizando la configuración y ejecutando un nuevo backup Full

13.2 Permisos de Archivos

# Plugin binaries
-rwxr-xr-x root:bacula /opt/bacula/lib/bacula/plugins/podheitor-replica-sd.so
-rwxr-xr-x root:bacula /opt/bacula/lib/bacula/plugins/podheitor-replica-sd-backend

# Configuration
-rw-r----- bacula:bacula /opt/bacula/etc/podheitor-replica-sd.conf

# Replica target
drwxr-xr-x bacula:bacula /mnt/replica_dest

13.3 Consideraciones de Red

El plugin opera completamente en el host del Storage Daemon — sin comunicación de red más allá de lo que Bacula ya utiliza
Para destinos de réplica montados mediante NFS, asegure NFS v4 con Kerberos o restrinja el acceso por IP
Los informes de cumplimiento contienen metadatos de jobs — restrinja el acceso al directorio de informes

13.4 Seguridad de Memoria

PodHeitor BRC está implementado íntegramente en Rust, lo que garantiza seguridad de memoria por diseño — sin buffer overflows, sin vulnerabilidades use-after-free, sin condiciones de carrera. A diferencia de los plugins escritos en C o C++, el compilador de Rust elimina en tiempo de compilación toda una clase de vulnerabilidades de seguridad, convirtiendo a BRC en una opción más segura para entornos que procesan datos sensibles o regulados.

14. Cumplimiento e Informes

14.1 Informes de RPO/RTO

Cuando rpo_report_dir está configurado, el plugin genera tres formatos de informe por job:

Formato	Archivo	Propósito
JSONL	`{job_name}_rpo.jsonl`	Registro de eventos de solo anexado para procesamiento automatizado
JSON	`{job_name}_rpo_latest.json`	Instantánea del estado actual para dashboards
Markdown	`{job_name}_rpo_report.md`	Informe legible por humanos para auditores

14.2 Contenido de los Informes

Cada informe incluye:

Nombre, ID y hora de finalización del job
Nivel del backup (Full/Incremental/Differential)
Cantidad de archivos y total de bytes replicados
Medición de RPO: tiempo desde la última replicación exitosa
Estimación de RTO: tiempo de recuperación desde la réplica
Estado de cumplimiento del SLA (aprobado/reprobado respecto a los umbrales configurados)
Estado del cifrado

14.3 Umbrales de SLA

Parámetro	Valor predeterminado	Significado
`sla_rpo_secs`	14400 (4h)	Tiempo máximo aceptable entre replicaciones
`sla_rto_secs`	3600 (1h)	Tiempo máximo aceptable de recuperación

Los informes indican claramente APROBADO o REPROBADO para cada SLA, facilitando las revisiones de auditoría.

15. Consideraciones de Rendimiento

15.1 Características de Optimización

Característica	Impacto	Cuándo Usar
`skip_unchanged`	Reduce las escrituras en un 50-90% en cargas de trabajo incrementales	Siempre recomendado para grandes volúmenes de datos
`delta_enabled`	Reduce la transferencia de archivos grandes con pequeños cambios	Archivos grandes (bases de datos, VMs)
`bandwidth_limit`	Evita la saturación del almacenamiento compartido	Infraestructura compartida
Modo FIFO	Elimina el I/O doble (escritura de volumen + escritura de réplica)	Jobs de replicación dedicados
`preserve_sparse`	Mantiene la eficiencia de archivos dispersos	Discos de VM, bases de datos

15.2 Consejos de Rendimiento

Use el modo FIFO para jobs de replicación dedicados — elimina la sobrecarga de I/O de volumen
Active skip_unchanged — el hashing BLAKE3 es rápido (~5 GB/s) y evita escrituras innecesarias
Use compresión LZ4 en el FileSet — más rápida que GZIP con buena tasa de compresión
Dimensione el disco de réplica según el patrón de I/O — se recomiendan SSDs para cargas de acceso aleatorio
Configure un bandwidth_limit apropiado al compartir almacenamiento con cargas de trabajo de producción
Use log_level=warn en producción para reducir el I/O de log

16. Resolución de Problemas

16.1 Problemas Comunes

Síntoma	Causa	Solución
El plugin no carga	`.so` ausente en el directorio de plugins	Verifique `Plugin Directory` en la configuración del SD
Backend no encontrado	El binario no está en la ruta esperada	Compruebe `/opt/bacula/lib/bacula/plugins/podheitor-replica-sd-backend`
Permiso denegado	Propiedad incorrecta en la configuración o el destino	`chown bacula:bacula` en la configuración y el destino
Timeout del FIFO	Named pipe no creado	Asegúrese de que `Device Type = Fifo` y que `Archive Device` coincida con `fifo_path`
ACLs no preservadas	Sistema de archivos montado sin ACL	Remonte con `mount -o acl` o use `acl` en `/etc/fstab`
Alto uso de CPU	Hashing BLAKE3 en muchos archivos	Comportamiento esperado — deshabilite `skip_unchanged` si es inaceptable
Informe RPO ausente	Directorio sin permisos de escritura	Verifique los permisos de `rpo_report_dir`

16.2 Ubicación de los Logs

Log	Ruta	Contenido
Log del backend	`/opt/bacula/working/podheitor-replica-sd-backend.log`	Operaciones del plugin
Log del SD	`/opt/bacula/log/bacula-sd.log`	Mensajes del shim (con prefijo `podheitor:`)
Cumplimiento	`{rpo_report_dir}/`	Informes RPO/RTO

16.3 Modo Debug

Activar el registro detallado:

log_level=debug

Verificar la salida del backend:

tail -f /opt/bacula/working/podheitor-replica-sd-backend.log

17. Evidencia Validada

17.1 Entorno de Laboratorio

Componente	Versión	Host
Bacula CE	15.0.3	192.168.15.105
SO	Oracle Linux 9	192.168.15.105
Plugin	PodHeitor BRC 2.0.0	192.168.15.105

17.2 Resultados de las Pruebas

Prueba	ID del Job	Estado	Detalles
Reinstalación de RPM + reinicio del servicio	—	OK	Instalación limpia, servicio activo
Backup Full mediante FIFO	786	T (Terminado con Éxito)	3 archivos, 648 bytes replicados
Generación de informe de cumplimiento	786	OK	Informes JSONL/JSON/MD generados

17.3 Comandos de Verificación

# Verify package installation
rpm -qa | grep podheitor

# Verify service is running
systemctl status bacula-sd

# Check last job status
echo "list jobs last" | bconsole

# Verify replica files
ls -la /mnt/replica_dest/

18. Roadmap

Característica	Estado	Objetivo
Replicación mirror	GA	v2.0.0
Modo retention	GA	v2.0.0
Modo FIFO	GA	v2.0.0
ACL/xattr/disperso	GA	v2.0.0
BLAKE3 skip-unchanged	GA	v2.0.0
Cifrado AES-256-GCM	GA	v2.0.0
Grupos de consistencia	GA	v2.0.0
Automatización de failover	GA	v2.0.0
Cumplimiento RPO/RTO	GA	v2.0.0
Paquetes RPM/DEB	GA	v2.0.0
Dashboard Bacularis	Planificado	v0.5.0
Federación multi-SD	Planificado	v0.6.0
Destinos en la nube (S3/Azure/GCS)	Planificado	v0.7.0
Conversión con soporte para VM	Planificado	v0.8.0
Soporte para SD en Windows	Backlog	—

19. Información Comercial

Acerca de

PodHeitor BRC es desarrollado y mantenido por Heitor Faria, con profunda experiencia en el ecosistema Bacula, backup empresarial y soluciones de recuperación ante desastres.

Licenciamiento

Licencia comercial — por Storage Daemon. Las organizaciones que migran desde Bacula Enterprise u otras soluciones comerciales logran típicamente más del 50% de ahorro en costos de licenciamiento, manteniendo funcionalidades equivalentes o superiores.

Servicio	Descripción
Licencia enterprise	Licencia de despliegue en producción con actualizaciones
Soporte prioritario	Acceso directo al desarrollador para la resolución de incidencias
Implementación	Instalación, configuración y ajuste fino para su entorno
Consultoría en DR	Proyectos personalizados de recuperación ante desastres y arquitectura

¿Listo para evaluar?

Agende una consultoría técnica gratuita — analizaremos su entorno de backup actual y le mostraremos exactamente cómo PodHeitor BRC puede reducir el RTO y la carga operativa en su infraestructura.

WhatsApp: +1 786 726-1749
Correo electrónico: heitor@opentechs.lat
Consultoría gratuita: podheitor.com/consultoria-gratis

Disponível em: Português (Portugués, Brasil)English (Inglés)Español