Whitepaper — PodHeitor ADABAS - PodHeitor — Backup, Replicação e Recuperação de Desastres

Respaldo ADABAS sin ventana. Software AG ADABAS protegido con hot backup nativo, PLOG streaming, restauración al PLOG, integración con nucleus z/OS, Linux y Open Systems.

Hot backup nativo — sin stop del nucleus, sin ventana de mantenimiento.
PLOG streaming continuo — RPO cerca de cero.
z/OS, Linux, Open Systems — mismo plugin, misma sintaxis.
Restauración al PLOG — precisión transaccional.
ADASAV-aware — integración con utilitario oficial.

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
Introducción y contexto de mercado
Descripción general de la arquitectura
Modos de respaldo 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 resolució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

ADABAS (Adaptable DAta BAse System), desarrollado por Software AG, es un sistema de gestión de bases de datos jerárquico/navegacional con una historia de producción excepcionalmente larga — introducido originalmente en 1971, continúa siendo la base de cargas de trabajo de misión crítica en telecomunicaciones, banca, seguros y organismos gubernamentales en todo el mundo. ADABAS funciona en mainframes z/OS, AIX y Linux, y no es raro encontrar instancias activas de ADABAS que protegen décadas de historial de transacciones en sectores donde la continuidad heredada es exigida por regulación.

A pesar de esta enorme importancia crítica, el respaldo de ADABAS en entornos Linux ha sido gestionado históricamente mediante utilitarios nativos de Software AG — ADASAV, ADABCK, ADAREP — invocados por scripts de shell de operadores, o mediante snapshots de sistema de archivos a nivel de SO que no pueden garantizar la consistencia de la base de datos. Ninguno de estos enfoques se integra con un catálogo de respaldo empresarial, proporciona flujos de restauración verificados ni ofrece la gestión de retención, cifrado y programación basada en políticas que los estándares modernos de protección de datos requieren.

El Plugin de Respaldo ADABAS de PodHeitor para Bacula cierra esta brecha. Es un plugin para el Bacula File Daemon, nativo en Rust y de calidad para producción, que integra el respaldo y la restauración de ADABAS directamente en PodHeitor Backup+. El plugin encapsula los utilitarios nativos de ADABAS (adabck, adaopr, adavfy, adarec) mediante una capa de subproceso con tipo seguro y límite de tiempo, transmite datos de respaldo sobre el canal interno otimizado y almacena todo en el catálogo estándar de Bacula. Los respaldos completos, los incrementales basados en PLOG, los trabajos con múltiples DBIDs, la restauración a un punto en el tiempo y la verificación de consistencia posterior a la restauración se gestionan a través de una única cadena de Plugin de Bacula — sin scripts de operadores, sin secuenciación manual.

Las pruebas de validación en Community Edition (CE) 7.4.0.3 confirmaron: 78 pruebas unitarias Rust aprobadas, respaldo completo de extremo a extremo (7,27 MB, exit 0, manifiesto válido), perfil de memoria en streaming de 1,94 MB en el pico para un volcado de 7,27 MB (streaming de memoria constante O(1)), agregación de múltiples DBIDs en modo best-effort y cancelación segura por señal. Las funcionalidades bloqueadas por licencia (aplicación de PLOG en modo online, finalización de restauración con nucleus fuera de línea) están completas en código y aguardan validación de extremo a extremo en una instancia licenciada de ADABAS.

Para cualquier organización que ejecute ADABAS en Linux con PodHeitor Backup, el plugin de PodHeitor es el camino más completo y más rentable hacia una postura de respaldo defendible y auditable — sin reemplazar la plataforma de respaldo que ya está en operación.

2. Introducción y contexto de mercado

2.1 ADABAS en producción hoy

ADABAS ocupa una posición única en el panorama de las bases de datos. No es un sistema académico de nicho — es la base de datos que mantuvo telecomunicaciones nacionales enteras, cámaras de compensación bancaria y registros de pólizas de seguros en funcionamiento durante cuarenta años antes de que los sistemas relacionales modernos maduraran. Su arquitectura refleja su época: un modelo de datos jerárquico y de acceso directo con registros de longitud fija, acoplado al lenguaje de programación Natural 4GL desarrollado en paralelo por Software AG. Características clave:

Modelo jerárquico / navegacional. Los datos se almacenan como campos numerados (FDT — Field Definition Table) accedidos por ISN (Internal Sequence Number), lo que permite lecturas secuenciales y directas extremadamente rápidas en grandes conjuntos de datos planos.
Procesamiento de transacciones de alto rendimiento. ADABAS utiliza una arquitectura Multi-User Facility (MUF) con colas de mensajes SysV IPC para la comunicación entre procesos, lo que permite miles de operaciones simultáneas NUC (Nucleus).
Modelo de contenedores PLOG / ASSO / DATA / WORK. La base de datos se divide físicamente en contenedores ASSO (asociador), DATA, WORK y PLOG (Protection LOG) — cada uno con semántica de respaldo independiente.
Integración con el lenguaje Natural. La mayoría de las aplicaciones ADABAS están escritas en Natural, y el IDE NaturalONE / entorno de desarrollo NaturalOne acopla estrechamente la lógica de la aplicación al esquema.
Legado multiplataforma. ADABAS funciona en z/OS, BS2000, AIX, HP-UX y Linux. Este plugin apunta a Linux (x86_64, aarch64), que es el principal destino de implementación para las nuevas instalaciones de ADABAS y para las organizaciones que migran de mainframe a hardware de commodity.

Sectores donde ADABAS permanece en producción activa:

Telecomunicaciones: gestión de abonados, facturación y almacenamiento de registros de datos de llamadas (CDR) en operadoras nacionales en Brasil, Alemania, Sudáfrica y otros países.
Servicios financieros: libros contables de core banking, sistemas de liquidación de compensaciones y motores de reserva de pólizas de seguros.
Gobierno: registros de personal, registros de seguridad social y bases de datos tributarias — especialmente en América Latina, Europa Central y África Subsahariana.
Servicios públicos: facturación de clientes para redes de distribución de electricidad y agua.

2.2 Por qué los enfoques de respaldo existentes son insuficientes

Enfoque	Consistencia con ADABAS	Veredicto
PodHeitor Backup (nivel de archivo, sin plugin)	Ninguna — realiza respaldo de los archivos de contenedor sin procesar mientras el ADABAS MUF está en ejecución	No seguro — ASSO/DATA están en estado inconsistente en medio de una transacción
Snapshot LVM / ZFS a nivel de SO	Consistente con falla, en el mejor de los casos	Requiere quiesce del nucleus; sin integración con PLOG; secuenciación manual de recuperación
Veeam	Sin agente nativo para ADABAS	Respaldo solo a nivel de VM; sin recuperación de ADABAS consistente con la aplicación
Commvault	Sin iDataAgent para ADABAS	Solo integración mediante script personalizado
NetBackup	Sin tipo de política para ADABAS	Solo a nivel de SO; sin integración con el punto de quiesce del Nucleus
Solo herramientas nativas Software AG (ADASAV, ADABCK)	Consistencia total	Sin catálogo, sin gestión de retención, sin programación por política, sin integración de cifrado; intervención manual del operador en la restauración
Scripts de shell personalizados que encapsulan adabck	Parcial — la corrección depende de la calidad del script	No apto para producción; sin reintentos, sin verificación, sin monitoreo

La brecha es clara: hasta ahora, ninguna solución de respaldo compatible con código abierto se integró con ADABAS a nivel del motor. El plugin de PodHeitor llena esta brecha.

2.3 El enfoque de PodHeitor

El plugin sigue la misma filosofía de diseño de la familia de plugins de PodHeitor: implementación nativa en Rust, desarrollo con fases y pruebas de regresión automatizadas, cero dependencias de tiempo de ejecución más allá de las herramientas de la base de datos objetivo, y una arquitectura de canal interno otimizado que hace que la división plugin/backend sea trivialmente segura ante cambios en la API interna de Bacula. El plugin de ADABAS reutiliza el mismo canal interno otimizado, el framework plugin FD de framework de plugin PodHeitor, el modelo de aislamiento de subprocesos y el mecanismo de combinación de archivos de configuración que han sido validados en los plugins de PodHeitor para PostgreSQL, Firebird y otros.

3. Descripción general de la arquitectura

3.1 Diseño de dos componentes

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

Componente	Archivo	Función
Plugin Bacula FD (plugin FD)	`/opt/bacula/plugins/podheitor-adabas-fd.so`	Cargado por `bacula-fd` en tiempo de ejecución; implementa la API de plugin de Bacula (plugin nativo en Rust)
Binario backend	`/opt/bacula/bin/podheitor-adabas-backend`	Creado (fork) por trabajo por el plugin FD; realiza toda la interacción con ADABAS mediante llamadas de subproceso a los utilitarios nativos de ADABAS

Esta separación proporciona tres ventajas clave:

Aislamiento. El plugin FD es mínimo y estable. Toda la lógica que interactúa con los utilitarios de ADABAS (adabck, adaopr, adavfy, adarec) reside en el backend. Un fallo o bloqueo en el backend no puede corromper el proceso Bacula FD.
Capacidad de actualización. El binario backend puede actualizarse sin reiniciar bacula-fd. Solo el plugin FD interactúa con el ABI del plugin de Bacula.
Capacidad de prueba. El binario backend puede ejercitarse directamente en pruebas de integración sin involucrar a Bacula — fundamental para un sistema donde el ADABAS licenciado puede no estar disponible en el CI.

3.2 Restricción de co-localización

El backend Rust se ejecuta en el mismo host Linux que ADABAS. La comunicación entre procesos de ADABAS utiliza colas de mensajes SysV — que no pueden ser tuneladas entre máquinas. El Bacula Storage Daemon puede estar en cualquier lugar; el plugin transmite paquetes canal interno a través de la conexión TCP estándar FD→SD de Bacula. En implementaciones en contenedores donde los utilitarios de ADABAS residen dentro de un contenedor Podman/Docker, el script wrapper incluido (scripts/podheitor-adabas-backend.podman-wrapper.sh) re-ejecuta el backend dentro del contenedor usando podman exec -i, haciendo el puente entre el host y el contenedor de forma transparente.

3.3 Gestión de estado

Los trabajos incrementales basados en PLOG requieren un estado persistente para rastrear qué archivos de protection log han sido archivados y cuáles están pendientes de eliminación con compuerta de seguridad. Este estado se almacena por DBID en:

/opt/bacula/working/podheitor-adabas-state/
  ├── dbid-12.json      # estado para DBID 12
  ├── dbid-13.json      # estado para DBID 13
  └── dbid-14.json      # estado para DBID 14

Cada archivo de estado se escribe atómicamente mediante el patrón tmpfile-then-rename, garantizando que no haya corrupción de estado en caso de fallo. El esquema está versionado para compatibilidad futura.

4. Modos de respaldo en detalle

4.1 Respaldo completo (Level F) — ADABCK DUMP en línea

Cómo funciona

El modo de respaldo completo invoca adabck con DUMP=* para realizar un respaldo en línea completo del nucleus de ADABAS. Antes del volcado, el plugin opcionalmente encapsula la operación con un comando adaopr EXT_BACKUP=PREPARE para notificar al nucleus que una herramienta de respaldo externa está comenzando, garantizando la consistencia transaccional en el punto de quiesce. Al completar, adaopr EXT_BACKUP=CONTINUE libera el punto de quiesce. El flujo del volcado se captura mediante la variable de entorno BCK001=- (modo de streaming por stdout) y se retransmite a Bacula a través de canal interno en un bucle de buffer fijo de 1 MiB — memoria constante independientemente del tamaño de la base de datos.

  adaopr EXT_BACKUP=PREPARE  →  adabck DUMP=* (stdout)  →  búfer 1 MiB  →  Bacula SD
                                     (via canal interno)  →  Bacula SD

Cuándo usar

Respaldo completo semanal como punto de anclaje para cadenas incrementales
Línea base inicial antes de habilitar el archivado incremental de PLOG
Cualquier escenario de DR que requiera un punto de restauración completo y autónomo
Entornos donde los incrementales basados en PLOG no están licenciados (Community Edition)

Propiedades clave

Propiedad	Evaluación
Consistencia	Excelente — punto de quiesce mediante EXT_BACKUP=PREPARE garantiza la frontera transaccional
Respaldo en línea (hot)	Sí — el nucleus permanece en línea durante todo el proceso
Uso de memoria	O(1) — búfer de streaming fijo de 1 MiB validado en 1,94 MB VmHWM para un volcado de 7,27 MB
Tamaño del respaldo	Contenedores ASSO + DATA completos; PLOG no incluido en Level F
Requisito de EXT_BACKUP	Sí en ADABAS licenciado (predeterminado activo); debe deshabilitarse en Community Edition
Soporte a múltiples DBIDs	Sí — best-effort por DBID; los fallos se agregan sin abortar los DBIDs restantes
Límite de tiempo	Sí — predeterminado de 4 horas; configurable mediante backup_timeout_secs

4.2 Respaldo incremental (Level I) — archivado de PLOG

Cómo funciona

El modo de respaldo incremental archiva los archivos de Protection Log (PLOG) de ADABAS desde el último trabajo exitoso. Los PLOGs registran cada transacción confirmada y son el mecanismo nativo de ADABAS para la recuperación a un punto en el tiempo. El plugin escanea el directorio de PLOG en busca de archivos con números de secuencia más recientes que la última secuencia archivada (rastreada en el archivo de estado por DBID), envía cada PLOG como un archivo virtual separado en /@ADABAS/dbid-<N>/plog-<seq>.adabck, y emite un _plog_manifest.json como Restore Object registrando rangos de secuencia, contadores de generación y marcas de tiempo.

  Scan PLOG.NNNN files  →  sequence-wrap detection  →  stream each PLOG via canal interno  →  safety-gated delete

La compuerta de seguridad garantiza que los archivos PLOG nunca se eliminen del disco local hasta que un trabajo posterior haya sido ejecutado con éxito — dándole al operador un ciclo completo de trabajo para abortar antes de perder las copias locales.

Cuándo usar

Protección incremental por hora entre respaldos completos semanales (RPO ≈ 1 hora)
Cualquier entorno que requiera capacidad de restauración a un punto en el tiempo
Entornos donde el tiempo de respaldo completo es demasiado largo para la ejecución nocturna

Propiedades clave

Propiedad	Evaluación
ADABAS licenciado requerido	Sí — la CE no emite PLOGs
Tamaño incremental vs. completo	Típicamente < 1% del tamaño del respaldo completo por intervalo horario
Detección de sequence-wrap	Sí — el contador de generación se incrementa en PLOG.0001 después de last_seen > 0
Eliminación con compuerta de seguridad	Sí — los PLOGs locales se eliminan solo después del siguiente trabajo exitoso
Reintento en fallo transitorio	Sí — backoff exponencial (100ms, 200ms, 400ms), limitado por plog_ship_retries (predeterminado 2)
Reintento de respaldo completo	Nunca — la lógica de reintento es solo para el envío de PLOG, no para volcados Level F

4.3 Restauración — completa (adabck RESTORE) + punto en el tiempo (aplicación de PLOG con adarec)

Flujo de restauración completa (Fase A → E)

El proceso de restauración sigue una orquestación de cinco fases:

Fase A — análisis del manifiesto. El plugin lee el Restore Object _manifest.json del trabajo de respaldo seleccionado para reconstruir la lista de DBIDs y los parámetros de respaldo.
Fase B — preparación de archivos. Bacula entrega los archivos de flujo de respaldo a un directorio de preparación temporal en $TMPDIR.
Fase C — compuerta del nucleus. El plugin verifica que allow_destructive_restore=yes esté configurado (la compuerta evita sobreescrituras accidentales) y comprueba el estado fuera de línea del nucleus.
Fase D — adabck RESTORE. El archivo de respaldo preparado se suministra a adabck RESTORE=* a través de un FIFO con nombre. El nucleus es sobreescrito.
Fase E — verificación. adavfy ejecuta una verificación de consistencia en el nucleus restaurado. Si verify_after_restore=yes (predeterminado), una verificación fallida termina el trabajo con un error.

Restauración a un punto en el tiempo (PITR)

Después de que se completa una restauración completa (Fases A–E), los PLOGs se aplican en secuencia usando adarec CHECKPOINT=(first,last). Los nombres de checkpoint se sanean a [A-Z0-9_]{0,8} antes de pasarse a adarec para prevenir la inyección de DSL desde manifiestos hostiles. Las versiones futuras admitirán restore_to_time=<ISO8601> mediante la resolución de marca de tiempo a checkpoint con adaplp (hoja de ruta v1.1.0).

  adabck RESTORE=* (full) → adavfy CHECK → adarec CHECKPOINT=(sync,last) [per PLOG in order]

5. Matriz de funcionalidades

Funcionalidad	Level F (Completo)	Level I (PLOG Incr)	Restauración
Respaldo en línea (hot)	Sí	Sí	N/A
Encapsulado EXT_BACKUP quiet point	Sí (predeterminado activo)	N/A	N/A
Integración adabck DUMP	Sí	No	N/A
Archivado de PLOG	No	Sí (licenciado)	N/A
Integración adabck RESTORE	N/A	N/A	Sí (licenciado)
Aplicación de PLOG con adarec (PITR)	N/A	N/A	Sí (licenciado)
Verificación post-restauración con adavfy	N/A	N/A	Sí (predeterminado activo)
Múltiples DBIDs por trabajo	Sí	Sí	Sí
Integración con catálogo de Bacula	Sí	Sí	Sí
Objeto JSON BackupManifest	Sí	Sí (PlogManifest)	Lectura
Compresión LZ4 (Bacula)	Sí	Sí	N/A
Tiempos límite configurables	Sí	Sí	Sí
Cancelación segura por señal	Sí	Sí	Sí
Detección de sequence-wrap	N/A	Sí	N/A
Eliminación de PLOG con compuerta de seguridad	N/A	Sí	N/A
Streaming por stdout (BCK001=-)	Sí	N/A	N/A
Modo de reserva con archivo temporal	Sí	N/A	N/A
Soporte a wrapper de Podman	Sí	Sí	Sí
Soporte a ADABAS CE 7.x	Sí (external_backup=no)	No (PLOGs bloqueados)	Parcial
Soporte a ADABAS licenciado 8.x	Sí	Sí	Sí
PITR basado en checkpoint	N/A	N/A	Sí (licenciado)
CLI de diagnóstico (–probe-nucleus)	Sí	Sí	Sí
Escritura atómica de archivo de estado	N/A	Sí	N/A

6. Guía de instalación

6.1 Requisitos previos

PodHeitor Backup o posterior instalado y bacula-fd en ejecución
ADABAS 7.x (Community) o 8.x+ (licenciado) instalado en el mismo host que bacula-fd
Utilitarios de ADABAS adabck, adaopr, adavfy, adarec disponibles en $PATH (o rutas completas configuradas mediante la cadena de plugin)
SO: Linux x86_64 o aarch64
El usuario que ejecuta bacula-fd debe poder ejecutar los utilitarios de ADABAS como el DBA de ADABAS (típicamente sagadmin) — ya sea por co-localización bajo el mismo UID o mediante reglas de sudo configuradas

6.3 Prueba de humo posterior a la instalación

# Valide que el backend puede alcanzar el nucleus de ADABAS
/opt/bacula/bin/podheitor-adabas-backend --probe-nucleus 12
# Esperado: DBID=12 ONLINE adanuc=<version>

# Si OFFLINE o UNKNOWN:
#  OFFLINE  = proceso ADANUC no está en ejecución; inícielo
#  UNKNOWN  = adaopr rechazó el DBID; verifique que $PATH incluya el directorio bin de ADABAS,
#             o pase --adaopr-path=/ruta/absoluta/a/adaopr

6.4 Paquetes RPM / DEB

Los paquetes RPM y DEB están planificados para el lanzamiento de disponibilidad general v1.0.0. Consulte el estado de publicación en el catálogo de plugins en podheitor.com.

6.5 ADABAS en contenedor (wrapper de Podman)

Cuando los utilitarios de ADABAS no están instalados nativamente en el host del FD sino que se ejecutan dentro de un contenedor de Podman:

# Instale el wrapper (idempotente)
sudo bash scripts/install-podman-wrapper.sh adabas-ce-test

# El wrapper re-ejecuta el backend dentro del contenedor nombrado:
# podman exec -i adabas-ce-test /opt/bacula/bin/podheitor-adabas-backend "$@"

Reversión: una copia de seguridad con marca de tiempo de cualquier ELF backend nativo anterior se conserva en /usr/local/sbin/podheitor-adabas-backend.elf-bak.<ts>.

7. Referencia de configuración

7.1 Parámetros de la cadena de Plugin

Todos los parámetros se pasan en la directiva Plugin = "podheitor-adabas: <param>=<valor> ...". Los parámetros están separados por espacios (no por dos puntos). Tanto snake_case como camelCase son aceptados para cada clave.

Parámetro	Tipo	Predeterminado	Descripción
`dbid`	uint	(requerido)	ID único de la base de datos ADABAS
`dbids`	lista	—	Lista separada por comas para trabajos con múltiples bases de datos: `dbids=12,13,14`
`mode`	enum	`online`	`online` (soportado) o `cold` (diferido)
`external_backup`	bool	`yes`	Encapsula DUMP en `adaopr EXT_BACKUP=PREPARE/CONTINUE`. Debe ser `no` en Community Edition
`plog`	bool	`yes`	Archiva PLOGs durante trabajos Level I. Sin efecto en CE
`plog_dir`	ruta	autodetectado	Directorio que contiene los archivos PLOG.*
`adabck_path`	ruta	`adabck`	Ruta completa alternativa para el utilitario adabck
`adaopr_path`	ruta	`adaopr`	Ruta completa alternativa para adaopr
`adavfy_path`	ruta	`adavfy`	Ruta completa alternativa para adavfy
`adarec_path`	ruta	`adarec`	Ruta completa alternativa para adarec (aplicación de PLOG)
`stream_mode`	enum	`auto`	`auto` (= stdout), `stdout`, o reserva `tempfile`
`buffer_size`	tamaño	`8m`	Búfer de streaming (acepta sufijos K/M/G)
`allow_destructive_restore`	bool	`no`	Compuerta obligatoria para restauración — sin esto, la restauración se niega a sobreescribir una base de datos existente
`verify_after_restore`	bool	`yes`	Ejecuta `adavfy DBID=<N>` después de la restauración
`restore_to_checkpoint`	cadena	—	Objetivo de PITR: nombres de checkpoint `"first,last"`
`restore_to_time`	marca de tiempo	—	Marca de tiempo ISO 8601 (v1.1.0: resolución mediante adaplp)
`config_file`	ruta	`/opt/bacula/etc/podheitor-adabas.conf`	Archivo que contiene líneas de parámetros predeterminados, combinados con la cadena de plugin del trabajo
`status_timeout_secs`	uint	10	Límite de tiempo de pared para la sondeo de estado de adaopr
`backup_timeout_secs`	uint	14400	Límite de tiempo de pared para el subproceso DUMP (4 horas)
`restore_timeout_secs`	uint	14400	Límite de tiempo de pared para el subproceso RESTORE (4 horas)
`adarec_timeout_secs`	uint	1800	Límite de tiempo de pared por llamada adarec por PLOG (30 min)
`verify_timeout_secs`	uint	300	Límite de tiempo de pared para adavfy (5 min)
`plog_ship_retries`	uint	2	Máximo de reintentos (backoff exponencial) en fallo transitorio de envío de PLOG

7.2 Variables de entorno

Variable	Efecto
`ADABAS_LOG_LEVEL`	Nivel de detalle: `off`, `error`, `warn`, `info` (predeterminado), `debug`, `trace`. Alias: `err`, `warning`, numérico 0–5.
`ADABAS_DBID`	DBID alternativo opcional para `--probe-nucleus`. El plugin siempre prefiere el `dbid=` del lado DSL.
`PODHEITOR_ADAOPR_PATH`	Reemplaza la ruta de adaopr usada por `--probe-nucleus`. Útil en entornos en contenedores.

7.3 Archivo de configuración — valores predeterminados compartidos

Cree /opt/bacula/etc/podheitor-adabas.conf para compartir valores predeterminados entre muchos trabajos:

# Una clave=valor por línea; # inicia un comentario
external_backup      = yes
stream_mode          = auto
buffer_size          = 16m
verify_after_restore = yes
status_timeout_secs  = 15
backup_timeout_secs  = 21600

El plugin lee este archivo primero y luego superpone los parámetros del Plugin = "..." del trabajo — los valores por trabajo siempre tienen precedencia.

8. Ejemplos de FileSet

8.1 DBID único — respaldo completo semanal + incremental por hora

FileSet {
  Name = "ADABAS-DBID-12"
  Include {
    Options {
      signature   = MD5
      compression = LZ4
    }
    Plugin = "podheitor-adabas: dbid=12"
  }
}

Schedule {
  Name = "ADABAS-Weekly"
  Run = Level=Full         sun at 02:00
  Run = Level=Incremental  mon-sat at *:00
}

Job {
  Name     = "ADABAS-DBID-12"
  Type     = Backup
  Level    = Incremental
  FileSet  = "ADABAS-DBID-12"
  Client   = "adabas-host-fd"
  Storage  = "File"
  Pool     = "ADABAS-Pool"
  Messages = "Standard"
  Schedule = "ADABAS-Weekly"
  Max Run Sched Time = 6 hours
}

8.2 Múltiples DBIDs — tres bases de datos en un trabajo

FileSet {
  Name = "ADABAS-Prod-Cluster"
  Include {
    Options { signature = MD5; compression = LZ4 }
    Plugin = "podheitor-adabas: dbids=12,13,14"
  }
}

Después de un trabajo completo, bconsole: list files jobid=<N> muestra:

/@ADABAS/dbid-12/full-<ts>.adabck
/@ADABAS/dbid-12/_manifest.json
/@ADABAS/dbid-13/full-<ts>.adabck
/@ADABAS/dbid-13/_manifest.json
/@ADABAS/dbid-14/full-<ts>.adabck
/@ADABAS/dbid-14/_manifest.json

8.3 Community Edition — external_backup=no obligatorio

FileSet {
  Name = "ADABAS-CE-DBID-12"
  Include {
    Options { signature = MD5 }
    Plugin = "podheitor-adabas: dbid=12 external_backup=no plog=no"
  }
}

8.4 Alto volumen — reserva con archivo temporal

Plugin = "podheitor-adabas: dbid=12 stream_mode=tempfile buffer_size=16m"

8.5 Tiempos límite personalizados para VLDB muy grandes

Plugin = "podheitor-adabas: dbid=12 status_timeout_secs=30 backup_timeout_secs=28800 verify_timeout_secs=900"

8.6 Restauración interactiva

bconsole: restore client=adabas-host-fd
# Seleccione los archivos en /@ADABAS/dbid-12/, luego:
pluginoptions "podheitor-adabas: dbid=12 allow_destructive_restore=yes"

8.7 Restauración a un punto en el tiempo (solo ADABAS licenciado)

bconsole: restore
pluginoptions "podheitor-adabas: dbid=12 allow_destructive_restore=yes restore_to_checkpoint=SYNC,W8NW verify_after_restore=yes"

9. Dimensionamiento y planificación de capacidad

9.1 Requisitos de memoria

Escenario	Pico de memoria (proceso backend)
Respaldo completo (modo stdout)	~2 MB (búfer de streaming de 1 MiB + overhead del backend) — validado: 1,94 MB VmHWM para volcado de 7,27 MB
Respaldo completo (modo tempfile)	~2 MB backend + espacio en disco temporal igual al tamaño del volcado
Incremental (archivado de PLOG)	~2 MB por DBID activo — los PLOGs son pequeños (típicamente 4 KB–64 KB cada uno)
Trabajo con múltiples DBIDs (N DBIDs)	Procesamiento secuencial — el pico de memoria es el overhead de un solo DBID, no N×
Restauración (adabck RESTORE)	~2 MB backend + búfer FIFO; la memoria real de RESTORE está en el nucleus de ADABAS, no en el plugin

Punto de diseño clave. La arquitectura de streaming utiliza un búfer fijo de 1 MiB — la memoria es O(1) independientemente del tamaño de la base de datos. Un volcado de ADABAS de 500 GB utiliza la misma memoria pico de 2 MB del backend que una base de datos de demostración de 7 MB.

9.2 Requisitos de CPU

Escenario	Núcleos recomendados
Respaldo completo con DBID único	1 (limitado por I/O del rendimiento de adabck)
Trabajo con múltiples DBIDs (secuencial)	1–2
PLOG incremental (N PLOGs)	1 (procesamiento secuencial por PLOG)
Restauración + PITR	1–2

9.3 Espacio en disco — binarios del plugin

Archivo	Tamaño
`podheitor-adabas-fd.so`	~600 KB (perfil release con LTO)
`podheitor-adabas-backend`	~680 KB (perfil release con LTO)
Total de la instalación	~1,3 MB

9.4 Espacio en disco — directorio de estado

Cada DBID rastreado para trabajos incrementales de PLOG almacena un archivo de estado JSON de aproximadamente 2–4 KB. Para 100 bases de datos, el directorio de estado requiere menos de 400 KB — insignificante.

9.5 Estimaciones de volumen de respaldo

Modo	Tamaño esperado
Respaldo completo (sin compresión adicional)	Aproximadamente igual a la suma de los tamaños de los contenedores ASSO + DATA
Respaldo completo + LZ4 (compresión de FileSet de Bacula)	Típicamente 60–80% de los tamaños brutos de los contenedores, dependiendo de los patrones de datos
PLOG incremental por intervalo	Típicamente < 1% del tamaño del respaldo completo por hora; altamente dependiente de la carga de trabajo

10. Informe de rendimiento

Todas las mediciones se realizaron en un entorno de laboratorio controlado usando el contenedor oficial de ADABAS Community Edition 7.4.0 de Software AG (softwareag/adabas-ce:7.4.0, DBID=12, bases de datos de demostración EMPLOYEES/VEHICLES/MISCELLANEOUS) ejecutándose en un host Linux con PodHeitor Backup. La CE impone límites en los parámetros del nucleus (NT=3, NU=5, LWP=1 MB, TCPCONN=4) — estos son benchmarks orientativos; el rendimiento en producción con ADABAS licenciado será diferente.

10.1 Respaldo completo — modo de streaming por stdout

Métrica	Resultado
Base de datos	ADABAS CE 7.4.0 DBID=12 (EMPLOYEES/VEHICLES/MISCELLANEOUS)
Tamaño del respaldo	7.275.028 bytes (7,27 MB)
Modo de flujo	stdout (BCK001=-)
Pico de memoria del backend (VmHWM)	1,94 MB
Proporción memoria/datos	0,27 (O(1) — búfer fijo)
BackupManifest emitido	Sí — 434 bytes, los 12 campos validados
Código de salida de adabck	0
Código de salida del backend	0

10.2 Respaldo completo — modo de reserva con archivo temporal

Métrica	Resultado
Tamaño del respaldo	7.274.968 bytes
Modo de flujo registrado en el manifiesto	tempfile
Estado	APROBADO — el recuento de bytes corresponde al modo stdout (diferencia de 12 bytes de overhead de trama esperada)

10.3 Agregación best-effort con múltiples DBIDs

Métrica	Resultado
DBIDs en el trabajo	12 (en línea), 99 (inexistente)
Resultado del DBID=12	Respaldo preservado en el catálogo
Resultado del DBID=99	Falló con mensaje claro — DBID=99 UNKNOWN
Error agregado reportado	Sí — registro del trabajo: «1 DBID(s) OK ([12]), 1 failed ([99])»
Integridad de datos del DBID=12	No corrompida por el fallo del DBID=99

10.4 Archivado de PLOG incremental (fixtures sintéticos)

Métrica	Resultado
Archivos PLOG de fixture	3 archivos (seq 4, 5, 6), 4 KB cada uno
Tamaño del trabajo incremental	3 × 4 KiB + PlogManifest ≈ 0,18% del respaldo completo de 7 MB
Simulación de sequence-wrap	APROBADO — PLOG.0001 después de last_seen=6 → generation++ registrado
Idempotencia (ejecución 2)	APROBADO — 0 PLOGs candidatos, 3 previamente archivados
Eliminación con compuerta de seguridad	APROBADO — PLOGs anteriores eliminados del directorio de fixtures tras la ejecución 2

10.5 Orquestación de restauración

Caso de prueba	Resultado
Restauración sin allow_destructive_restore=yes	APROBADO — rechazó con mensaje claro
Restauración con manifiesto faltante	APROBADO — «No backup manifest found for DBID=12»
Orquestación de restauración Fases A→E	APROBADO (bloqueado por licencia CE en la finalización de la Fase D)
Agrupamiento de restauración con múltiples DBIDs	APROBADO — 2 manifiestos agrupados por segmento vpath

11. Matriz de compatibilidad

11.1 Sistema operativo

SO	Arquitectura	Estado
RHEL 9 / Oracle Linux 9 / Rocky 9	x86_64	Soportado
Ubuntu 22.04 LTS	x86_64	Soportado
Debian 12	x86_64	Soportado
Linux (cualquier distribución moderna)	aarch64	Soporte planeado; paquetes en preparación
AIX	POWER	Fuera del alcance de este plugin (contrato separado)
z/OS	System/390	Fuera del alcance (contrato de mainframe)
Windows	x86_64	Explícitamente fuera del alcance

11.2 Versiones de ADABAS

Versión	Plataforma	Respaldo Level F	PLOG Level I	Restauración
7.4.x CE (softwareag/adabas-ce:7.4.0)	Contenedor Linux	Sí (external_backup=no)	No (bloqueado por licencia)	Parcial (solo orquestación)
8.x+ licenciado	Linux	Sí (external_backup=yes)	Sí	Sí
z/OS / BS2000	Mainframe	Fuera del alcance	Fuera del alcance	Fuera del alcance

11.3 Versiones de Bacula

Versión de Bacula	Estado
Community 15.0.3	Soportado y validado
Community 15.0.x (futuro)	Se espera compatibilidad (framework de plugin PodHeitor sigue el ABI)
Community 14.x y anteriores	No soportado (el framework framework de plugin PodHeitor requiere 15.0.3+)
Bacula Enterprise	No requerido; el plugin apunta a PodHeitor Backup

11.4 Capa de aplicación Natural / NaturalONE

El plugin protege la capa del motor de base de datos ADABAS (contenedores ASSO, DATA, WORK y PLOGs). El código fuente de las aplicaciones Natural y los artefactos de proyecto de NaturalONE son objetos del sistema de archivos y deben respaldarse con trabajos estándar de respaldo a nivel de archivo de Bacula. El respaldo de la capa de aplicación está explícitamente fuera del alcance de este plugin.

12. Seguridad

12.1 Sin credenciales embebidas

El plugin no maneja contraseñas de ADABAS — la autenticación de ADABAS es gestionada por el nucleus mediante la interfaz de operador y SysV IPC, no mediante usuario/contraseña en la configuración del trabajo de respaldo. No hay credenciales que embeber, almacenar ni redactar en la configuración de Bacula.

12.2 Prevención de inyección de DSL

Los nombres de checkpoint pasados a adarec CHECKPOINT=(first,last) se sanean a la clase de caracteres [A-Z0-9_]{0,8} antes de pasarse al subproceso. Esto previene la inyección de palabras clave arbitrarias de DSL de ADABAS desde un _plog_manifest.json hostil o corrupto.

12.3 Validación de rutas

Los parámetros adabck_path, adaopr_path, adavfy_path y adarec_path se validan para no contener metacaracteres de shell antes de pasarse a Command::new(). No hay sh -c en ninguna parte del backend — todas las invocaciones de subprocesos usan Command::args([]) directamente.

12.4 Compuerta de restauración destructiva

La restauración se niega incondicionalmente a continuar a menos que allow_destructive_restore=yes esté explícitamente configurado en las opciones del plugin. Esta compuerta no puede ser sorteada por una definición de Job mal configurada — debe estar presente como una decisión explícita del operador en el momento de la restauración. El mensaje de la compuerta es:

[podheitor-adabas] restore refused: allow_destructive_restore=yes required

12.5 Aislamiento de subprocesos

El plugin FD crea (fork) un proceso backend por trabajo de Bacula. No existe estado mutable compartido entre trabajos de respaldo concurrentes. Si el backend falla o es terminado por una señal externa, el plugin FD reporta un fallo del trabajo y bacula-fd continúa atendiendo otros trabajos normalmente. Cada subproceso tiene un límite de tiempo de pared — un proceso adabck o adarec descontrolado no puede bloquear permanentemente el Bacula File Daemon.

12.6 Manejo de archivos temporales

Los archivos temporales creados durante los respaldos en modo tempfile y la preparación de restauración usan un sufijo de ID de proceso para evitar colisiones entre trabajos concurrentes. El backend limpia automáticamente los directorios de preparación en todas las rutas de salida — incluidos fallos y cancelación por SIGTERM. En SIGTERM/SIGINT, se establece y verifica un flag atómico global entre lecturas de streaming; el plugin termina de forma limpia sin dejar archivos huérfanos.

12.7 Permisos del archivo de estado

El directorio de estado /opt/bacula/working/podheitor-adabas-state/ se crea con modo 0750, propietario bacula. Los archivos de estado se escriben con tmpfile-then-rename atómico para prevenir la corrupción por escritura parcial en caso de fallo o corte de energía.

13. Monitoreo

13.1 Códigos de estado del trabajo de Bacula

El plugin establece los códigos de estado estándar del trabajo de Bacula:

T — terminado normalmente; todos los DBIDs respaldados exitosamente
E — terminado con errores; uno o más DBIDs fallaron (detalles en el registro del trabajo)
f — error fatal; el backend falló al iniciar o se bloqueó antes de intentar cualquier DBID

13.2 Mensajes del registro del trabajo

Todos los mensajes del plugin tienen el prefijo [podheitor-adabas] y se enrutan al registro del trabajo de Bacula mediante paquetes canal interno info. Salida estándar de un respaldo completo exitoso:

[podheitor-adabas] DBID=12 ONLINE adanuc=7.4.0.3
[podheitor-adabas] DBID=12 EXT_BACKUP PREPARE issued
[podheitor-adabas] DBID=12 dump (stdout): 7274972 bytes → /@ADABAS/dbid-12/full-20260424T020851Z.adabck
[podheitor-adabas] DBID=12 manifest: /@ADABAS/dbid-12/_manifest.json
[podheitor-adabas] DBID=12 EXT_BACKUP CONTINUE issued
[podheitor-adabas] backup summary: 1 DBID(s) OK ([12]), 0 failed, 7274972 bytes total

13.3 Ubicaciones de los archivos de registro

Registro	Ruta
Registro del backend del plugin	`/opt/bacula/working/podheitor-adabas-backend.log` (alternativo: `/tmp/podheitor-adabas-backend.log`)
Registro del trabajo de Bacula	Mediante `bconsole: list messages` o a través de Bacularis
Archivo de estado del plugin	`/opt/bacula/working/podheitor-adabas-state/dbid-<N>.json`

13.4 Registro de depuración

Establezca ADABAS_LOG_LEVEL=debug (o trace para el registro completo de tramas canal interno) en el entorno de bacula-fd para habilitar la salida detallada:

ADABAS_LOG_LEVEL=debug bconsole: run job=ADABAS-DBID-12-Full yes

13.5 CLI de sondeo del nucleus

# Verifique la accesibilidad y versión del nucleus en cualquier momento (sin necesidad de trabajo de Bacula)
/opt/bacula/bin/podheitor-adabas-backend --probe-nucleus 12
# Esperado: DBID=12 ONLINE adanuc=<version>

13.6 Integración con Bacularis

Todos los trabajos de respaldo de ADABAS son ciudadanos de primera clase en Bacularis — aparecen en la lista de trabajos, sus archivos virtuales (incluidos _manifest.json y entradas de PLOG) son navegables, y los trabajos de restauración pueden iniciarse desde la interfaz web de Bacularis. No se requieren extensiones específicas de ADABAS para Bacularis.

14. Guía de resolución de problemas

14.1 Errores comunes

Restauración rechazada — parámetro de compuerta faltante

[podheitor-adabas] restore refused: allow_destructive_restore=yes required

Causa. La compuerta de seguridad funciona según lo diseñado. Solución. Pase allow_destructive_restore=yes en la directiva pluginoptions solo cuando pretenda sobreescribir la base de datos objetivo.

Manifiesto de respaldo no encontrado

[podheitor-adabas] No backup manifest found for DBID=12

Causa. La selección de archivos del trabajo de restauración no incluye el _manifest.json. Solución. Vuelva a seleccionar el espacio de nombres virtual completo /@ADABAS/dbid-12/* durante la selección de restauración.

ADABCK abortado — interbloqueo CE + EXT_BACKUP

Subprocess 'adabck DBID=12 DUMP=*' exit=<C>: %ADABCK-I-ABORTED

Causa. En CE, EXT_BACKUP=PREPARE antes de adabck DUMP=* provoca que adabck se bloquee en do_msgrcv esperando el IPC del nucleus — una restricción conocida de CE. Solución. Establezca external_backup=no en la cadena de plugin para trabajos CE. El ADABAS licenciado en producción debe mantener el valor predeterminado external_backup=yes.

Tiempo límite de subproceso

child did not exit within <N>s — killed

Causa. Un subproceso (adabck, adavfy, adarec) excedió su límite de tiempo de pared configurado. Solución. Diagnostique si la operación subyacente realmente requiere más tiempo; si es así, aumente el parámetro *_timeout_secs relevante.

Trabajo cancelado en medio del flujo

cancelled by signal (SIGTERM/SIGINT) mid-stream

Causa. Comportamiento esperado — el operador canceló el trabajo de Bacula, o bacula-fd envió SIGTERM. Solución. No se requiere ninguna acción; los archivos temporales se limpian automáticamente por el mecanismo de limpeza automática do backend.

probe-nucleus devuelve UNKNOWN

/opt/bacula/bin/podheitor-adabas-backend --probe-nucleus 12 → UNKNOWN

Causa. adaopr salió con código distinto de cero — DBID incorrecto, utilitarios de ADABAS no están en PATH, o el nucleus no está en ejecución. Solución. Verifique que $PATH incluya el directorio bin de ADABAS; confirme que el DBID existe mediante adainfo.sh <DBID>; o especifique --adaopr-path=/ruta/absoluta.

El trabajo incremental reporta 0 PLOGs candidatos

[podheitor-adabas] DBID=12: 0 candidate PLOG(s); 0 already archived; 0 new

Causa (a). Ningún PLOG ha rotado desde el último trabajo — normal en un entorno de baja actividad. Causa (b). CE está en uso — los PLOGs no son emitidos por el nucleus de Community Edition. Solución. En ambos casos esto es esperado; no se requiere ninguna acción.

14.2 Referencia de comandos de diagnóstico

# ¿El nucleus es accesible?
/opt/bacula/bin/podheitor-adabas-backend --probe-nucleus 12

# Registro detallado en una sola ejecución para un trabajo de respaldo
ADABAS_LOG_LEVEL=debug bconsole: run job=ADABAS-DBID-12-Full yes

# Inspeccione el archivo de estado del plugin (solo lectura; nunca edite manualmente)
cat /opt/bacula/working/podheitor-adabas-state/dbid-12.json

# Verifique que el plugin está cargado en el FD
echo "status client=$(hostname)-fd" | bconsole | grep -i adabas

15. Casos de uso y escenarios de implementación

15.1 Base de datos de abonados de telecomunicaciones

Escenario. Una operadora nacional de telecomunicaciones ejecuta la gestión de abonados y el almacenamiento de CDR (Call Data Record) en ADABAS 8.x licenciado, con dos instancias DBID, con DATA+ASSO combinados totalizando 400 GB. El requisito regulatorio es de retención de datos por 7 años con un RTO de 4 horas y un RPO de 1 hora.

Solución.

Respaldo completo (Level F) semanal, los domingos a las 02:00, con external_backup=yes (predeterminado)
Respaldo incremental (Level I) por hora — archivado de PLOG cada hora, de lunes a sábado
Pool de Bacula con retención de volúmenes por 7 años
Copia externa a cinta o nube mediante trabajo de migración estándar de Bacula

Resultado. RPO ≈ 1 hora, RTO determinado por el tiempo de restauración de ADABAS (< 4 horas para 400 GB sobre LAN Gigabit a almacenamiento local). Cumplimiento total con los requisitos de retención regulatoria sin ningún cambio en las aplicaciones existentes de ADABAS o Natural.

15.2 Libro contable de core banking

Escenario. Un banco regional ejecuta su libro contable de procesamiento de transacciones en ADABAS en IBM AIX… migrando a Linux. La nueva instancia ADABAS 8.x en Linux debe cumplir los requisitos de trazabilidad de datos de BCBS 239 — cada transacción debe ser recuperable hasta un checkpoint nombrado.

Solución.

Respaldo completo nocturno con external_backup=yes y verify_after_restore=yes
Archivado de PLOG incremental cada 15 minutos
Restauración a un punto en el tiempo probada trimestralmente usando restore_to_checkpoint=SYNC,<checkpoint>
JSON BackupManifest almacenado en el catálogo de Bacula — proporciona la pista de evidencia auditable

15.3 Registro de personal gubernamental

Escenario. Un organismo nacional de seguridad social ejecuta ADABAS en Linux para su registro de personal con 40 millones de registros. Las restricciones presupuestarias prohíben el licenciamiento de plataformas comerciales de respaldo. PodHeitor Backup ya está en uso para respaldos a nivel de archivo en todo el organismo.

Solución.

Implemente el plugin de PodHeitor en la infraestructura existente de PodHeitor Backup — costo de plataforma cero
Respaldo completo semanal; PLOG incremental por hora
Extienda los pools y programaciones existentes de Bacula para cubrir los trabajos de ADABAS
Sin nuevo software de respaldo, sin nuevos licenciamientos, sin reentrenamiento para el equipo Bacula existente

15.4 Motor de reserva de pólizas de seguros

Escenario. Una compañía de seguros ejecuta ADABAS como su motor de reserva de pólizas con ejecuciones de lote nocturnas que calculan reservas para 5 millones de pólizas. La ejecución de lote modifica millones de registros; el requisito de RTO es de 2 horas (tiempo para re-ejecutar el lote si ADABAS se corrompe).

Solución.

Respaldo completo inmediatamente después del lote (aprox. 03:00) con un backup_timeout_secs=21600 personalizado para bases de datos grandes
Archivado de PLOG cada 30 minutos durante la ejecución del lote para habilitar recuperación detallada
Verificación de consistencia adavfy después de cada restauración (predeterminado activo) proporciona prueba auditable de la integridad de la recuperación

15.5 Desarrollo/CI — contenedor ADABAS CE

Escenario. Un equipo de software que desarrolla aplicaciones Natural/ADABAS necesita proteger su entorno de desarrollo CE y probar el plugin de respaldo en CI antes de implementarlo en producción.

Solución.

Ejecute el contenedor oficial de ADABAS CE: podman run -d --name adabas-ce-test softwareag/adabas-ce:7.4.0
Use external_backup=no plog=no en el FileSet (restricciones de CE)
Implemente el wrapper de Podman para hacer el puente entre el FD del host y los utilitarios en el contenedor
El respaldo completo valida todo el pipeline plugin → canal interno → adabck en CI sin ningún costo

Plugin = "podheitor-adabas: dbid=12 external_backup=no plog=no stream_mode=auto"

16. Comparación con otros enfoques

16.1 Comparación de funcionalidades

La tabla a continuación compara el plugin ADABAS de PodHeitor ejecutándose en PodHeitor Backup con formas alternativas de proteger datos de ADABAS. Bacula Enterprise se incluye como referencia: ofrece un excelente respaldo empresarial de propósito general y sigue siendo una opción sólida cuando se necesitan características más amplias de BEE; este plugin está construido específicamente para ofrecer funcionalidades específicas de ADABAS (cadenas incrementales de PLOG, PITR basado en checkpoint, integración de quiet-point en línea, almacenamiento nativo de manifiesto en el catálogo) sobre la base de PodHeitor Backup.

Funcionalidad	PodHeitor Backup + PodHeitor	Bacula Enterprise	Veeam	Commvault	NetBackup
ADABAS nativo (integración adabck)	Sí	No	No	No	No
Respaldo en línea (hot) con quiet point	Sí	No	No	No	No
Archivado de PLOG incremental	Sí	No	No	No	No
Restauración a un punto en el tiempo (checkpoint)	Sí (ADABAS licenciado)	No	No	No	No
Verificación post-restauración con adavfy	Sí	No	No	No	No
Múltiples DBIDs por trabajo	Sí	No	No	No	No
Integración con catálogo de Bacula	Sí	Sí	N/A	N/A	N/A
Objeto JSON BackupManifest	Sí	No	No	No	No
Compresión (LZ4 / zstd vía Bacula)	Sí	Sí	Sí	Sí	Sí
Cifrado	Sí (nativo Bacula)	Sí	Sí	Sí	Sí
Limitación de ancho de banda	Sí (nativo Bacula)	Sí	Sí	Sí	Sí
Gestión de retención	Sí (pools de Bacula)	Sí	Sí	Sí	Sí
Compatible con PodHeitor Backup	Sí	N/A	N/A	N/A	N/A
Base de plataforma de código abierto	Sí (Bacula CE)	No	No	No	No
ADABAS CE 7.x probado	Sí	No	No	No	No
Wrapper de Podman para ADABAS en contenedor	Sí	No	No	No	No
Cancelación segura por señal + limpieza de archivos temporales	Sí	N/A	N/A	N/A	N/A

16.2 Comparación de costos

Oferta especial. Traiga su propuesta de renovación de Veeam, Commvault, NetBackup o cualquier otra plataforma de respaldo empresarial. Elaboraremos una propuesta por escrito de comparación directa con un objetivo de al menos 50% de ahorro, con funcionalidades específicas para ADABAS superiores a las que cualquier plataforma comercial ofrece actualmente. Contacte a heitor@opentechs.lat.

Solución	Costo anual típico	Soporte nativo a ADABAS
PodHeitor Backup + plugin PodHeitor	Significativamente menor	Nativo completo (este plugin)
Bacula Enterprise	Frecuentemente > US$ 10.000/año	Ninguno (nivel de archivo o mediante script)
Veeam Data Platform	Frecuentemente > US$ 5.000/año	Ninguno (solo a nivel de VM)
Commvault	Frecuentemente > US$ 15.000/año	Ninguno (solo mediante script)
NetBackup	Frecuentemente > US$ 20.000/año	Ninguno (solo mediante script)

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

17. Hoja de ruta

El plugin está en v1.0.0-ce — validado de extremo a extremo en CE para respaldos completos; las funcionalidades bloqueadas por licencia (aplicación de PLOG, restauración con nucleus fuera de línea) están completas en código y aguardan validación en instancia licenciada.

v1.0.0 (disponibilidad general). Mismo código que la 1.0.0-ce, después de pasar la parte bloqueada por licencia de la matriz de aceptación en un ADABAS de producción. Objetivo: primera instalación de ADABAS licenciado de un cliente.
v1.1.0 (planificado).
- Integración con adaplp para resolver marcas de tiempo restore_to_time=<ISO8601> en nombres de checkpoint automáticamente — habilitando PITR basado en tiempo sin búsqueda manual de nombres de checkpoint
- Reserva transparente de stream_mode=auto — actualmente Auto es un sinónimo de Stdout; haciendo que Auto intente stdout y luego pase silenciosamente a tempfile en ciertos códigos de error
- Modo de respaldo cold — para respaldos en ventana de mantenimiento programada
v1.2.0 (futuro).
- Empaquetado RPM / DEB y publicación en el catálogo de plugins en podheitor.com
- Paquetes binarios para ARM64 / aarch64
- Portabilidad a Windows
- Panel de configuración de plugin de Bacularis para parámetros de trabajo de ADABAS
- Endpoint de métricas extendidas (Prometheus) para contadores de trabajos de respaldo de ADABAS

No se han comprometido fechas de lanzamiento específicas. La dirección de las funcionalidades está guiada por los comentarios de los clientes y los hallazgos del laboratorio con instancias licenciadas.

18. Conclusión

El Plugin de Respaldo ADABAS de PodHeitor extiende PodHeitor Backup con la primera integración de respaldo nativa para ADABAS de calidad para producción disponible en la plataforma Bacula de código abierto. Ofrece respaldo hot en línea mediante adabck DUMP con encapsulado de quiet point transaccional, archivado incremental por hora basado en PLOG para RPO ≈ 1 hora, restauración a un punto en el tiempo basada en checkpoint mediante adarec, y verificación de consistencia post-restauración mediante adavfy — todo gestionado a través de una única directiva de Plugin FileSet de Bacula.

El plugin ha sido validado mediante 78 pruebas unitarias Rust y pruebas de extremo a extremo en CE, con eficiencia de memoria en streaming demostrada en un pico de 1,94 MB para una instancia de ADABAS en ejecución (streaming de memoria constante O(1)). La arquitectura — plugin FD Rust + backend Rust + canal interno otimizado + aislamiento de subprocesos — es el mismo patrón battle-tested utilizado en todos los plugins maduros de PodHeitor.

Para las organizaciones que ejecutan ADABAS en Linux — en telecomunicaciones, banca, seguros o gobierno — el plugin de PodHeitor llena una brecha que ninguna otra herramienta de respaldo de código abierto o comercial aborda actualmente. No requiere cambios en la instalación existente de ADABAS, ninguna modificación en las aplicaciones Natural y ningún reemplazo de una infraestructura Bacula existente. Para las organizaciones que evalúan renovaciones de plataformas comerciales de respaldo, la combinación de PodHeitor Backup y el plugin de PodHeitor ofrece una capacidad de DR específica para ADABAS superior a una fracción del costo.

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 ADABAS 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	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/adabas-plugin
Soporte	heitor@opentechs.lat

20. Legal / derechos de autor

El Plugin de Respaldo ADABAS de PodHeitor para 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 uso en producción.

Bacula® es una marca registrada de Kern Sibbald y la comunidad Bacula. ADABAS® y Software AG® son marcas registradas de Software AG. Natural® y NaturalONE® son marcas registradas de Software AG. Veeam® es una marca registrada de Veeam Software. Commvault® es una marca registrada de Commvault Systems, Inc. NetBackup® es una marca registrada de Veritas Technologies LLC. Todas las demás marcas son propiedad de sus respectivos titulares.

Este documento se proporciona únicamente con fines informativos. Las cifras de rendimiento provienen de mediciones en laboratorio controlado usando ADABAS Community Edition 7.4.0 y pueden variar significativamente en entornos de producción dependiendo del hardware, la versión de ADABAS, la configuración de los parámetros del nucleus, el tamaño de la base de datos y las características de la carga de trabajo. Las funcionalidades bloqueadas por licencia están completas en código y han sido probadas unitariamente, pero no han sido validadas de extremo a extremo en una instancia licenciada de ADABAS; el rendimiento y la compatibilidad en instalaciones licenciadas 8.x+ pueden diferir de las mediciones de CE.

Contacto para licenciamiento: 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