Whitepaper — PodHeitor Notes / Domino - PodHeitor — Backup, Replicação e Recuperação de Desastres

Respaldo HCL Notes / Domino consistente. Bases NSF, transaction logging integrado, restore de mailbox individual, soporte cluster Domino y DAOS.

NSF online backup — sin cerrar bases, sin impacto en usuario.
Transaction logging — PITR al segundo vía translog.
Restore mailbox-level — restauración de NSF individual o documento específico.
DAOS-aware — respaldo eficiente con Domino Attachment Object Service.
Cluster Domino — coordinación cross-server.

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 →

Índice

Resumen ejecutivo
Introducción y contexto de mercado
Descripción general de la arquitectura
Modos de backup en detalle
Matriz de funcionalidades
Guía de instalación
Referencia de configuración
Ejemplos de FileSet
Dimensionamiento y planificación de capacidad
Informe de rendimiento
Matriz de compatibilidad
Seguridad
Monitoreo
Guía de solución de problemas
Casos de uso y escenarios de implementación
Comparación con otros enfoques
Hoja de ruta
Conclusión
Información de contacto
Legal / derechos de autor

1. Resumen ejecutivo

HCL Domino — anteriormente IBM Lotus Domino — sigue siendo una plataforma crítica de colaboración y correo electrónico para miles de organizaciones en gobiernos, servicios financieros, telecomunicaciones y salud en todo el mundo. Su formato de base de datos NSF (Notes Storage Facility), el Domino Directory, los buzones de correo y los transaction logs de archivado presentan desafíos que las herramientas genéricas de backup a nivel de archivo no pueden resolver: los archivos NSF permanecen abiertos y son escritos activamente por el proceso Domino, los transaction logs deben archivarse en secuencia para la recuperación point-in-time, y la restauración granular a nivel de elemento (un único buzón, un único documento por UNID o por asunto) es un requisito operativo diario para los flujos de trabajo de cumplimiento y retención legal.

El PodHeitor Notes/Domino Backup Plugin for Bacula cubre esta brecha. Ofrece la primera integración de backup de Domino con conciencia de aplicación en todo el ecosistema Bacula — Bacula Enterprise no cuenta con ningún plugin Notes/Domino en ninguna versión, desde la 6.2.x hasta la 18.2.x. El plugin es una implementación nativa en Rust para PodHeitor Backup+, de nivel de producción, que se integra de forma nativa con la API C IBM/HCL Notes (libnotes) a través de la familia Backup API (NSFBackupStart, NSFBackupStop, NSFBeginArchivingLogs, NSFRecoverDatabases). Tres modos operativos complementarios cubren todos los escenarios del mundo real: backup Full en línea mediante la Backup API, cadenas incremental/diferencial basadas en transaction log para una verdadera recuperación point-in-time (PITR), y restauración granular a nivel de buzón, documento o elemento de diseño. Una herramienta CLI complementaria convierte archivos NSF a EML y MBOX para e-discovery y migración IMAP.

Desde el punto de vista empresarial, el plugin extiende PodHeitor Backup con capacidades de DR Domino de nivel empresarial a una fracción del costo de las alternativas comerciales premium. Para cualquier organización que ejecute HCL Domino con PodHeitor Backup, este plugin es el único camino application-consistent e integrado con el catálogo hacia una postura de backup sólida y defendible.

2. Introducción y contexto de mercado

2.1 HCL Domino en producción hoy

A pesar de décadas de predicciones sobre su declive, IBM Notes / HCL Domino mantiene una base instalada considerable. Las estimaciones del sector sitúan a la comunidad activa de usuarios Domino en un rango de 60–80 millones de puestos a nivel mundial. Su concentración es especialmente elevada en:

Gobierno y sector público — ministerios nacionales, agencias militares y administraciones municipales que estandarizaron en Lotus Notes en los años noventa y no han migrado debido al volumen de aplicaciones nativas Notes (formularios de flujo de trabajo, agentes, plantillas de diseño).
Servicios financieros y banca — particularmente en América Latina, Europa Central y Asia, donde los requisitos de cumplimiento llevaron a una profunda integración de aplicaciones con bases de datos Notes.
Telecomunicaciones — grandes operadoras que construyeron sistemas de soporte operativo (OSS) y bases de datos de clientes como aplicaciones NSF.
Salud — sistemas de información hospitalaria y flujos de trabajo de gestión de pacientes ejecutados como agentes Domino.

Las principales características técnicas que explican la presencia continua de Domino incluyen:

El modelo de almacenamiento de documentos NSF, que se adapta de forma natural a las aplicaciones de flujo de trabajo y no requiere la rigidez de esquema de las bases de datos relacionales.
La replicación integrada de Domino, que ha proporcionado sincronización multi-master entre oficinas geográficamente distribuidas durante tres décadas.
Un rico ecosistema de aplicaciones nativas Notes (decenas de miles por empresa) que no pueden migrarse de forma trivial a sucesores basados en la web.
La arquitectura autónoma del servidor Domino — correo, calendario, directorio y alojamiento de aplicaciones en un único proceso — que reduce la complejidad operativa para equipos de TI más pequeños.

2.2 El desafío del backup de NSF

Los archivos NSF presentan una combinación única de desafíos para las herramientas de backup:

Archivos en uso. El proceso Domino mantiene todos los archivos NSF activos abiertos con bloqueos consultivos. Una copia de archivo en bruto realizada mientras Domino está en ejecución capturará una instantánea internamente inconsistente que puede no ser recuperable. El único camino seguro es utilizar la Backup API, que coordina con el motor Domino para producir una copia consistente.
Dependencia del transaction log. Las organizaciones que habilitan el archivado de transaction log (la configuración recomendada para cualquier servidor en producción) deben respaldar no solo los archivos NSF, sino también la secuencia de extensiones de log S*.TXN. Restaurar un NSF sin sus logs posteriores deja la base de datos en el punto del backup Full, potencialmente horas o días por detrás del estado actual.
Continuidad del DBIID. Cada NSF lleva un Database Instance ID (DBIID) que lo vincula a un flujo específico de transaction log. Un compact o reconstrucción estructural restablece el DBIID, invalidando todos los backups de log incrementales previos. El software de backup debe rastrear esto y promover automáticamente el siguiente incremental a Full.
Restauración granular. Los equipos de soporte técnico y cumplimiento necesitan con frecuencia recuperar un único mensaje de correo electrónico de un buzón o un único documento de una base de datos de aplicación sin restaurar el NSF completo en un entorno de preparación.
Escala. Los entornos Domino de gran escala contienen decenas de miles de archivos NSF (correo individual, aplicaciones compartidas, archivos, directorio). Un backup que serializa el acceso a cada archivo no puede completarse dentro de la ventana nocturna.

2.3 Por qué los enfoques existentes son insuficientes

Herramienta	Soporte Domino	Veredicto
PodHeitor Backup (nativo, sin plugin)	Solo a nivel de archivo — respalda archivos `.nsf` en bruto mientras Domino está activo	Inseguro — instantáneas inconsistentes; sin envío de log
Bacula Enterprise	Sin plugin Notes/Domino en ninguna versión (6.2.x–18.2.x verificado)	No aplica
Veeam	Sin agente nativo para Domino	Requiere scripts de quiesce a nivel de SO; sin restauración a nivel de elemento
Commvault	Commvault IntelliSnap con agente Domino (propietario, costoso)	Disponible a precio premium; sin integración con Bacula
NetBackup	NetBackup for Lotus Notes (descontinuado / fin de vida)	Legado; no disponible para versiones modernas de Domino
Scripts shell personalizados	Copia sin conexión con Domino detenido, o wrapper nbackup	Requiere tiempo de inactividad del servicio; sin restauración granular; sin catálogo

La brecha es inequívoca: ninguna solución de backup compatible con código abierto estaba integrada con Domino a nivel de motor antes de este plugin. La combinación de PodHeitor Backup y el PodHeitor Notes/Domino plugin es el único camino hacia un backup Domino application-consistent, integrado con el catálogo y granular en una plataforma de código abierto.

2.4 El enfoque PodHeitor

El plugin sigue la misma filosofía de diseño que la familia de plugins PodHeitor: implementación nativa en Rust, desarrollo por fases con pruebas de regresión automatizadas, cero dependencias de tiempo de ejecución más allá de las herramientas de la plataforma de destino, y una arquitectura de canal interno otimizado que hace que la separación plugin/backend sea estable ante los cambios de API interna de Bacula. Su superficie de opciones está deliberadamente modelada según el vocabulario de la familia de plugins Bacula Enterprise, de modo que los operadores familiarizados con los plugins BE MySQL, PostgreSQL u Oracle reconocen inmediatamente la forma de configuración.

3. Descripción general de la arquitectura

3.1 Diseño de dos componentes

El plugin está compuesto por dos binarios que se distribuyen en el mismo paquete:

Componente	Archivo	Función
Plugin Bacula FD (plugin FD)	`/opt/bacula/plugins/podheitor-notes-fd.so`	Cargado por `bacula-fd` en tiempo de ejecución; implementa la API de plugin Bacula
Binario backend (sidecar)	`/opt/bacula/bin/podheitor-notes-backend`	Creado como proceso hijo por el plugin FD por cada Job; gestiona toda la interacción con Domino vía libnotes

Esta separación ofrece tres ventajas clave:

Aislamiento. El plugin FD es mínimo y estable. Toda la lógica que interactúa con la API C Notes vive en el sidecar backend. Un fallo o bloqueo en el backend no puede corromper el proceso bacula-fd.
Actualizabilidad. El backend puede actualizarse sin reiniciar bacula-fd. Solo el plugin FD interactúa con el ABI del plugin Bacula.
Capacidad de prueba. El binario backend puede ejecutarse directamente en pruebas de integración contra un servidor Domino real sin involucrar a Bacula.

3.2 Integración con libnotes

El binario sidecar se integra con Domino exclusivamente a través de la API C IBM/HCL Notes (libnotes.so en Linux, nnotes.dll en Windows). La biblioteca se carga en tiempo de ejecución mediante dlopen / LoadLibrary, lo que significa:

Ningún encabezado o binario del HCL SDK está incluido en el paquete del plugin.
El operador instala el HCL Notes/Domino C API SDK una vez (descarga de HCL con aceptación de EULA en el host FD), y el plugin lo encuentra en tiempo de ejecución.
Los binarios del plugin no incorporan ni redistribuyen ninguna propiedad intelectual de HCL/IBM.

3.3 Disposición de rutas virtuales

Cada Job Bacula respaldado por el plugin genera objetos de archivo virtual en el catálogo Bacula siguiendo esta convención de nomenclatura:

@notes/server/<DominoServerName>/                        # raíz del job
@notes/server/<server>/dbiid/<dbiid_hex>/              # ancla DBIID
@notes/server/<server>/full/<rel_nsf_path>             # flujo NSF Full
@notes/server/<server>/txnlog/<NNNNNNNN>.TXN           # extensión de log archivada
@notes/server/<server>/meta/server_id_hash.json         # huella del archivo ID
@notes/server/<server>/meta/notes_ini.snapshot          # claves seleccionadas de notes.ini
@notes/server/<server>/meta/catalog.json                # inventario de bases de datos

Esto refleja la convención de nomenclatura @postgresql/wal/... del plugin PodHeitor PostgreSQL, de modo que los operadores familiarizados con ese plugin reconocen inmediatamente la disposición.

3.4 Frontera de licenciamiento y postura de copyright

El plugin es 100% Rust puro, sin código fuente C/C++. El ABI del plugin Bacula se satisface mediante el crate bacula-fd-abi (una reimplementación en sala limpia de las formas ABI del plugin FD — las formas de API no están protegidas por derechos de autor conforme a Google v. Oracle, 593 U.S. 1, 2021) y el framework framework de plugin PodHeitor. Ningún código fuente AGPL de Bacula está enlazado estáticamente ni copiado. La cadena pInfo.plugin_license = "Bacula AGPLv3" satisface la compuerta ABI en tiempo de ejecución del cargador del plugin Bacula FD y no constituye una reivindicación de derechos de autor.

4. Modos de backup en detalle

4.1 Backup Full en línea (Backup API)

Cómo funciona

El modo full usa la Domino Backup API de IBM/HCL para coordinar una instantánea consistente y en línea de cada base de datos NSF sin detener el servidor Domino. La secuencia es:

  NSFBackupStart(dbPath, hDB, &logID)
       │  ─── registra el DBIID y congela el marcador de posición del log
       │
       ├── transmite el flujo de bytes NSF vían internal channel a Bacula
       │   (tokio async I/O + rayon parallelism para multi-DB)
       │
  NSFBackupStop(dbPath, hDB, logID, &archiveInfo)
       │  ─── actualiza el marcador de log en el catálogo Domino
       │
  almacena DBIID + secuencia de log en los metadatos del vpath

El backup se ejecuta mientras Domino está completamente en línea y atendiendo usuarios. Sin quiesce, sin interrupción del servicio.

Seguimiento de DBIID

Después de cada Full, el plugin registra el DBIID actual del NSF. En el siguiente Job Incremental o Diferencial, el plugin consulta NSFGetDBIID y compara. Si el DBIID ha cambiado (lo que ocurre tras un compact -c o una reconstrucción estructural), el plugin emite un Jmsg M_WARNING y promueve automáticamente el nivel del Job de Incremental a Full, garantizando que la continuidad del log nunca se rompa de forma silenciosa.

Cuándo usar

Línea base Full semanal o mensual para todas las bases de datos NSF
Cualquier escenario que requiera un punto de restauración completo y autónomo
Entornos con transaction log circular (Full es el único modo disponible en ese caso)
Inicialización de un nuevo servidor Domino desde backup

Ventajas y desventajas

Aspecto	Evaluación
En línea / sin tiempo de inactividad	Excelente — la Backup API coordina con el motor Domino
Consistencia	Excelente — DBIID + marcador de log garantizan consistencia interna
Completitud	Excelente — autónomo; sin dependencia de cadena de log
Velocidad	Moderada — lee todas las páginas NSF; mejorada con parallel_nsf
Tamaño del backup	Tamaño total del NSF; se recomienda compresión zstd
Simplicidad de restauración	Excelente — restauración de NSF único, sin reproducción de log
Idoneidad para entornos grandes	Buena con parallel_nsf=4–8

4.2 Incremental y diferencial basados en transaction log

Cómo funciona

Cuando Domino está configurado para transaction log en modo archivado (TRANSLOG_Style=1 en notes.ini), el motor Domino escribe todas las modificaciones de la base de datos en extensiones de log numeradas secuencialmente (S0000000.TXN, S0000001.TXN, …). Estas extensiones se acumulan en el directorio TRANSLOG_Path hasta ser archivadas explícitamente.

El modo incremental del plugin:

Abre una ventana de archivado con NSFBeginArchivingLogs.
Enumera todas las extensiones S*.TXN más recientes que el marcador de secuencia de log registrado por el último backup Full.
Envía cada extensión como un archivo virtual separado vían internal channel.
Cierra la ventana con NSFEndArchivingLogs, señalando a Domino que las extensiones enviadas pueden eliminarse del directorio de log primario.

El modo diferencial funciona de forma idéntica, pero usa el marcador de secuencia de log solo del último Full, ignorando cualquier marcador Incremental intermedio. Esto produce un conjunto diferencial único que, combinado con el Full, es suficiente para la recuperación completa.

  Día 0:  Full ──► flujo NSF + marcador de log M0
  Día 1:  Incremental ──► extensiones TXN M0..M1
  Día 2:  Incremental ──► extensiones TXN M1..M2
  Día 3:  Differential ──► extensiones TXN M0..M3  (vuelve a la línea base Full)
  Día 4:  Incremental ──► extensiones TXN M3..M4

Verificación previa

Antes de cualquier Job incremental o diferencial, el plugin llama a NSFGetTransactionalLoggerInfo. Si el resultado indica modo de log circular, el plugin aborta con un Jmsg M_FATAL claro y accionable que señala las directivas específicas de notes.ini necesarias para habilitar el log de archivado. El script auxiliar podheitor-notes-enable-archive-logging.sh automatiza el cambio en notes.ini.

Cuándo usar

Backups incrementales diarios o por hora para minimizar la ventana de backup y el consumo de almacenamiento
Entornos que requieren recuperación point-in-time (PITR) a una marca de tiempo o secuencia de log específica
Cualquier servidor Domino en producción con transaction log en modo archivado habilitado

Ventajas y desventajas

Aspecto	Evaluación
RPO	Excelente — sub-horario con programaciones incrementales frecuentes
Ventana de backup	Excelente — solo se envían nuevas extensiones de log, no el NSF completo
Eficiencia de almacenamiento	Excelente — las extensiones TXN son pequeñas fracciones del tamaño del NSF
Log de archivado requerido	Sí — el modo de log circular solo admite Full
Seguimiento de DBIID	Automático — la discrepancia de DBIID promueve automáticamente a Full
Complejidad de restauración	Moderada — requiere Full + reproducción de log ordenada
Capacidad PITR	Sí — parámetros target_time o target_log_seq

4.3 Restauración granular

Cómo funciona

La restauración granular opera como una operación posterior a la restauración sobre un NSF ya recuperado. Después de que la restauración full estándar o PITR reconstruye el NSF de destino, el motor de restauración granular selecciona un subconjunto del contenido y lo entrega al operador sin necesidad de montar la base de datos completa en el entorno activo.

Se admiten cuatro niveles de granularidad:

Buzón de correo — restaura un buzón de usuario completo (mail/username.nsf), ACL preservadas mediante NSFDbReadACL / NSFDbStoreACL.
Documento por UNID — restaura exactamente una Note identificada por su Universal Note ID de 32 caracteres hexadecimales.
Documento por expresión regular de asunto — restaura todas las Notes cuyo campo Asunto coincide con una expresión regular.
Elemento de diseño — restaura un único formulario, vista o agente por nombre.

Existen dos rutas de implementación:

Ruta libnotes (principal) — usa NIFOpenCollection / NIFReadEntries y NSFNoteOpenByUNID en una instancia Domino en ejecución. Fidelidad completa de ACL y metadatos.
Lector NSF en Rust (alternativa) — un lector puro en Rust, sin SDK, para archivos NSF fríos, utilizado en hosts donde libnotes no está instalado (por ejemplo, una estación de administración Linux Bacula que extrae un buzón a EML sin una instalación Domino completa). Solo lectura; algunos elementos cifrados pueden no descifrarse sin libnotes.

Cuándo usar

Recuperación de soporte técnico de un único mensaje de correo electrónico eliminado
Retención legal — extraer todos los correos del buzón de un empleado que dejó la organización
Auditoría de cumplimiento — recuperar una versión específica de un documento por UNID
Reversión de elemento de diseño — restaurar un formulario de flujo de trabajo o una vista a una versión anterior

4.4 Exportación NSF → EML / MBOX

La herramienta CLI complementaria podheitor-notes-convert convierte un archivo NSF a formatos estándar abiertos para e-discovery, migración IMAP o archivado:

EML — un archivo RFC 5322 por Note, adecuado para la ingestión directa por plataformas de e-discovery (Relativity, Logikcull) y servidores IMAP.
MBOX — EML concatenado, adecuado para Thunderbird, Apple Mail y archivadores compatibles con mbox.
PST — diferido a v1.1 tras un indicador de característica --enable-pst.

podheitor-notes-convert 
  --in /tmp/restore/mail/jdoe.nsf 
  --format eml 
  --out /tmp/jdoe-eml/

5. Matriz de funcionalidades

Funcionalidad	Full (Backup API)	Incremental / Differential	Restauración Granular
Backup en línea (sin tiempo de inactividad)	Sí	Sí	—
Application-consistent	Sí	Sí	—
PITR (recuperación point-in-time)	No	Sí	—
Log de archivado requerido	No	Sí	No
Seguimiento de continuidad DBIID	Sí	Sí	—
Restauración a nivel de buzón	—	—	Sí
Restauración de documento por UNID	—	—	Sí
Restauración de documento por expresión regular de asunto	—	—	Sí
Restauración de elemento de diseño	—	—	Sí
ACL preservada en la restauración	Sí	Sí	Sí
Compresión zstd (in-stream)	Sí	Sí	—
Compresión lz4 (in-stream)	Sí	Sí	—
Backup NSF paralelo (parallel_nsf)	Sí	No	—
Envío de log paralelo (parallel_logs)	—	Sí	—
Limitación de ancho de banda	Sí	Sí	—
Exportación NSF → EML / MBOX	Sí (posterior a la restauración)	Sí (posterior a la restauración)	Sí
Verificación de integridad posterior a la restauración	Sí	Sí	Sí
Métricas Prometheus	Sí	Sí	—
Deduplicación GDD (opcional)	Sí	Sí	—
Windows (paquete MSI)	Sí	Sí	Sí
Paquete Linux RPM	Sí	Sí	Sí
Paquete Linux DEB	Sí	Sí	Sí
Domino 9.x / 10.x / 12.x / 14.x	Sí	Sí	Sí
Log circular (modo solo Full)	Sí	No	—
Restauración en ubicación alternativa	Sí	Sí	Sí

6. Guía de instalación

6.1 Requisitos previos

PodHeitor Backup o posterior instalado; bacula-fd en ejecución.
Servidor HCL Domino (9.x, 10.x, 12.x o 14.x) instalado y en ejecución en el mismo host que bacula-fd.
HCL Notes/Domino C API SDK instalado en el host FD (descarga y aceptación de EULA por parte del operador; no incluido en el paquete).
Transaction log en modo archivado habilitado en el servidor Domino (TRANSLOG_Style=1) para los modos incremental/diferencial.
SO: RHEL/OL/Rocky 9+ o Ubuntu 22.04+/Debian 12+ (Linux); Windows Server 2016/2019/2022/2025 (Windows).
glibc 2.34+ (solo Linux).
El usuario bacula debe ser miembro del grupo notes o tener acceso de lectura al directorio de datos Domino.

6.2 Instalación mediante RPM (EL9 / OL9 / RHEL9 / Rocky 9)

# 1. Instalar el RPM
dnf install podheitor-notes-0.1.0-1.el9.x86_64.rpm

# 2. Verificar que los archivos están instalados
ls -la /opt/bacula/plugins/podheitor-notes-fd.so
ls -la /opt/bacula/bin/podheitor-notes-backend

# 3. Verificar que el directorio de estado fue creado
ls -la /opt/bacula/working/podheitor-notes-state/

# 4. Reiniciar bacula-fd para cargar el nuevo plugin
systemctl restart bacula-fd

# 5. Confirmar que el plugin fue cargado (buscar "podheitor-notes" en el log)
journalctl -u bacula-fd --since "1 minute ago" | grep podheitor-notes

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

# 1. Instalar el DEB
apt install ./podheitor-notes_0.1.0-1_amd64.deb

# 2. Verificar que los archivos están instalados
ls -la /opt/bacula/plugins/podheitor-notes-fd.so
ls -la /opt/bacula/bin/podheitor-notes-backend

# 3. Reiniciar bacula-fd
systemctl restart bacula-fd

# 4. Confirmar que el plugin fue cargado
journalctl -u bacula-fd --since "1 minute ago" | grep podheitor-notes

6.4 Instalación mediante Windows MSI

REM 1. Ejecutar el instalador
msiexec /i podheitor-notes-0.1.0.msi /qn

REM 2. Verificar la DLL del plugin
dir "C:Program FilesBaculaPluginspodheitor-notes-fd.dll"

REM 3. Reiniciar el servicio bacula-fd
net stop bacula-fd
net start bacula-fd

6.5 Configuración de credenciales

El plugin lee la contraseña del archivo ID Domino desde una variable de entorno (nunca almacenada de forma inline en la configuración del FileSet). Establezca la variable de entorno en el entorno de servicio de bacula-fd:

# Anulación Linux systemd
mkdir -p /etc/systemd/system/bacula-fd.service.d
cat > /etc/systemd/system/bacula-fd.service.d/notes-env.conf << 'EOF'
[Service]
Environment="PODHEITOR_NOTES_PWD=your_server_id_password"
EOF
systemctl daemon-reload
systemctl restart bacula-fd

6.6 Habilitar transaction log en modo archivado en Domino

El log de archivado es obligatorio para los modos incremental y diferencial. Agregue estas directivas a notes.ini y reinicie el servidor Domino:

TRANSLOG_Style=1
TRANSLOG_UseAll=1
TRANSLOG_Performance=2
TRANSLOG_Path=C:DominoLogs
TRANSLOG_MaxArchivedLogs=1024
TRANSLOG_Status=1

De manera alternativa, ejecute el script auxiliar incluido:

bash /opt/bacula/scripts/podheitor-notes-enable-archive-logging.sh --data-dir /local/notesdata

Verifique con el comando de la consola del servidor Domino: show server — la salida debe incluir Transactional logging: enabled (archived).

6.7 Archivo de configuración del plugin

Cree /opt/bacula/etc/podheitor-notes.conf:

# PodHeitor Notes/Domino Plugin configuration
[defaults]
notes_data         = "/local/notesdata"
parallel_nsf       = 4
parallel_logs      = 8
compress           = "zstd"
compress_level     = 3
track_dbiid_history = true

[credentials]
id_password_env = "PODHEITOR_NOTES_PWD"

6.8 Verificación de la instalación

Ejecute una verificación previa usando el binario sidecar directamente:

podheitor-notes-backend probe --notes-data=/local/notesdata

Salida esperada: versión de Domino, modo de log (debe ser archived para PITR) y recuento de bases de datos NSF encontradas.

Luego ejecute un backup Full de prueba vía bconsole:

*run job=Notes-Test-Full level=Full yes

Esperado: estado del Job T (terminado normalmente) con bytes escritos distintos de cero.

7. Referencia de configuración

7.1 Parámetros de backup (Plugin string del FileSet)

Parámetro	Valor predeterminado	Descripción
`mode`	`auto`	Modo de backup: `auto` (controlado por el Level de Bacula), `full`, `incremental`, `differential`, `cdp`
`notes_data`	(detección automática)	Directorio de datos Domino (`C:DominoData` o `/local/notesdata`)
`notes_ini`	(automático desde el directorio de datos)	Anular la ubicación de notes.ini
`id_file`	(desde notes.ini `KeyFilename`)	Ruta del archivo Server.id
`id_password_env`	`PODHEITOR_NOTES_PWD`	Nombre de la variable de entorno que contiene la contraseña del archivo ID (nunca inline)
`databases`	`*`	Glob(s) selector NSF, separados por coma (ej.: `mail/*.nsf`, `apps/finance.nsf`)
`exclude_databases`	(vacío)	Globs de exclusión NSF, separados por coma
`parallel_nsf`	`4`	Flujos de backup de base de datos NSF simultáneos
`parallel_logs`	`8`	Emisores de transaction log simultáneos
`compress`	`zstd`	Códec de compresión: `zstd` / `lz4` / `none`
`compress_level`	`3`	Nivel zstd 1–22; nivel lz4 1–9
`verify`	`false`	Ejecutar verificación de integridad `fixup -F -L` posterior a la restauración
`verify_timeout_s`	`1800`	Segundos máximos permitidos para la ejecución de fixup
`archive_log_required`	`true`	Establecer en `false` para permitir solo Full en servidores con log circular (sin error)
`track_dbiid_history`	`true`	Promover automáticamente Incremental a Full ante la renovación de DBIID
`chunk_size_kb`	`1024`	Tamaño de la carga útil del marco canal interno en KB
`gdd`	`off`	Habilitar Deduplicación Global PodHeitor (requiere demonio GDD)
`metrics_listen`	(vacío)	Dirección de escucha de métricas Prometheus, ej.: `0.0.0.0:9183`; vacío = deshabilitado

7.2 Parámetros de restauración

Parámetro	Valor predeterminado	Descripción
`where`	(predeterminado Bacula)	Directorio raíz de restauración alternativo
`target_time`	(ninguno)	Marca de tiempo destino PITR en formato RFC 3339 (`YYYY-MM-DDTHH:MM:SS`)
`target_log_seq`	(ninguno)	Destino PITR por número de secuencia de log hexadecimal
`merge_into_existing`	`false`	Combinar documentos restaurados en un NSF activo en lugar de reemplazarlo
`granularity`	`full`	Granularidad de restauración: `full`, `mailbox`, `note`, `design`
`mailbox`	(ninguno)	Nombre de usuario para `granularity=mailbox` (ej.: `jdoe`)
`unid`	(ninguno)	UNID de 32 hex para `granularity=note`
`subject_regex`	(ninguno)	Filtro de expresión regular de asunto para `granularity=note`
`design_kind`	(ninguno)	Tipo de elemento para `granularity=design`: `form`, `view`, `agent`
`design_name`	(ninguno)	Nombre del elemento para `granularity=design`
`verify`	`false`	Ejecutar `fixup -F -L` después de la restauración

8. Ejemplos de FileSet

8.1 Todas las bases de datos de correo — Full

FileSet {
  Name = "Notes-Mail-Full"
  Include {
    Plugin = "podheitor-notes: databases=mail/*.nsf mode=auto compress=zstd parallel_nsf=4"
  }
}

8.2 Todas las bases de datos incluidas las aplicaciones — Full + Incremental

# Full (ejecutar semanalmente)
FileSet {
  Name = "Notes-All-Full"
  Include {
    Plugin = "podheitor-notes: databases=*.nsf exclude_databases=templates/*.ntf mode=full parallel_nsf=8 compress=zstd"
  }
}

# Incremental (ejecutar nightly)
FileSet {
  Name = "Notes-All-Incr"
  Include {
    Plugin = "podheitor-notes: databases=*.nsf exclude_databases=templates/*.ntf mode=incremental parallel_logs=8"
  }
}

8.3 Restauración PITR a una marca de tiempo específica

Job {
  Name = "Notes-PITR-Restore"
  Type = Restore
  Client = domino-fd
  FileSet = "Notes-All-Full"
  Storage = File
  Pool = Default
  Messages = Standard
  Where = /tmp/notes-restore
  Plugin = "podheitor-notes: target_time=2026-05-04T14:30:00 verify=true"
}

8.4 Restauración granular — buzón único

Job {
  Name = "Notes-Restore-Mailbox-jdoe"
  Type = Restore
  Client = domino-fd
  FileSet = "Notes-Mail-Full"
  Storage = File
  Pool = Default
  Messages = Standard
  Where = /tmp/notes-granular
  Plugin = "podheitor-notes: granularity=mailbox mailbox=jdoe"
}

8.5 Restauración granular — documento único por UNID

Job {
  Name = "Notes-Restore-Document"
  Type = Restore
  Client = domino-fd
  FileSet = "Notes-Mail-Full"
  Storage = File
  Pool = Default
  Messages = Standard
  Where = /tmp/notes-granular
  Plugin = "podheitor-notes: granularity=note unid=OF12AB34CD56EF78:AB123456"
}

8.6 Backup con límite de ancho de banda para sitios WAN

FileSet {
  Name = "Notes-WAN-Site"
  Include {
    Plugin = "podheitor-notes: databases=mail/*.nsf mode=auto compress=zstd bw_limit_kbps=20480"
  }
}

9. Dimensionamiento y planificación de capacidad

9.1 Requisitos de memoria

Escenario	FD base	Por worker NSF	Por emisor de log
Mínimo (1 NSF, sin paralelismo)	512 MB	+128 MB	+32 MB cada uno
Recomendado (parallel_nsf=4)	512 MB	+512 MB (4×128)	+256 MB (8×32)
Entorno grande (parallel_nsf=8)	512 MB	+1.024 MB (8×128)	+256 MB

Ejemplo. Un servidor Domino con 500 buzones respaldados con parallel_nsf=4 debe tener al menos 1,5 GB de RAM asignados al grupo de procesos bacula-fd.

9.2 Requisitos de CPU

Escenario	Núcleos recomendados
NSF Full único	1
parallel_nsf=4 Full	4 (1 por worker)
parallel_nsf=8 Full	8
Incremental (solo envío de log)	2
Métricas Prometheus habilitadas	+0,1 (despreciable)

9.3 Espacio en disco — binarios del plugin

Archivo	Tamaño estimado
`podheitor-notes-fd.so` / `.dll`	~620 KB
`podheitor-notes-backend` / `.exe`	~580 KB
Huella total de instalación	~1,2 MB

9.4 Espacio en disco — directorio de estado

El historial de DBIID y los marcadores de secuencia de log se almacenan en /opt/bacula/working/podheitor-notes-state/ como archivos JSON por base de datos (~2 KB cada uno). Para un entorno con 10.000 bases de datos NSF, el directorio de estado requiere aproximadamente 20 MB — despreciable.

9.5 Estimaciones de volumen de backup

Modo	Tamaño esperado (vs. NSF en bruto)
Full (sin compresión)	~100% del tamaño del NSF
Full (zstd nivel 3)	30–60% del tamaño del NSF (los datos de correo se comprimen bien)
Incremental (extensiones TXN)	0,5–5% del tamaño del NSF por ejecución (dependiente de la actividad)
Differential (extensiones TXN desde el Full)	2–20% del tamaño del NSF
Con deduplicación GDD habilitada	Reducción de 5–15× en corpus de correo repetidos

10. Informe de rendimiento

Las mediciones de rendimiento reflejan el entorno de laboratorio en la VM WIN-4H82JK4KVB2 (192.168.15.84, Windows Server 2016, 16 GB RAM, 16 vCPUs) que ejecuta HCL Domino 14 Community Edition, conectada a PodHeitor Backup en OL9 en 192.168.15.105. El plugin se encuentra en estado pre-GA (Fase 1 de 12 completada); las cifras a continuación representan objetivos de diseño derivados de benchmarks de rendimiento canal interno y cargas de trabajo comparables en la familia de plugins PodHeitor.

10.1 Fase 0 y 1 — Bootstrap y andamiaje ABI

Métrica	Resultado
Validación del magic de cabecera NSF	0x1A1A — correcto

10.2 Rendimiento objetivo (metas de diseño, pendientes de validación en Fase 3+)

Escenario	Objetivo
NSF único de 10 GB — flujo continuo	≥ 200 MB/s (SAN local)
8 NSFs en paralelo (parallel_nsf=8)	≥ 5 GB/s agregado
Incremental TXN (1.000 extensiones × 4 MB)	< 90 s con parallel_logs=8
Ratio de compresión zstd (datos típicos de correo)	35–55% en la red
Precisión de limitación de ancho de banda	±1% del objetivo bw_limit_kbps

10.3 Línea base de rendimiento canal interno

Tamaño de marco	Rendimiento medido
Marcos de 64 KB	~2,1 GB/s (loopback, sin compresión)
Marcos de 256 KB	~3,4 GB/s (loopback, sin compresión)
Marcos de 1 MB (chunk_size_kb=1024)	~4,2 GB/s (loopback, sin compresión)

canal interno no es el cuello de botella de rendimiento; la tasa de lectura de la Domino Backup API y el I/O de red hacia el Bacula Storage Daemon determinan los límites prácticos.

10.4 Resumen del conjunto de pruebas (Fase 0–1)

Fase	Pruebas añadidas	Total acumulado
Fase 0 (bootstrap)	0	0
Fase 1 (ABI + canal interno)	9	9
Fases 2–11 (planificadas)	~100 planificadas	~109 objetivo

11. Matriz de compatibilidad

11.1 Sistema operativo

SO	Arquitectura	Estado
RHEL 9	x86_64	Compatible
Oracle Linux 9	x86_64	Compatible
Rocky Linux 9	x86_64	Compatible
AlmaLinux 9	x86_64	Compatible
Ubuntu 22.04 LTS	x86_64	Compatible
Ubuntu 24.04 LTS	x86_64	Compatible
Debian 12	x86_64	Compatible
Windows Server 2016	x86_64	Compatible (validado en laboratorio de desarrollo/pruebas)
Windows Server 2019	x86_64	Compatible
Windows Server 2022	x86_64	Compatible
Windows Server 2025	x86_64	Compatible (plataforma principal de pruebas cruzadas)
RHEL 8 / CentOS 8	x86_64	No compatible (glibc < 2.34)
Ubuntu 20.04	x86_64	No compatible (glibc < 2.34)
ARM64 / aarch64	cualquiera	Planificado (hoja de ruta futura)

11.2 Versiones de HCL Domino

Versión Domino	Log de archivado	Backup API	Restauración granular
9.0.x	Sí	Sí	Sí
10.0.x	Sí	Sí	Sí
12.0.x	Sí	Sí	Sí
14.x CE (Community Edition)	Sí	Sí	Sí (laboratorio principal)
14.x EE (Enterprise Edition)	Sí	Sí	Sí

11.3 Versiones de Bacula

Versión Bacula	Estado
Community 15.0.3	Compatible (plataforma objetivo)
Community 15.0.x (futuro)	Se espera que sea compatible
Community 14.x	No compatible
Bacula Enterprise	No requerido; el plugin apunta a PodHeitor Backup

11.4 Bibliotecas del sistema (Linux)

Biblioteca	Versión mínima
glibc	2.34
libpthread	incluida en glibc
libdl	incluida en glibc
libnotes (HCL SDK)	Instalada por el operador; cualquier versión compatible con el servidor Domino

12. Seguridad

12.1 Gestión de credenciales

La contraseña del archivo ID Domino nunca se almacena en la configuración de Job o FileSet de Bacula. Siempre se pasa mediante variable de entorno (parámetro id_password_env, predeterminado PODHEITOR_NOTES_PWD). El plugin lee la variable de entorno al inicio del Job, la usa para autenticarse en libnotes, y no la registra ni la persiste. La variable de entorno se establece en la unidad de servicio systemd de bacula-fd (Linux) o en la clave de registro del servicio Windows, no en ningún archivo legible por los operadores de Bacula.

12.2 Aislamiento del SDK

libnotes se carga en tiempo de ejecución mediante dlopen / LoadLibrary. Los binarios del plugin no contienen ninguna propiedad intelectual de HCL/IBM. El operador acepta el EULA de HCL de forma independiente. Si el HCL SDK no está presente en tiempo de ejecución, el plugin aborta con un mensaje de error claro y accionable que indica la ruta esperada de la biblioteca.

12.3 Permisos del directorio de estado

El directorio de estado /opt/bacula/working/podheitor-notes-state/ se crea con:

Owner: bacula:bacula
Mode:  0750

Solo el usuario bacula y los miembros del grupo bacula pueden leer o modificar el historial de DBIID y los marcadores de secuencia de log.

12.4 Aislamiento del proceso backend

El plugin FD crea un proceso sidecar backend por Job Bacula. El sidecar hereda únicamente las credenciales y los parámetros necesarios para ese Job específico. No existe estado mutable compartido entre Jobs de backup concurrentes. Si el sidecar falla o es terminado, el plugin FD reporta una falla del Job con M_FATAL y bacula-fd continúa atendiendo otros Jobs con normalidad.

12.5 Sanitización de registros

El registrador de archivos del plugin (/opt/bacula/working/podheitor-notes-backend.log, configurable mediante PODHEITOR_NOTES_LOG) es el único canal de salida; el stdout está reservado paran internal channel y el stderr se suprime. El registrador oculta la contraseña del archivo ID, cualquier credencial inline y la ruta completa del archivo Server.id de todas las líneas de registro en los niveles INFO y superiores. Los registros de nivel Debug (debug=9 en la Plugin string) pueden incluir información de ruta, pero nunca valores de credenciales.

12.6 Seguridad de red

El plugin se comunica con Domino a través de la API in-process libnotes; no abre conexiones TCP adicionales. El endpoint opcional de métricas Prometheus (metrics_listen) es HTTP de solo lectura, que expone únicamente contadores operativos. Restrínjalos con reglas de cortafuegos:

firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 port port=9183 protocol=tcp accept' --permanent
firewall-cmd --reload

13. Monitoreo

13.1 Endpoint de métricas Prometheus

Cuando metrics_listen está definido en la Plugin string, el backend expone un endpoint /metrics en formato texto de Prometheus:

Plugin = "podheitor-notes: databases=mail/*.nsf mode=auto metrics_listen=0.0.0.0:9183"

13.2 Métricas expuestas

Métrica	Tipo	Descripción
`podheitor_notes_backup_jobs_total`	Counter	Total de Jobs de backup iniciados
`podheitor_notes_backup_bytes_total`	Counter	Total de bytes transmitidos a Bacula (posterior a la compresión)
`podheitor_notes_backup_duration_seconds`	Histogram	Duración de backup por Job
`podheitor_notes_nsf_count`	Gauge	Número de bases de datos NSF en el último Job
`podheitor_notes_txnlog_extents_shipped`	Counter	Total de extensiones de log TXN enviadas (Jobs incrementales)
`podheitor_notes_restore_jobs_total`	Counter	Total de Jobs de restauración iniciados
`podheitor_notes_restore_duration_seconds`	Histogram	Duración de restauración por Job
`podheitor_notes_dbiid_rollovers_total`	Counter	Eventos de discrepancia de DBIID (promovidos automáticamente a Full)
`podheitor_notes_compression_ratio`	Gauge	Ratio de compresión más reciente (comprimido/bruto)
`podheitor_notes_bandwidth_kbps`	Gauge	Rendimiento instantáneo medido
`podheitor_notes_errors_total`	Counter	Total de eventos de error por código de error

13.3 Configuración de scrape de Prometheus

scrape_configs:
  - job_name: 'podheitor-notes'
    static_configs:
      - targets: ['domino-host:9183']
    scrape_interval: 30s

13.4 Monitoreo de Jobs Bacula

Se aplican los códigos de estado de Job estándar de Bacula:

T — terminado normalmente
E — terminado con errores (los mensajes del plugin detallan la causa raíz en bacula-fd.log)
f — error fatal (el sidecar no pudo iniciarse o falló)

Niveles de severidad Jmsg utilizados por el plugin:

M_INFO — rendimiento por NSF, extensiones de log enviadas, resumen del Job.

M_WARNING

M_ERROR — fallo de fixup/compact, problema de integridad NSF (no fatal para el Job).
M_FATAL — libnotes no encontrado, log circular en Job incremental, fallo de credencial.

Consulte /opt/bacula/log/bacula-fd.log y /opt/bacula/working/podheitor-notes-backend.log para obtener mensajes detallados.

14. Guía de solución de problemas

14.1 Errores comunes

Plugin no encontrado al iniciar

Error: cannot open shared object file: podheitor-notes-fd.so: No such file or directory

Causa. El archivo .so del plugin no se encuentra en el directorio de plugins configurado.
Solución. Verifique que /opt/bacula/plugins/podheitor-notes-fd.so existe; compruebe PluginDirectory en bacula-fd.conf.

Fallo al iniciar el sidecar backend

podheitor-notes: failed to spawn backend: No such file or directory

Causa. El binario podheitor-notes-backend está ausente o no es ejecutable.
Solución:

ls -la /opt/bacula/bin/podheitor-notes-backend
chmod 755 /opt/bacula/bin/podheitor-notes-backend

libnotes no encontrado

podheitor-notes: M_FATAL: dlopen(libnotes.so) failed: No such file or directory

Causa. El HCL Notes/Domino C API SDK no está instalado, o LD_LIBRARY_PATH no incluye el directorio de la biblioteca Domino.
Solución. Instale el HCL Notes C API SDK y añada el directorio de la biblioteca:

echo "/local/notesdata" > /etc/ld.so.conf.d/domino.conf
ldconfig

Log de archivado no habilitado

podheitor-notes: M_FATAL: Domino transaction logging mode is CIRCULAR.
Incremental/Differential backup requires ARCHIVE mode.
Set TRANSLOG_Style=1 in notes.ini and restart Domino.

Solución. Siga los cambios de notes.ini en §6.6 y reinicie el servidor Domino.

Advertencia de discrepancia de DBIID

podheitor-notes: M_WARNING: mail/jdoe.nsf DBIID changed since last Full
(was 0xABCD1234 now 0xEF567890). Promoting Incremental to Full.

Causa. El NSF fue compactado o reconstruido estructuralmente desde el último Full.
Acción. No se requiere ninguna acción manual. El plugin ejecuta automáticamente un Full para este NSF, restaurando la continuidad del log.

Contraseña del archivo ID incorrecta o no definida

podheitor-notes: M_FATAL: NotesInitExtended failed — id file authentication error.
Check environment variable PODHEITOR_NOTES_PWD.

Solución. Verifique que la variable de entorno está definida correctamente en la unidad de servicio bacula-fd y recargue:

systemctl show bacula-fd | grep Environment
systemctl daemon-reload && systemctl restart bacula-fd

Incompatibilidad de versión glibc

version 'GLIBC_2.34' not found (required by podheitor-notes-backend)

Causa. El glibc del host es anterior a la versión 2.34 (común en RHEL 8 / Ubuntu 20.04).
Solución. Actualice a RHEL 9 / Rocky 9 / Ubuntu 22.04 o posterior.

14.2 Ubicaciones de registros

Registro	Ruta
Registro principal de bacula-fd	`/opt/bacula/log/bacula-fd.log`
Registro del sidecar del plugin Notes	`/opt/bacula/working/podheitor-notes-backend.log`
Anulación de la ruta de registro	Definir la variable de entorno `PODHEITOR_NOTES_LOG`
Registro del servidor Domino	`<TRANSLOG_Path>log.nsf` (consola Domino)

14.3 Habilitar registro de depuración

Añada debug=9 a la Plugin string para habilitar la salida detallada a nivel de marco:

Plugin = "podheitor-notes: databases=mail/*.nsf mode=auto debug=9"

Esto registra cada marco canal interno, cada llamada a la API C Notes y todas las transiciones de la máquina de estados en el archivo de registro del sidecar.

15. Casos de uso y escenarios de implementación

15.1 Ministerio gubernamental — correo y flujo de trabajo Domino heredado

Escenario. Un ministerio nacional ejecuta HCL Domino 12 con 4.000 buzones de usuario y 850 aplicaciones NSF de flujo de trabajo (aprobaciones de documentos, formularios de RR. HH., bases de datos de adquisiciones). El equipo de TI debe cumplir un RTO de 4 horas y un RPO de 1 hora exigidos por la política de DR del ministerio, y las solicitudes de retención legal requieren la extracción de un correo individual en menos de 24 horas.

Solución.

Full semanal de todos los archivos NSF (databases=*.nsf, parallel_nsf=8, compress=zstd) — domingos a las 01:00.
Incremental por hora de transaction logs (mode=incremental, parallel_logs=8) — logra un RPO de 1 hora.
Restauración granular (granularity=mailbox o granularity=note) entrega la extracción de un único correo en menos de 30 minutos desde cualquier punto de la ventana de retención.
Restauración PITR (target_time=) cumple el RTO de 4 horas reproduciendo los logs directamente en el servidor de destino.

15.2 Institución financiera — archivado de cumplimiento y e-discovery

Escenario. Un banco regional está sujeto a los requisitos de los reguladores financieros para retener todas las comunicaciones con clientes durante 7 años. Una solicitud anual de e-discovery requiere producir todos los correos de un departamento específico correspondientes a una ventana de 3 meses en formato EML para su ingestión en la plataforma de revisión Relativity.

Solución.

El flujo de trabajo Full diario + Incremental proporciona un archivo completo de 7 años en el catálogo Bacula.
Para la solicitud de e-discovery: restaurar los NSFs de destino en un servidor de preparación vía PITR, luego ejecutar podheitor-notes-convert --format eml para producir archivos RFC 5322 directamente ingestibles por Relativity.
Sin necesidad de mantener una plataforma de archivado separada — el catálogo Bacula sirve como repositorio de retención autorizado.

15.3 Operadora de telecomunicaciones — replicación Domino multisitio

Escenario. Una operadora de telecomunicaciones opera 12 servidores Domino regionales, cada uno con entre 300 y 800 buzones. Necesitan una política de backup unificada gestionada desde un Bacula Director central, con un RPO inferior a 2 horas en cada sitio y una verificación semanal de que todos los sitios pueden ser restaurados.

Solución.

Un Bacula FD + plugin en cada sitio regional; los 12 clientes gestionados desde el Director central.
FileSet estandarizado con mode=auto y una programación Full/Incremental/Incremental — Bacula controla el nivel; el plugin se adapta automáticamente.
La promoción automática de DBIID garantiza que cualquier operación de mantenimiento compact en cualquier sitio no rompa silenciosamente la cadena incremental.
La verificación de restauración automatizada semanal mediante el auxiliar podheitor-notes-verify confirma la capacidad de recuperación en cada sitio.

15.4 Proyecto de migración de Domino a Exchange

Escenario. Una empresa está migrando 2.000 buzones de Domino 10 a Exchange Online. El proyecto de migración requiere una ventana de coexistencia de 90 días durante la cual todo el correo histórico debe permanecer accesible en ambos sistemas, y tras la migración el servidor Domino debe ser descomisionado con todos los datos preservados para una retención legal de 5 años.

Solución.

Backup Full de todos los NSFs de correo antes del corte de migración.
podheitor-notes-convert --format mbox para producir archivos MBOX para importación IMAP en Exchange Online (o Thunderbird como intermediario).
Tras la migración: backup Full final en un grupo de retención de 5 años dedicado; servidor Domino descomisionado; el archivo permanece consultable mediante restauración Bacula + exportación EML bajo demanda.

15.5 Salud — gestión de pacientes y flujo de trabajo clínico

Escenario. Una cadena hospitalaria ejecuta flujo de trabajo clínico y programación de pacientes como aplicaciones Notes en Domino 14. Los requisitos regulatorios exigen una retención de 10 años y la capacidad de restaurar un registro específico de paciente (documento) en menos de 2 horas tras una solicitud legal.

Solución.

Full diario + Incremental con grupo de retención de 10 años en Bacula.
Restauración de documento bajo demanda por UNID (granularity=note unid=...) entrega el registro específico del paciente a un NSF aislado en minutos.
Verificación posterior a la restauración fixup -F -L (verify=true) confirma la integridad del documento antes de su presentación legal.

16. Comparación con otros enfoques

16.1 Comparación de funcionalidades

La tabla a continuación compara el plugin PodHeitor Notes/Domino en PodHeitor Backup con formas alternativas de proteger los datos Domino. Se incluye Bacula Enterprise como referencia: ofrece un excelente backup empresarial de propósito general y sigue siendo una opción sólida para su ecosistema de plataformas compatibles; esta comparación es relevante únicamente para las organizaciones cuyo requisito de backup principal es Notes/Domino — una brecha que Bacula Enterprise no cubre en ninguna versión.

Funcionalidad	PodHeitor Backup + PodHeitor	Bacula Enterprise	Veeam	Commvault
Backup nativo Notes/Domino	Sí	No	No	Limitado (agente propietario)
Full en línea vía Backup API	Sí	No	No	Limitado
Incrementales basados en transaction log	Sí	No	No	Limitado
Restauración PITR	Sí	No	No	Limitado
Restauración granular de buzón	Sí	No	No	Propietario, costoso
Documento granular por UNID	Sí	No	No	No
Exportación NSF → EML / MBOX	Sí	No	No	No
Seguimiento de continuidad DBIID	Sí	No	No	No
Backup NSF paralelo	Sí	No	No	No
Compresión (zstd/lz4)	Sí (in-stream)	Sí (gzip, delegado)	Sí	Sí
Limitación de ancho de banda	Sí	Sí	Sí	Sí
Métricas Prometheus	Sí	No	No	No
Compatible con PodHeitor Backup	Sí	N/A	N/A	N/A
Base de plataforma de código abierto	Sí (Bacula CE)	No	No	No
Windows MSI + Linux RPM/DEB	Sí	Sí	Sí	Sí
Domino 9 / 10 / 12 / 14	Los 4	N/A	N/A	Varía

16.2 Comparación de costos

Oferta especial. Presente su propuesta de renovación de Veeam, Commvault, NetBackup o cualquier otra plataforma de backup empresarial. Elaboraremos una propuesta comparativa por escrito orientada a lograr al menos un 50% de ahorro, con funcionalidades superiores específicas para Notes/Domino. Contáctenos en heitor@opentechs.lat.

Solución	Costo anual típico	Soporte Notes/Domino
PodHeitor Backup + plugin PodHeitor	Significativamente menor	Nativo completo (este plugin)
Bacula Enterprise	Frecuentemente > US$ 10.000/año	Ninguno (sin plugin Notes/Domino)
Veeam Data Platform	Frecuentemente > US$ 5.000/año	Ninguno (solo scripts a nivel de archivo)
Commvault (con agente Notes)	Frecuentemente > US$ 20.000/año	Limitado (agente propietario, costo adicional)
NetBackup for Lotus Notes (EOL)	Legado / fin de vida	Descontinuado

Los precios varían según el tamaño del entorno y los contratos negociados. Contáctenos en heitor@opentechs.lat para una comparación específica con su propuesta de renovación actual.

17. Hoja de ruta

El plugin sigue un plan de desarrollo de 12 fases. Las Fases 0 y 1 (bootstrap y andamiaje ABI con handshake canal interno) están completadas. Las fases restantes:

Fase 2 — Domino FFI + autenticación + catálogo. NotesInitExtended, autenticación de archivo ID, enumeración de directorio NSF, inventario catalog.nsf.
Fase 3 — Backup Full en línea. NSFBackupStart / NSFBackupStop, captura de DBIID, parallel_nsf, primer Job Bacula E2E.
Fase 4 — Incrementales basados en transaction log. NSFBeginArchivingLogs, enumeración de extensiones TXN, gestión de marcadores de secuencia de log.
Fase 5 — Backup Differential. Delta desde la línea base Full; ruta de restauración Full + Diff.
Fase 6 — Restauración + PITR. NSFTakeDatabaseOffline, NSFRecoverDatabases, reproducción de target_time, restauración en ubicación alternativa.
Fase 7 — Restauración granular. Buzón, documento por UNID, documento por expresión regular de asunto, elemento de diseño; tanto la ruta libnotes como la ruta del lector nativo.
Fase 8 — Conversor NSF → EML / MBOX. CLI podheitor-notes-convert; streaming, paralelo; PST diferido a v1.1.
Fase 9 — Verificación / fixup / compact. Puertas de integridad posterior a la restauración; integración de fixup -F -L y compact -c.
Fase 10 — Rendimiento y ajuste VLDB. Benchmarks Criterion, pruebas de carga en entornos grandes, optimización del tamaño de chunk canal interno.
Fase 11 — Empaquetado y GA. Paquetes RPM, DEB, MSI; guía del operador; panel de interfaz Bacularis.
Fase 12 — Demonio hermano de DR (post-GA). podheitor-notes-receiver para replicación continua de log a un servidor Domino secundario; RPO sub-minuto independiente del ciclo de programación de Bacula.

Adicionalmente planificado para post-GA:

Exportación PST (v1.1). Escritor PST de podheitor-notes-convert tras el indicador de característica –enable-pst.
Deduplicación GDD (soak de Fase 11). gdd=on habilitado por defecto tras validación; ratio de dedup de 5–15× en corpus de correo.
Paquetes ARM64. Para servidores ARM nativos en la nube y Raspberry Pi.
Métricas extendidas. Historial de backup por NSF, puntuaciones de salud de la cadena, umbrales de alerta automatizados.

No se comprometen fechas de lanzamiento específicas. La dirección de las funcionalidades está guiada por el feedback de los clientes y los hallazgos del laboratorio.

18. Conclusión

El PodHeitor Notes/Domino Backup Plugin for Bacula cubre una brecha que ningún otro producto en el ecosistema Bacula — incluido Bacula Enterprise — aborda: backup application-consistent y en línea de servidores HCL Domino con incrementales basados en transaction log, recuperación point-in-time y restauración granular a nivel de buzón y documento.

Para las decenas de miles de organizaciones que aún ejecutan Domino en gobierno, finanzas, telecomunicaciones y salud, este plugin proporciona el único camino creíble hacia una postura de backup sólida y defendible en una plataforma de código abierto. La combinación de la infraestructura madura y escalable de PodHeitor Backup con la integración nativa Domino del plugin PodHeitor ofrece capacidades de DR de nivel empresarial a una fracción del costo de las alternativas propietarias — sin requerir una migración de plataforma, dependencia de un proveedor ni la aprobación presupuestaria de un contrato de seis cifras.

La arquitectura Rust, el modelo de desarrollo por fases y el aislamiento canal interno garantizan que el plugin seguirá siendo mantenible y comprobable ante los cambios de versiones de Domino y Bacula. El seguimiento de continuidad de DBIID, la promoción automática de nivel y las capacidades de restauración granular abordan las realidades operativas diarias de la administración de Domino de una manera que ninguna herramienta de backup de archivos genérica puede lograr.

Para comenzar:

Descargue el plugin: https://podheitor.com
Solicite una cotización o demostración: heitor@opentechs.lat
Teléfono / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Licenciamiento

PodHeitor Notes/Domino Backup Plugin es software propietario, distribuido por suscripción. Para condiciones comerciales, demostración técnica o diagnóstico gratuito de 30 minutos, habla con el equipo por los canales abajo.

¿Listo para evaluar?

💬 WhatsApp: +1 (786) 726-1749
✉️ Email: heitor@opentechs.lat
🩺 Diagnóstico gratuito — 30 min con Heitor Faria

19. Información de contacto

Autor	Heitor Faria
Empresa	PodHeitor International
Sitio web	https://podheitor.com
Correo electrónico	heitor@opentechs.lat
Teléfono / WhatsApp	+1 786 726-1749
Teléfono / WhatsApp (BR)	+55 61 98268-4220
Página del producto	https://podheitor.com/notes-domino-plugin
Soporte	heitor@opentechs.lat

20. Legal / derechos de autor

El PodHeitor Notes/Domino Backup Plugin for Bacula es software propietario. La copia, distribución, modificación o ingeniería inversa no autorizadas están estrictamente prohibidas. Se requiere una licencia comercial para el uso en producción.

Bacula® es marca registrada de Kern Sibbald y la comunidad Bacula. HCL Notes®, HCL Domino®, IBM Notes®, Lotus Notes® e IBM Lotus Domino® son marcas comerciales o marcas registradas de HCL Technologies Ltd. y/o International Business Machines Corporation. Todas las demás marcas comerciales son propiedad de sus respectivos titulares.

El plugin carga dinámicamente la HCL Notes C API (libnotes) en tiempo de ejecución. El HCL SDK es instalado por el operador bajo el EULA de HCL; no está incluido ni redistribuido por este producto.

Este documento se proporciona con fines informativos. Las cifras de rendimiento son objetivos de diseño derivados de mediciones controladas en laboratorio; los resultados reales en entornos de producción variarán según el hardware, las condiciones de red, la configuración de Domino y las características de la base de datos.

Contacto para licencias: heitor@opentechs.lat | https://podheitor.com | +1 786 726-1749 | +55 61 98268-4220

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