Blog

Whitepaper técnico — PodHeitor ADABAS para Bacula

Whitepaper técnico — PodHeitor ADABAS para Bacula

Whitepaper Técnico — Versão 1.0.0-ce — Maio de 2026

Autor: Heitor Faria · Website: https://podheitor.com · E-mail: heitor@opentechs.lat · Telefone / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Oferta especial. Traga sua proposta de renovação de qualquer plataforma comercial de backup empresarial — Veeam, Commvault, NetBackup ou outras. Produziremos uma proposta de confronto direto com foco em pelo menos 50% de economia, com funcionalidades específicas para ADABAS superiores às de qualquer concorrente. Entre em contato: heitor@opentechs.lat para receber uma cotação por escrito.

Sumário

  1. Resumo executivo
  2. Introdução e contexto de mercado
  3. Visão geral da arquitetura
  4. Modos de backup em detalhe
  5. Matriz de funcionalidades
  6. Guia de instalação
  7. Referência de configuração
  8. Exemplos de FileSet
  9. Dimensionamento e planejamento de capacidade
  10. Relatório de desempenho
  11. Matriz de compatibilidade
  12. Segurança
  13. Monitoramento
  14. Guia de resolução de problemas
  15. Casos de uso e cenários de implantação
  16. Comparação com outras abordagens
  17. Roadmap
  18. Conclusão
  19. Informações de contato
  20. Legal / direitos autorais

1. Resumo executivo

ADABAS (Adaptable DAta BAse System), desenvolvido pela Software AG, é um sistema de gerenciamento de banco de dados hierárquico/navegacional com um histórico de produção excepcionalmente longo — introduzido originalmente em 1971, continua sustentando cargas de trabalho de missão crítica em telecomunicações, bancos, seguradoras e agências governamentais em todo o mundo. ADABAS roda em mainframes z/OS, AIX e Linux, e não é incomum encontrar instâncias ativas do ADABAS protegendo décadas de histórico de transações em setores onde a continuidade legada é exigida por regulação.

Apesar desse enorme peso crítico, o backup do ADABAS em ambientes Linux tem sido historicamente gerenciado por meio de utilitários nativos da Software AG — ADASAV, ADABCK, ADAREP — invocados por scripts de shell de operadores, ou por snapshots de sistema de arquivos em nível de SO que não garantem consistência do banco de dados. Nenhuma dessas abordagens se integra a um catálogo de backup corporativo, fornece fluxos de restauração verificados ou oferece o gerenciamento de retenção, criptografia e agendamento baseado em políticas que os padrões modernos de proteção de dados exigem.

O Plugin de Backup ADABAS da PodHeitor para Bacula fecha essa lacuna. É um plugin para o Bacula File Daemon, nativo em Rust e de qualidade para produção, que integra backup e restauração do ADABAS diretamente ao Bacula Community 15.0.3+. O plugin encapsula os utilitários nativos do ADABAS (adabck, adaopr, adavfy, adarec) por meio de uma camada de subprocesso com tipo seguro e limite de tempo, transmite dados de backup sobre o protocolo PTCOMM e armazena tudo no catálogo padrão do Bacula. Backups completos, incrementais baseados em PLOG, jobs com múltiplos DBIDs, restauração point-in-time e verificação de consistência pós-restauração são todos gerenciados por meio de uma única string de Plugin do Bacula — sem scripts de operadores, sem sequenciamento manual.

Testes de validação na Community Edition (CE) 7.4.0.3 confirmaram: 78 testes unitários Rust aprovados, backup completo ponta a ponta (7,27 MB, exit 0, manifesto válido), perfil de memória em streaming de 1,94 MB no pico para um dump de 7,27 MB (streaming de memória constante O(1)), agregação de múltiplos DBIDs em modo best-effort e cancelamento seguro por sinal. Funcionalidades bloqueadas por licença (aplicação de PLOG em modo online, conclusão de restauração com nucleus offline) estão completas em código e aguardam validação ponta a ponta em uma instância licenciada do ADABAS.

Para qualquer organização que execute ADABAS no Linux com Bacula Community, o plugin da PodHeitor é o caminho mais completo e mais econômico para uma postura de backup defensável e auditável — sem substituir a plataforma de backup já em operação.

2. Introdução e contexto de mercado

2.1 ADABAS em produção hoje

ADABAS ocupa uma posição única no cenário de bancos de dados. Não é um sistema acadêmico de nicho — é o banco de dados que manteve telecomunicações nacionais inteiras, câmaras de compensação bancária e registros de apólices de seguros funcionando por quarenta anos antes que os sistemas relacionais modernos amadurecessem. Sua arquitetura reflete sua época: um modelo de dados hierárquico e de acesso direto com registros de comprimento fixo, acoplado à linguagem de programação Natural 4GL desenvolvida em paralelo pela Software AG. Características principais:

  • Modelo hierárquico / navegacional. Os dados são armazenados como campos numerados (FDT — Field Definition Table) acessados por ISN (Internal Sequence Number), permitindo leituras sequenciais e diretas extremamente rápidas em grandes conjuntos de dados planos.
  • Processamento de transações de alto throughput. O ADABAS usa uma arquitetura Multi-User Facility (MUF) com filas de mensagens SysV IPC para comunicação entre processos, permitindo milhares de operações simultâneas NUC (Nucleus).
  • Modelo de contêineres PLOG / ASSO / DATA / WORK. O banco de dados é fisicamente dividido em contêineres ASSO (associador), DATA, WORK e PLOG (Protection LOG) — cada um com semântica de backup independente.
  • Integração com a linguagem Natural. A maioria das aplicações ADABAS é escrita em Natural, e o IDE NaturalONE / ambiente de desenvolvimento NaturalOne acopla fortemente a lógica de aplicação ao esquema.
  • Legado multiplataforma. ADABAS roda em z/OS, BS2000, AIX, HP-UX e Linux. Este plugin tem como alvo o Linux (x86_64, aarch64), que é o principal destino de implantação para novas instalações do ADABAS e para organizações que migram de mainframe para hardware de commodity.

Setores onde o ADABAS permanece em produção ativa:

  • Telecomunicações: gerenciamento de assinantes, faturamento e armazenamento de registros de dados de chamadas (CDR) em operadoras nacionais no Brasil, Alemanha, África do Sul e outros países.
  • Serviços financeiros: livros-razão de core banking, sistemas de liquidação de compensações e motores de reserva de apólices de seguros.
  • Governo: registros de pessoal, registros de previdência social e bases de dados tributárias — especialmente na América Latina, Europa Central e África Subsaariana.
  • Utilidades: faturamento de clientes para redes de distribuição de eletricidade e água.

2.2 Por que as abordagens de backup existentes são insuficientes

Abordagem Consistência com ADABAS Veredicto
Bacula Community (nível de arquivo, sem plugin) Nenhuma — realiza backup dos arquivos de contêiner brutos enquanto o ADABAS MUF está em execução Inseguro — ASSO/DATA estão em estado inconsistente no meio de uma transação
Snapshot LVM / ZFS em nível de SO Consistente com crash, na melhor das hipóteses Requer quiesce do nucleus; sem integração com PLOG; sequenciamento manual de recuperação
Veeam Sem agente nativo para ADABAS Backup apenas em nível de VM; sem recuperação do ADABAS consistente com a aplicação
Commvault Sem iDataAgent para ADABAS Apenas integração via script personalizado
NetBackup Sem tipo de política para ADABAS Apenas nível de SO; sem integração com o ponto de quiesce do Nucleus
Apenas ferramentas nativas Software AG (ADASAV, ADABCK) Consistência total Sem catálogo, sem gerenciamento de retenção, sem agendamento por política, sem integração de criptografia; intervenção manual do operador na restauração
Scripts de shell personalizados encapsulando adabck Parcial — a correção depende da qualidade do script Não adequado para produção; sem retry, sem verificação, sem monitoramento

A lacuna é clara: até agora, nenhuma solução de backup compatível com código aberto se integrou ao ADABAS no nível do mecanismo. O plugin da PodHeitor preenche essa lacuna.

2.3 A abordagem da PodHeitor

O plugin segue a mesma filosofia de design da família de plugins PodHeitor: implementação nativa em Rust, desenvolvimento com fases e testes de regressão automatizados, zero dependências de runtime além das ferramentas do banco de dados alvo, e uma arquitetura de protocolo PTCOMM que torna a divisão cdylib/backend trivialmente segura em relação a mudanças na API interna do Bacula. O plugin ADABAS reutiliza o mesmo protocolo PTCOMM, framework cdylib de metaplugin, modelo de isolamento de subprocesso e mecanismo de mesclagem de arquivo de configuração que foram validados nos plugins PodHeitor para PostgreSQL, Firebird e outros.

3. Visão geral da arquitetura

3.1 Design com dois componentes

O plugin é composto por dois binários que são entregues no mesmo pacote:

Componente Arquivo Função
Plugin Bacula FD (cdylib) /opt/bacula/plugins/podheitor-adabas-fd.so Carregado pelo bacula-fd em tempo de execução; implementa a API de plugin do Bacula (cdylib puro em Rust, construído a partir do metaplugin-rs)
Binário backend /opt/bacula/bin/podheitor-adabas-backend Criado (fork) por job pelo cdylib; realiza toda a interação com o ADABAS via chamadas de subprocesso para os utilitários nativos do ADABAS

Essa separação fornece três vantagens principais:

  1. Isolamento. O cdylib é mínimo e estável. Toda a lógica que toca os utilitários do ADABAS (adabck, adaopr, adavfy, adarec) fica no backend. Uma falha ou travamento no backend não pode corromper o processo Bacula FD.
  2. Capacidade de atualização. O binário backend pode ser atualizado sem reiniciar o bacula-fd. Apenas o cdylib toca o ABI do plugin Bacula.
  3. Testabilidade. O binário backend pode ser exercitado diretamente em testes de integração sem envolver o Bacula — essencial para um sistema onde o ADABAS licenciado pode não estar disponível no CI.

3.2 Protocolo PTCOMM

O cdylib e o backend se comunicam pelo stdin/stdout do processo filho usando o PTCOMM (PodHeitor Transport Communications), um protocolo de framing binário com tag de comprimento:

┌────────────────────────────────────────────────────────┐
│  PTCOMM Frame (8-byte header + payload)                │
│                                                        │
│  Offset  Size  Field                                   │
│  ──────  ────  ─────                                   │
│  0       4     Magic  (0x50544300)                     │
│  4       4     Payload length (u32, big-endian)        │
│  8       N     Payload (JSON envelope or binary blob)  │
└────────────────────────────────────────────────────────┘

O handshake de cinco fases do PTCOMM cobre: negociação de capacidades → parâmetros do job → stream de backup/restauração → relatório de status → encerramento limpo. Cada fase tem limite de tempo para evitar que um subprocesso ADABAS fora de controle trave o job do Bacula.

3.3 Diagrama de arquitetura

┌─────────────────────────────┐
│  Bacula Director             │    Job definition: Plugin = "podheitor-adabas: dbid=12"
└──────────────┬──────────────┘
               │
┌──────────────▼──────────────┐
│  Bacula File Daemon (bacula-fd)                                   │
│  Loads /opt/bacula/plugins/podheitor-adabas-fd.so                 │
│  (Rust cdylib — delegates every callback to the backend)          │
└──────────────┬──────────────┘
               │ PTCOMM protocol (length-prefixed packets via stdin/stdout)
               ▼
┌──────────────────────────────────────────┐
│  /opt/bacula/bin/podheitor-adabas-backend │  Rust binary
│    ├── main.rs          PTCOMM 5-phase handshake
│    ├── config.rs        plugin string + config-file merge
│    ├── backup.rs        Level F orchestration
│    ├── incremental.rs   Level I (PLOG archiving) orchestration
│    ├── restore.rs       Phase A→E restore orchestration
│    ├── adabck.rs        DUMP + RESTORE subprocess wrappers
│    ├── adaopr.rs        Operator: status + EXT_BACKUP + RAII guard
│    ├── adavfy.rs        Post-restore consistency verify
│    ├── adarec.rs        PLOG apply (license-gated on CE)
│    ├── plog.rs          PLOG discovery + sequence-wrap detection
│    ├── state.rs         Plugin state file (archived + pending_delete)
│    ├── stream.rs        Fixed 1 MiB buffer child_stdout → PTCOMM
│    ├── subproc.rs       Bounded-wait helper (timeouts)
│    ├── metadata.rs      BackupManifest JSON builder
│    └── types.rs         Contracts: AdabasConfig, NucleusStatus, Manifests
└──────────────┬───────────────────────────┘
               │ child subprocess calls (native ADABAS utilities)
               ▼
┌───────────────────────────────────────────┐
│  ADABAS host (same machine as bacula-fd)  │
│    adabck / adaopr / adavfy / adarec      │
│    DBID=<N> ASSO / DATA / WORK containers │
└───────────────────────────────────────────┘

3.4 Restrição de co-localização

O backend Rust roda no mesmo host Linux que o ADABAS. A comunicação entre processos do ADABAS usa filas de mensagens SysV — que não podem ser tuneladas entre máquinas. O Bacula Storage Daemon pode estar em qualquer lugar; o plugin transmite pacotes PTCOMM pela conexão TCP padrão FD→SD do Bacula. Em implantações em contêineres onde os utilitários do ADABAS ficam dentro de um contêiner Podman/Docker, o script wrapper incluído (scripts/podheitor-adabas-backend.podman-wrapper.sh) re-executa o backend dentro do contêiner usando podman exec -i, fazendo a ponte entre o host e o contêiner de forma transparente.

3.5 Gerenciamento de estado

Jobs incrementais baseados em PLOG exigem estado persistente para rastrear quais arquivos de protection log foram arquivados e quais estão pendentes de exclusão com gate de segurança. Esse estado é armazenado por DBID em:

/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 arquivo de estado é escrito atomicamente via o padrão tmpfile-then-rename, garantindo que não haja corrupção de estado em caso de falha. O esquema possui versionamento para compatibilidade futura.

4. Modos de backup em detalhe

4.1 Backup completo (Level F) — ADABCK DUMP online

Como funciona

O modo de backup completo invoca o adabck com DUMP=* para realizar um backup online completo do nucleus do ADABAS. Antes do dump, o plugin opcionalmente encapsula a operação com um comando adaopr EXT_BACKUP=PREPARE para notificar o nucleus de que uma ferramenta de backup externa está começando, garantindo consistência transacional no ponto de quiesce. Ao concluir, adaopr EXT_BACKUP=CONTINUE libera o ponto de quiesce. O stream de dump é capturado via a variável de ambiente BCK001=- (modo de streaming por stdout) e retransmitido ao Bacula pelo PTCOMM em um loop de buffer fixo de 1 MiB — memória constante independentemente do tamanho do banco de dados.

  adaopr EXT_BACKUP=PREPARE  →  adabck DUMP=* (stdout)  →  buffer 1 MiB  →  PTCOMM  →  Bacula SD

Quando usar

  • Backup completo semanal como ponto de ancoragem para cadeias incrementais
  • Linha de base inicial antes de habilitar o arquivamento incremental de PLOG
  • Qualquer cenário de DR que exija um ponto de restauração completo e autossuficiente
  • Ambientes onde os incrementais baseados em PLOG não estão licenciados (Community Edition)

Propriedades principais

Propriedade Avaliação
Consistência Excelente — ponto de quiesce via EXT_BACKUP=PREPARE garante fronteira transacional
Backup online (hot) Sim — o nucleus permanece online durante todo o processo
Uso de memória O(1) — buffer de streaming fixo de 1 MiB validado em 1,94 MB VmHWM para um dump de 7,27 MB
Tamanho do backup Contêineres ASSO + DATA completos; PLOG não incluído no Level F
Requisito de EXT_BACKUP Sim no ADABAS licenciado (padrão ativo); deve ser desabilitado na Community Edition
Suporte a múltiplos DBIDs Sim — best-effort por DBID; falhas agregadas sem abortar DBIDs restantes
Limite de tempo Sim — padrão de 4 horas; configurável via backup_timeout_secs

4.2 Backup incremental (Level I) — arquivamento de PLOG

Como funciona

O modo de backup incremental arquiva os arquivos de Protection Log (PLOG) do ADABAS desde o último job bem-sucedido. Os PLOGs registram cada transação confirmada e são o mecanismo nativo do ADABAS para recuperação point-in-time. O plugin varre o diretório de PLOG em busca de arquivos com números de sequência mais recentes do que a última sequência arquivada (rastreada no arquivo de estado por DBID), envia cada PLOG como um arquivo virtual separado em /@ADABAS/dbid-<N>/plog-<seq>.adabck, e emite um _plog_manifest.json como Restore Object registrando intervalos de sequência, contadores de geração e timestamps.

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

O gate de segurança garante que os arquivos PLOG nunca sejam excluídos do disco local até que um job subsequente tenha sido executado com sucesso — dando ao operador um ciclo completo de job para abortar antes de perder as cópias locais.

Quando usar

  • Proteção incremental por hora entre backups completos semanais (RPO ≈ 1 hora)
  • Qualquer ambiente que exija capacidade de restauração point-in-time
  • Ambientes onde o tempo de backup completo é muito longo para execução noturna

Propriedades principais

Propriedade Avaliação
ADABAS licenciado necessário Sim — a CE não emite PLOGs (ADR-011, R8)
Tamanho incremental vs. completo Tipicamente < 1% do tamanho do backup completo por intervalo horário
Detecção de sequence-wrap Sim — contador de geração incrementa em PLOG.0001 após last_seen > 0
Exclusão com gate de segurança Sim — PLOGs locais removidos somente após o próximo job bem-sucedido
Retry em falha transitória Sim — backoff exponencial (100ms, 200ms, 400ms), limitado por plog_ship_retries (padrão 2)
Retry de backup completo Nunca — ADR-009: a lógica de retry é apenas para envio de PLOG, não para dumps Level F

4.3 Restauração — completa (adabck RESTORE) + point-in-time (aplicação de PLOG com adarec)

Fluxo de restauração completa (Fase A → E)

O processo de restauração segue uma orquestração de cinco fases:

  1. Fase A — análise do manifesto. O plugin lê o Restore Object _manifest.json do job de backup selecionado para reconstruir a lista de DBIDs e os parâmetros de backup.
  2. Fase B — preparação dos arquivos. O Bacula entrega os arquivos de stream de backup para um diretório de preparação temporário em $TMPDIR.
  3. Fase C — gate do nucleus. O plugin verifica se allow_destructive_restore=yes está configurado (o gate evita sobrescritas acidentais) e verifica o status offline do nucleus.
  4. Fase D — adabck RESTORE. O arquivo de backup preparado é alimentado ao adabck RESTORE=* via um FIFO nomeado. O nucleus é sobrescrito.
  5. Fase E — verificação. O adavfy executa uma verificação de consistência no nucleus restaurado. Se verify_after_restore=yes (padrão), uma verificação com falha encerra o job com erro.

Restauração point-in-time (PITR)

Após a conclusão de uma restauração completa (Fases A–E), os PLOGs são aplicados em sequência usando adarec CHECKPOINT=(first,last). Os nomes de checkpoint são sanitizados para [A-Z0-9_]{0,8} antes de serem passados ao adarec para prevenir injeção de DSL a partir de manifestos hostis. Versões futuras suportarão restore_to_time=&lt;ISO8601&gt; via resolução de timestamp-para-checkpoint com adaplp (roadmap v1.1.0).

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

5. Matriz de funcionalidades

Funcionalidade Level F (Completo) Level I (PLOG Incr) Restauração
Backup online (hot) Sim Sim N/A
Encapsulamento EXT_BACKUP quiet point Sim (padrão ativo) N/A N/A
Integração adabck DUMP Sim Não N/A
Arquivamento de PLOG Não Sim (licenciado) N/A
Integração adabck RESTORE N/A N/A Sim (licenciado)
Aplicação de PLOG com adarec (PITR) N/A N/A Sim (licenciado)
Verificação pós-restauração com adavfy N/A N/A Sim (padrão ativo)
Múltiplos DBIDs por job Sim Sim Sim
Integração com catálogo Bacula Sim Sim Sim
Objeto JSON BackupManifest Sim Sim (PlogManifest) Leitura
Compressão LZ4 (Bacula) Sim Sim N/A
Timeouts configuráveis Sim Sim Sim
Cancelamento seguro por sinal Sim Sim Sim
Detecção de sequence-wrap N/A Sim N/A
Exclusão de PLOG com gate de segurança N/A Sim N/A
Streaming por stdout (BCK001=-) Sim N/A N/A
Modo fallback para arquivo temporário Sim N/A N/A
Suporte a wrapper Podman Sim Sim Sim
Suporte a ADABAS CE 7.x Sim (external_backup=no) Não (PLOGs bloqueados) Parcial
Suporte a ADABAS licenciado 8.x Sim Sim Sim
PITR baseado em checkpoint N/A N/A Sim (licenciado)
CLI de diagnóstico (–probe-nucleus) Sim Sim Sim
Escrita atômica de arquivo de estado N/A Sim N/A

6. Guia de instalação

6.1 Pré-requisitos

  • Bacula Community 15.0.3 ou posterior instalado e bacula-fd em execução
  • ADABAS 7.x (Community) ou 8.x+ (licenciado) instalado no mesmo host que o bacula-fd
  • Utilitários do ADABAS adabck, adaopr, adavfy, adarec disponíveis no $PATH (ou caminhos completos configurados via string de plugin)
  • SO: Linux x86_64 ou aarch64
  • Rust 1.70+ (necessário apenas para compilação a partir do código-fonte)
  • O usuário que executa o bacula-fd deve poder executar os utilitários do ADABAS como o DBA do ADABAS (tipicamente sagadmin) — seja por co-localização sob o mesmo UID ou via regras de sudo configuradas

6.2 Compilando a partir do código-fonte (recomendado)

# 1. Clone ou descompacte o código-fonte do plugin
cd /opt/podheitor-adabas-plugin

# 2. Compile o cdylib Rust + binário backend (sem necessidade do código-fonte do Bacula)
make

# 3. Instale (requer root — escreve em /opt/bacula/{plugins,bin})
sudo make install

# 4. Reinicie o File Daemon para que ele carregue o novo .so
sudo systemctl restart bacula-fd

# 5. Confirme que o plugin foi carregado
echo "status client=$(hostname)-fd" | bconsole | grep -i adabas
# Esperado: Plugin: ... podheitor-adabas(1.0.0-ce) ...

6.3 Teste de fumaça pós-instalação

# Valide que o backend consegue alcançar o nucleus do ADABAS
/opt/bacula/bin/podheitor-adabas-backend --probe-nucleus 12
# Esperado: DBID=12 ONLINE adanuc=&lt;version&gt;

# Se OFFLINE ou UNKNOWN:
#  OFFLINE  = processo ADANUC não está em execução; inicie-o
#  UNKNOWN  = adaopr rejeitou o DBID; verifique se $PATH inclui o diretório bin do ADABAS,
#             ou passe --adaopr-path=/caminho/absoluto/para/adaopr

6.4 Pacotes RPM / DEB

Pacotes RPM e DEB estão planejados para o lançamento de disponibilidade geral v1.0.0. Acompanhe o status de publicação no catálogo de plugins em podheitor.com.

6.5 ADABAS em contêiner (wrapper Podman)

Quando os utilitários do ADABAS não estão instalados nativamente no host do FD, mas rodam dentro de um contêiner Podman:

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

# O wrapper re-executa o backend dentro do contêiner nomeado:
# podman exec -i adabas-ce-test /opt/bacula/bin/podheitor-adabas-backend "$@"

Rollback: um backup com timestamp de qualquer ELF backend nativo anterior é preservado em /usr/local/sbin/podheitor-adabas-backend.elf-bak.&lt;ts&gt;.

7. Referência de configuração

7.1 Parâmetros da string de Plugin

Todos os parâmetros são passados na diretiva Plugin = "podheitor-adabas: &lt;param&gt;=&lt;valor&gt; ...". Os parâmetros são separados por espaço (não por dois-pontos). Tanto snake_case quanto camelCase são aceitos para cada chave.

Parâmetro Tipo Padrão Descrição
dbid uint (obrigatório) ID único do banco de dados ADABAS
dbids lista — Lista separada por vírgulas para jobs com múltiplos bancos: dbids=12,13,14
mode enum online online (suportado) ou cold (adiado)
external_backup bool yes Encapsula DUMP em adaopr EXT_BACKUP=PREPARE/CONTINUE. Deve ser no na Community Edition
plog bool yes Arquiva PLOGs durante jobs Level I. Sem efeito na CE
plog_dir caminho autodetectado Diretório contendo os arquivos PLOG.*
adabck_path caminho adabck Caminho completo alternativo para o utilitário adabck
adaopr_path caminho adaopr Caminho completo alternativo para adaopr
adavfy_path caminho adavfy Caminho completo alternativo para adavfy
adarec_path caminho adarec Caminho completo alternativo para adarec (aplicação de PLOG)
stream_mode enum auto auto (= stdout), stdout, ou fallback tempfile
buffer_size tamanho 8m Buffer de streaming (aceita sufixos K/M/G)
allow_destructive_restore bool no Gate obrigatório para restauração — sem isso, a restauração recusa sobrescrever um banco existente
verify_after_restore bool yes Executa adavfy DBID=&lt;N&gt; após a restauração
restore_to_checkpoint string — Alvo de PITR: nomes de checkpoint "first,last"
restore_to_time timestamp — Timestamp ISO 8601 (v1.1.0: resolução via adaplp)
config_file caminho /opt/bacula/etc/podheitor-adabas.conf Arquivo contendo linhas de parâmetros padrão, mescladas com a string de plugin do job
status_timeout_secs uint 10 Limite de tempo de parede para a sondagem de status do adaopr
backup_timeout_secs uint 14400 Limite de tempo de parede para o subprocesso DUMP (4 horas)
restore_timeout_secs uint 14400 Limite de tempo de parede para o subprocesso RESTORE (4 horas)
adarec_timeout_secs uint 1800 Limite de tempo de parede por chamada adarec por PLOG (30 min)
verify_timeout_secs uint 300 Limite de tempo de parede para adavfy (5 min)
plog_ship_retries uint 2 Máximo de tentativas (backoff exponencial) em falha transitória de envio de PLOG

7.2 Variáveis de ambiente

Variável Efeito
ADABAS_LOG_LEVEL Verbosidade: off, error, warn, info (padrão), debug, trace. Aliases: err, warning, numérico 0–5.
ADABAS_DBID DBID alternativo opcional para --probe-nucleus. O plugin sempre prefere o dbid= do lado DSL.
PODHEITOR_ADAOPR_PATH Substitui o caminho do adaopr usado pelo --probe-nucleus. Útil em ambientes em contêineres.

7.3 Arquivo de configuração — padrões compartilhados

Crie /opt/bacula/etc/podheitor-adabas.conf para compartilhar padrões entre muitos jobs:

# Uma chave=valor por linha; # inicia um comentário
external_backup      = yes
stream_mode          = auto
buffer_size          = 16m
verify_after_restore = yes
status_timeout_secs  = 15
backup_timeout_secs  = 21600

O plugin lê este arquivo primeiro e, em seguida, sobrepõe os parâmetros do Plugin = "..." do job — os valores por job sempre têm precedência.

8. Exemplos de FileSet

8.1 DBID único — backup 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últiplos DBIDs — três bancos de dados em um job

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

Após um job completo, bconsole: list files jobid=&lt;N&gt; exibe:

/@ADABAS/dbid-12/full-&lt;ts&gt;.adabck
/@ADABAS/dbid-12/_manifest.json
/@ADABAS/dbid-13/full-&lt;ts&gt;.adabck
/@ADABAS/dbid-13/_manifest.json
/@ADABAS/dbid-14/full-&lt;ts&gt;.adabck
/@ADABAS/dbid-14/_manifest.json

8.3 Community Edition — external_backup=no obrigatório

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

8.4 Alto volume — fallback para arquivo temporário

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

8.5 Timeouts personalizados para VLDB muito grandes

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

8.6 Restauração interativa

bconsole: restore client=adabas-host-fd
# Selecione os arquivos em /@ADABAS/dbid-12/, depois:
pluginoptions "podheitor-adabas: dbid=12 allow_destructive_restore=yes"

8.7 Restauração point-in-time (somente ADABAS licenciado)

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

9. Dimensionamento e planejamento de capacidade

9.1 Requisitos de memória

Cenário Pico de memória (processo backend)
Backup completo (modo stdout) ~2 MB (buffer de streaming de 1 MiB + overhead do backend) — validado: 1,94 MB VmHWM para dump de 7,27 MB
Backup completo (modo tempfile) ~2 MB backend + espaço em disco temporário igual ao tamanho do dump
Incremental (arquivamento de PLOG) ~2 MB por DBID ativo — PLOGs são pequenos (tipicamente 4 KB–64 KB cada)
Job com múltiplos DBIDs (N DBIDs) Processamento sequencial — pico de memória é o overhead de um único DBID, não N×
Restauração (adabck RESTORE) ~2 MB backend + buffer FIFO; a memória real do RESTORE está no nucleus do ADABAS, não no plugin

Ponto-chave de design. A arquitetura de streaming usa um buffer fixo de 1 MiB — a memória é O(1) independentemente do tamanho do banco de dados. Um dump de 500 GB do ADABAS usa o mesmo pico de 2 MB de memória do backend que um banco de dados de demonstração de 7 MB.

9.2 Requisitos de CPU

Cenário Núcleos recomendados
Backup completo com DBID único 1 (limitado por I/O do throughput do adabck)
Job com múltiplos DBIDs (sequencial) 1–2
PLOG incremental (N PLOGs) 1 (processamento sequencial por PLOG)
Restauração + PITR 1–2

9.3 Espaço em disco — binários do plugin

Arquivo Tamanho
podheitor-adabas-fd.so ~600 KB (perfil release com LTO)
podheitor-adabas-backend ~680 KB (perfil release com LTO)
Total da instalação ~1,3 MB

9.4 Espaço em disco — diretório de estado

Cada DBID rastreado para jobs incrementais de PLOG armazena um arquivo de estado JSON de aproximadamente 2–4 KB. Para 100 bancos de dados, o diretório de estado requer menos de 400 KB — insignificante.

9.5 Estimativas de volume de backup

Modo Tamanho esperado
Backup completo (sem compressão adicional) Aproximadamente igual à soma dos tamanhos dos contêineres ASSO + DATA
Backup completo + LZ4 (compressão de FileSet do Bacula) Tipicamente 60–80% dos tamanhos brutos dos contêineres, dependendo dos padrões de dados
PLOG incremental por intervalo Tipicamente < 1% do tamanho do backup completo por hora; altamente dependente da carga de trabalho

10. Relatório de desempenho

Todas as medições foram realizadas em um ambiente de laboratório controlado usando o contêiner oficial do ADABAS Community Edition 7.4.0 da Software AG (softwareag/adabas-ce:7.4.0, DBID=12, bancos de dados de demonstração EMPLOYEES/VEHICLES/MISCELLANEOUS) rodando em um host Linux com Bacula Community 15.0.3. A CE impõe limites de parâmetros do nucleus (NT=3, NU=5, LWP=1 MB, TCPCONN=4) — estes são benchmarks indicativos; o desempenho em produção com ADABAS licenciado será diferente.

10.1 Backup completo — modo de streaming por stdout

Métrica Resultado
Banco de dados ADABAS CE 7.4.0 DBID=12 (EMPLOYEES/VEHICLES/MISCELLANEOUS)
Tamanho do backup 7.275.028 bytes (7,27 MB)
Modo de stream stdout (BCK001=-)
Pico de memória do backend (VmHWM) 1,94 MB
Proporção memória/dados 0,27 (O(1) — buffer fixo)
BackupManifest emitido Sim — 434 bytes, todos os 12 campos validados
Código de saída do adabck 0
Código de saída do backend 0

10.2 Backup completo — modo fallback para arquivo temporário

Métrica Resultado
Tamanho do backup 7.274.968 bytes
Modo de stream registrado no manifesto tempfile
Status APROVADO — contagem de bytes corresponde ao modo stdout (diferença de 12 bytes de overhead do frame esperada)

10.3 Agregação best-effort com múltiplos DBIDs

Métrica Resultado
DBIDs no job 12 (online), 99 (inexistente)
Resultado do DBID=12 Backup preservado no catálogo
Resultado do DBID=99 Falhou com mensagem clara — DBID=99 UNKNOWN
Erro agregado reportado Sim — log do job: “1 DBID(s) OK ([12]), 1 failed ([99])”
Integridade dos dados do DBID=12 Não corrompida pela falha do DBID=99

10.4 Arquivamento de PLOG incremental (fixtures sintéticos)

Métrica Resultado
Arquivos PLOG de fixture 3 arquivos (seq 4, 5, 6), 4 KB cada
Tamanho do job incremental 3 × 4 KiB + PlogManifest ≈ 0,18% do backup completo de 7 MB
Simulação de sequence-wrap APROVADO — PLOG.0001 após last_seen=6 → generation++ registrado
Idempotência (execução 2) APROVADO — 0 PLOGs candidatos, 3 previamente arquivados
Exclusão com gate de segurança APROVADO — PLOGs anteriores removidos do diretório de fixtures após execução 2

10.5 Orquestração de restauração

Caso de teste Resultado
Restauração sem allow_destructive_restore=yes APROVADO — recusou com mensagem clara
Restauração com manifesto ausente APROVADO — “No backup manifest found for DBID=12”
Orquestração de restauração Fases A→E APROVADO (bloqueado por licença CE na conclusão da Fase D)
Agrupamento de restauração com múltiplos DBIDs APROVADO — 2 manifestos agrupados por segmento vpath

10.6 Suite de testes unitários Rust

Módulo Testes Status
config 13 Aprovado
types 10 Aprovado
ptcomm 5 Aprovado
adaopr 6 Aprovado
adabck 4 Aprovado
adarec 3 Aprovado
adavfy 1 Aprovado
incremental 1 Aprovado
logging 3 Aprovado
plog 13 Aprovado
state 6 Aprovado
restore 3 Aprovado
metadata 2 Aprovado
misc 8 Aprovado
Total 78 / 78 Todos aprovados

11. Matriz de compatibilidade

11.1 Sistema operacional

SO Arquitetura Status
RHEL 9 / Oracle Linux 9 / Rocky 9 x86_64 Suportado
Ubuntu 22.04 LTS x86_64 Suportado
Debian 12 x86_64 Suportado
Linux (qualquer distribuição moderna) aarch64 Compatível para compilação (cargo target); pacotes pendentes
AIX POWER Fora do escopo deste plugin (contrato separado)
z/OS System/390 Fora do escopo (contrato de mainframe)
Windows x86_64 Explicitamente fora do escopo (ADR-007)

11.2 Versões do ADABAS

Versão Plataforma Backup Level F PLOG Level I Restauração
7.4.x CE (softwareag/adabas-ce:7.4.0) Contêiner Linux Sim (external_backup=no) Não (bloqueado por licença) Parcial (somente orquestração)
8.x+ licenciado Linux Sim (external_backup=yes) Sim Sim
z/OS / BS2000 Mainframe Fora do escopo Fora do escopo Fora do escopo

11.3 Versões do Bacula

Versão do Bacula Status
Community 15.0.3 Suportado e validado
Community 15.0.x (futuro) Esperada compatibilidade (metaplugin-rs acompanha o ABI)
Community 14.x e anteriores Não suportado (o framework metaplugin requer 15.0.3+)
Bacula Enterprise Não necessário; o plugin tem como alvo o Bacula Community

11.4 Camada de aplicação Natural / NaturalONE

O plugin protege a camada do mecanismo de banco de dados ADABAS (contêineres ASSO, DATA, WORK e PLOGs). O código-fonte de aplicações Natural e os artefatos de projeto NaturalONE são objetos de sistema de arquivos e devem ser protegidos por jobs padrão de backup em nível de arquivo do Bacula. O backup da camada de aplicação está explicitamente fora do escopo deste plugin.

12. Segurança

12.1 Sem credenciais embutidas

O plugin não lida com senhas do ADABAS — a autenticação do ADABAS é gerenciada pelo nucleus via interface de operador e SysV IPC, não por usuário/senha na configuração do job de backup. Não há credenciais para embutir, armazenar ou redigir na configuração do Bacula.

12.2 Prevenção de injeção de DSL

Os nomes de checkpoint passados para adarec CHECKPOINT=(first,last) são sanitizados para a classe de caracteres [A-Z0-9_]{0,8} antes de serem passados ao subprocesso. Isso previne a injeção de palavras-chave arbitrárias de DSL do ADABAS a partir de um _plog_manifest.json hostil ou corrompido.

12.3 Validação de caminhos

Os parâmetros adabck_path, adaopr_path, adavfy_path e adarec_path são validados para não conter metacaracteres de shell antes de serem passados para Command::new(). Não há sh -c em nenhum lugar do backend — todas as invocações de subprocesso usam Command::args([]) diretamente.

12.4 Gate de restauração destrutiva

A restauração recusa-se incondicionalmente a prosseguir a menos que allow_destructive_restore=yes esteja explicitamente definido nas opções do plugin. Esse gate não pode ser contornado por uma definição de Job mal configurada — deve estar presente como uma decisão explícita do operador no momento da restauração. A mensagem do gate é:

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

12.5 Isolamento de subprocesso

O cdylib cria (fork) um processo backend por job do Bacula. Não existe estado mutável compartilhado entre jobs de backup concorrentes. Se o backend falhar ou for encerrado por um sinal externo, o cdylib reporta uma falha de job e o bacula-fd continua atendendo outros jobs normalmente. Cada subprocesso tem um limite de tempo de parede — um processo adabck ou adarec descontrolado não pode travar permanentemente o Bacula File Daemon.

12.6 Tratamento de arquivos temporários

Os arquivos temporários criados durante backups em modo tempfile e preparação de restauração usam um sufixo de ID de processo para evitar colisões entre jobs concorrentes. O tipo Rust StagedFiles implementa Drop para limpar os diretórios de preparação em todos os caminhos de saída — incluindo panics e cancelamento por SIGTERM. Em SIGTERM/SIGINT, uma flag atômica global é definida e verificada entre leituras de streaming; o plugin encerra de forma limpa sem deixar arquivos órfãos.

12.7 Permissões do arquivo de estado

O diretório de estado /opt/bacula/working/podheitor-adabas-state/ é criado com modo 0750, proprietário bacula. Os arquivos de estado são escritos com tmpfile-then-rename atômico para prevenir corrupção por escrita parcial em caso de falha ou queda de energia.

13. Monitoramento

13.1 Códigos de status do job do Bacula

O plugin define os códigos de status padrão do job do Bacula:

  • T — encerrado normalmente; todos os DBIDs foram protegidos com sucesso
  • E — encerrado com erros; um ou mais DBIDs falharam (detalhes no log do job)
  • f — erro fatal; o backend falhou ao iniciar ou travou antes de qualquer DBID ser tentado

13.2 Mensagens do log do job

Todas as mensagens do plugin são prefixadas com [podheitor-adabas] e roteadas para o log do job do Bacula via pacotes PTCOMM info. Saída padrão de um backup completo bem-sucedido:

[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 Localizações dos arquivos de log

Log Caminho
Log do backend do plugin /opt/bacula/working/podheitor-adabas-backend.log (alternativo: /tmp/podheitor-adabas-backend.log)
Log do job do Bacula Via bconsole: list messages ou pelo Bacularis
Arquivo de estado do plugin /opt/bacula/working/podheitor-adabas-state/dbid-&lt;N&gt;.json

13.4 Log de depuração

Defina ADABAS_LOG_LEVEL=debug (ou trace para log completo de frames PTCOMM) no ambiente do bacula-fd para habilitar saída detalhada:

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

13.5 CLI de sondagem do nucleus

# Verifique a acessibilidade e versão do nucleus a qualquer momento (sem necessidade de job do Bacula)
/opt/bacula/bin/podheitor-adabas-backend --probe-nucleus 12
# Esperado: DBID=12 ONLINE adanuc=&lt;version&gt;

13.6 Integração com Bacularis

Todos os jobs de backup do ADABAS são cidadãos de primeira classe no Bacularis — aparecem na lista de jobs, seus arquivos virtuais (incluindo _manifest.json e entradas de PLOG) são navegáveis, e jobs de restauração podem ser iniciados pela interface web do Bacularis. Nenhuma extensão específica do ADABAS para o Bacularis é necessária.

14. Guia de resolução de problemas

14.1 Erros comuns

Restauração recusada — parâmetro de gate ausente

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

Causa. Gate de segurança funcionando conforme projetado. Solução. Passe allow_destructive_restore=yes na diretiva pluginoptions somente quando você pretende sobrescrever o banco de dados alvo.

Manifesto de backup não encontrado

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

Causa. A seleção de arquivos do job de restauração não inclui o _manifest.json. Solução. Re-selecione o namespace virtual completo /@ADABAS/dbid-12/* durante a seleção de restauração.

ADABCK abortado — deadlock CE + EXT_BACKUP

Subprocess 'adabck DBID=12 DUMP=*' exit=&lt;C&gt;: %ADABCK-I-ABORTED

Causa. Na CE, EXT_BACKUP=PREPARE antes de adabck DUMP=* faz o adabck bloquear em do_msgrcv aguardando IPC do nucleus — uma restrição conhecida da CE. Solução. Defina external_backup=no na string de plugin para jobs CE. O ADABAS licenciado em produção deve manter o padrão external_backup=yes.

Timeout de subprocesso

child did not exit within &lt;N&gt;s — killed

Causa. Um subprocesso (adabck, adavfy, adarec) excedeu seu limite de tempo de parede configurado. Solução. Diagnostique se a operação subjacente realmente requer mais tempo; se sim, aumente o parâmetro *_timeout_secs relevante.

Job cancelado no meio do stream

cancelled by signal (SIGTERM/SIGINT) mid-stream

Causa. Comportamento esperado — o operador cancelou o job do Bacula, ou o bacula-fd enviou SIGTERM. Solução. Nenhuma ação necessária; os arquivos temporários são limpos automaticamente pelo guard Drop de StagedFiles.

probe-nucleus retorna UNKNOWN

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

Causa. O adaopr saiu com código diferente de zero — DBID errado, utilitários do ADABAS não estão no PATH, ou nucleus não está em execução. Solução. Verifique se $PATH inclui o diretório bin do ADABAS; confirme que o DBID existe via adainfo.sh &lt;DBID&gt;; ou especifique --adaopr-path=/caminho/absoluto.

Job incremental reporta 0 PLOGs candidatos

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

Causa (a). Nenhum PLOG rotacionou desde o último job — normal em um ambiente de baixa atividade. Causa (b). CE está em uso — PLOGs não são emitidos pelo nucleus da Community Edition. Solução. Em ambos os casos, isso é esperado; nenhuma ação necessária.

14.2 Referência de comandos de diagnóstico

# O nucleus está acessível?
/opt/bacula/bin/podheitor-adabas-backend --probe-nucleus 12

# Log detalhado em uma execução única para um job de backup
ADABAS_LOG_LEVEL=debug bconsole: run job=ADABAS-DBID-12-Full yes

# Inspecione o arquivo de estado do plugin (somente leitura; nunca edite manualmente)
cat /opt/bacula/working/podheitor-adabas-state/dbid-12.json

# Verifique se o plugin está carregado no FD
echo "status client=$(hostname)-fd" | bconsole | grep -i adabas

15. Casos de uso e cenários de implantação

15.1 Banco de dados de assinantes de telecomunicações

Cenário. Uma operadora nacional de telecomunicações executa o gerenciamento de assinantes e armazenamento de CDR (Call Data Record) no ADABAS 8.x licenciado, com duas instâncias DBID, com DATA+ASSO combinados totalizando 400 GB. O requisito regulatório é de retenção de dados por 7 anos com RTO de 4 horas e RPO de 1 hora.

Solução.

  • Backup completo (Level F) semanal, aos domingos às 02:00, com external_backup=yes (padrão)
  • Backup incremental (Level I) por hora — arquivamento de PLOG a cada hora, de segunda a sábado
  • Pool do Bacula com retenção de volumes por 7 anos
  • Cópia externa para fita ou nuvem via job de migração padrão do Bacula

Resultado. RPO ≈ 1 hora, RTO definido pelo tempo de restauração do ADABAS (< 4 horas para 400 GB via LAN Gigabit para armazenamento local). Conformidade total com os requisitos de retenção regulatória sem qualquer alteração nas aplicações existentes do ADABAS ou Natural.

15.2 Livro-razão de core banking

Cenário. Um banco regional executa seu livro-razão de processamento de transações em ADABAS no IBM AIX… migrando para Linux. A nova instância ADABAS 8.x no Linux deve atender aos requisitos de rastreabilidade de dados do BCBS 239 — cada transação deve ser recuperável até um checkpoint nomeado.

Solução.

  • Backup completo noturno com external_backup=yes e verify_after_restore=yes
  • Arquivamento de PLOG incremental a cada 15 minutos
  • Restauração point-in-time testada trimestralmente usando restore_to_checkpoint=SYNC,&lt;checkpoint&gt;
  • JSON BackupManifest armazenado no catálogo do Bacula — fornece a trilha de evidências auditável

15.3 Registro de pessoal governamental

Cenário. Um órgão nacional de previdência social executa o ADABAS no Linux para seu registro de pessoal com 40 milhões de registros. Restrições orçamentárias proíbem o licenciamento de plataformas comerciais de backup. O Bacula Community já está em uso para backups em nível de arquivo em todo o órgão.

Solução.

  • Implante o plugin da PodHeitor na infraestrutura existente do Bacula Community — custo de plataforma zero
  • Backup completo semanal; PLOG incremental por hora
  • Estenda os pools e agendamentos existentes do Bacula para cobrir os jobs do ADABAS
  • Sem novo software de backup, sem novos licenciamentos, sem retreinamento para a equipe Bacula existente

15.4 Motor de reserva de apólices de seguros

Cenário. Uma seguradora executa o ADABAS como seu motor de reserva de apólices com execuções de lote noturnas calculando reservas para 5 milhões de apólices. A execução de lote modifica milhões de registros; o requisito de RTO é de 2 horas (tempo para re-executar o lote se o ADABAS for corrompido).

Solução.

  • Backup completo imediatamente após o lote (aprox. 03:00) com um backup_timeout_secs=21600 personalizado para bancos de dados grandes
  • Arquivamento de PLOG a cada 30 minutos durante a execução do lote para habilitar recuperação granular
  • Verificação de consistência adavfy após cada restauração (padrão ativo) fornece prova auditável de integridade na recuperação

15.5 Desenvolvimento/CI — contêiner ADABAS CE

Cenário. Uma equipe de software desenvolvendo aplicações Natural/ADABAS precisa proteger seu ambiente de desenvolvimento CE e testar o plugin de backup no CI antes de implantar em produção.

Solução.

  • Execute o contêiner oficial do ADABAS CE: podman run -d --name adabas-ce-test softwareag/adabas-ce:7.4.0
  • Use external_backup=no plog=no no FileSet (restrições da CE)
  • Implante o wrapper Podman para fazer a ponte entre o FD do host e os utilitários no contêiner
  • O backup completo valida todo o pipeline plugin → PTCOMM → adabck no CI sem custo algum
Plugin = "podheitor-adabas: dbid=12 external_backup=no plog=no stream_mode=auto"

16. Comparação com outras abordagens

16.1 Comparação de funcionalidades

A tabela abaixo compara o plugin ADABAS da PodHeitor rodando no Bacula Community com formas alternativas de proteger dados do ADABAS. O Bacula Enterprise é incluído como referência: oferece backup corporativo de uso geral excelente e continua sendo uma escolha sólida quando recursos mais amplos do BEE são necessários; este plugin é construído especificamente para fornecer funcionalidades específicas do ADABAS (cadeias incrementais de PLOG, PITR baseado em checkpoint, integração de quiet-point online, armazenamento nativo de manifesto no catálogo) sobre a base do Bacula Community.

Funcionalidade Bacula Community + PodHeitor Bacula Enterprise Veeam Commvault NetBackup
ADABAS nativo (integração adabck) Sim Não Não Não Não
Backup online (hot) com quiet point Sim Não Não Não Não
Arquivamento de PLOG incremental Sim Não Não Não Não
Restauração point-in-time (checkpoint) Sim (ADABAS licenciado) Não Não Não Não
Verificação pós-restauração com adavfy Sim Não Não Não Não
Múltiplos DBIDs por job Sim Não Não Não Não
Integração com catálogo Bacula Sim Sim N/A N/A N/A
Objeto JSON BackupManifest Sim Não Não Não Não
Compressão (LZ4 / zstd via Bacula) Sim Sim Sim Sim Sim
Criptografia Sim (nativa Bacula) Sim Sim Sim Sim
Limitação de largura de banda Sim (nativa Bacula) Sim Sim Sim Sim
Gerenciamento de retenção Sim (pools Bacula) Sim Sim Sim Sim
Compatível com Bacula Community Sim N/A N/A N/A N/A
Base de plataforma de código aberto Sim (Bacula CE) Não Não Não Não
ADABAS CE 7.x testado Sim Não Não Não Não
Wrapper Podman para ADABAS em contêiner Sim Não Não Não Não
Cancelamento seguro por sinal + limpeza de arquivos temporários Sim N/A N/A N/A N/A
78 testes unitários Rust automatizados Sim N/A N/A N/A N/A

16.2 Comparação de custos

Oferta especial. Traga sua proposta de renovação da Veeam, Commvault, NetBackup ou qualquer outra plataforma de backup corporativo. Produziremos uma proposta por escrito de confronto direto com foco em pelo menos 50% de economia, com funcionalidades específicas para ADABAS superiores às que qualquer plataforma comercial oferece atualmente. Entre em contato: heitor@opentechs.lat.

Solução Custo anual típico Suporte nativo a ADABAS
Bacula Community + plugin PodHeitor Significativamente menor Nativo completo (este plugin)
Bacula Enterprise Frequentemente > US$ 10.000/ano Nenhum (nível de arquivo ou via script)
Veeam Data Platform Frequentemente > US$ 5.000/ano Nenhum (somente nível de VM)
Commvault Frequentemente > US$ 15.000/ano Nenhum (somente via script)
NetBackup Frequentemente > US$ 20.000/ano Nenhum (somente via script)

Os preços variam de acordo com o tamanho do ambiente e os contratos negociados. Entre em contato com heitor@opentechs.lat para uma comparação específica com sua proposta de renovação atual.

17. Roadmap

O plugin está na versão v1.0.0-ce — validado ponta a ponta na CE para backups completos; as funcionalidades bloqueadas por licença (aplicação de PLOG, restauração com nucleus offline) estão completas em código e aguardam validação em instância licenciada.

  • v1.0.0 (disponibilidade geral). Mesmo código que a 1.0.0-ce, após passar pela parte bloqueada por licença da matriz de aceitação em um ADABAS de produção. Alvo: primeira instalação de ADABAS licenciado de um cliente.
  • v1.1.0 (planejado).
    • Integração com adaplp para resolver timestamps restore_to_time=&lt;ISO8601&gt; em nomes de checkpoint automaticamente — habilitando PITR baseado em tempo sem consulta manual de nomes de checkpoint
    • Fallback transparente stream_mode=auto — atualmente Auto é sinônimo de Stdout; tornando Auto tentar stdout e então fazer fallback silencioso para tempfile em determinados códigos de erro
    • Modo de backup cold (ADR-006 aceito, adiado) — para backups em janela de manutenção agendada
  • v1.2.0 (futuro).
    • Empacotamento RPM / DEB e publicação no catálogo de plugins em podheitor.com
    • Pacotes binários para ARM64 / aarch64
    • Portabilidade para Windows (ADR-007 — reavaliar se um cliente necessitar de ADABAS no Windows)
    • Painel de configuração de plugin do Bacularis para parâmetros de job do ADABAS
    • Endpoint de métricas estendidas (Prometheus) para contadores de jobs de backup do ADABAS

Nenhuma data de lançamento específica está comprometida. A direção das funcionalidades é guiada pelo feedback dos clientes e pelos resultados do laboratório com instâncias licenciadas.

18. Conclusão

O Plugin de Backup ADABAS da PodHeitor estende o Bacula Community com a primeira integração de backup nativa para ADABAS de qualidade para produção disponível na plataforma Bacula de código aberto. Ele oferece backup hot online via adabck DUMP com encapsulamento de quiet point transacional, arquivamento incremental por hora baseado em PLOG para RPO ≈ 1 hora, restauração point-in-time baseada em checkpoint via adarec, e verificação de consistência pós-restauração via adavfy — tudo gerenciado por meio de uma única diretiva de Plugin FileSet do Bacula.

O plugin foi validado por 78 testes unitários Rust e testes ponta a ponta na CE, com eficiência de memória em streaming demonstrada em pico de 1,94 MB para uma instância ADABAS em execução (streaming de memória constante O(1)). A arquitetura — cdylib Rust + backend Rust + protocolo PTCOMM + isolamento de subprocesso — é o mesmo padrão battle-tested usado em todos os plugins maduros da PodHeitor.

Para organizações que executam ADABAS no Linux — em telecomunicações, bancos, seguros ou governo — o plugin da PodHeitor preenche uma lacuna que nenhuma outra ferramenta de backup de código aberto ou comercial aborda atualmente. Não requer alterações na instalação existente do ADABAS, nenhuma modificação nas aplicações Natural e nenhuma substituição de uma infraestrutura Bacula existente. Para organizações avaliando renovações de plataformas comerciais de backup, a combinação do Bacula Community com o plugin da PodHeitor oferece capacidade de DR específica para ADABAS superior a uma fração do custo.

Para começar:

  • Baixe o plugin: https://podheitor.com
  • Solicite uma cotação ou demonstração: heitor@opentechs.lat
  • Telefone / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

19. Informações de contato

Autor Heitor Faria
Empresa PodHeitor International
Website https://podheitor.com
E-mail heitor@opentechs.lat
Telefone / WhatsApp +1 786 726-1749
Telefone / WhatsApp (BR) +55 61 98268-4220
Página do produto https://podheitor.com/adabas-plugin
Suporte heitor@opentechs.lat

20. Legal / direitos autorais

© 2026 Heitor Faria — todos os direitos reservados.

O Plugin de Backup ADABAS da PodHeitor para Bacula é um software proprietário. A cópia, distribuição, modificação ou engenharia reversa não autorizada é estritamente proibida. Uma licença comercial é necessária para uso em produção.

Bacula® é uma marca registrada de Kern Sibbald e da comunidade Bacula. ADABAS® e Software AG® são marcas registradas da Software AG. Natural® e NaturalONE® são marcas registradas da Software AG. Veeam® é uma marca registrada da Veeam Software. Commvault® é uma marca registrada da Commvault Systems, Inc. NetBackup® é uma marca registrada da Veritas Technologies LLC. Todas as outras marcas são propriedade de seus respectivos detentores.

Este documento é fornecido apenas para fins informativos. As figuras de desempenho são de medições em laboratório controlado usando ADABAS Community Edition 7.4.0 e podem variar significativamente em ambientes de produção dependendo de hardware, versão do ADABAS, configuração de parâmetros do nucleus, tamanho do banco de dados e características da carga de trabalho. As funcionalidades bloqueadas por licença estão completas em código e foram testadas por unidade, mas não foram validadas ponta a ponta em uma instância licenciada do ADABAS; o desempenho e a compatibilidade em instalações licenciadas 8.x+ podem diferir das medições da CE.

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

Plugin de Backup ADABAS da PodHeitor para Bacula — v1.0.0-ce — © 2026 Heitor Faria — todos os direitos reservados — https://podheitor.com

Disponível em: pt-brPortuguêsenEnglish (Inglês)esEspañol (Espanhol)

Deixe um comentário