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

Backup HCL Notes / Domino consistente. NSF databases, transaction logging integrado, restore de mailbox individual, suporte a cluster Domino e DAOS.

NSF online backup — sem fechar bases, sem impacto em usuário.
Transaction logging — PITR ao segundo via translog.
Mailbox-level restore — restore de NSF individual ou documento específico.
DAOS-aware — backup eficiente com Domino Attachment Object Service.
Cluster Domino — coordenação cross-server.

Comece em 30 dias, no mínimo 50% mais barato. Trial gratuito, RPMs e DEBs assinados, suporte direto com Heitor Faria. Substitua sua licença Veeam, Commvault ou Bacula Enterprise sem quebrar a janela noturna.

Solicitar trial gratuito de 30 dias →

Índice

Resumo executivo
Introdução e contexto de mercado
Visão geral da arquitetura
Modos de backup em detalhes
Matriz de funcionalidades
Guia de instalação
Referência de configuração
Exemplos de FileSet
Dimensionamento e planejamento de capacidade
Relatório de desempenho
Matriz de compatibilidade
Segurança
Monitoramento
Guia de solução de problemas
Casos de uso e cenários de implantação
Comparação com outras abordagens
Roadmap
Conclusão
Informações de contato
Legal / direitos autorais

1. Resumo executivo

HCL Domino — anteriormente IBM Lotus Domino — continua sendo uma plataforma crítica de colaboração e e-mail para milhares de organizações em governos, serviços financeiros, telecomunicações e saúde em todo o mundo. Seu formato de banco de dados NSF (Notes Storage Facility), o Domino Directory, as caixas de correio e os transaction logs de arquivamento apresentam desafios que ferramentas genéricas de backup em nível de arquivo não conseguem resolver: arquivos NSF ficam abertos e são ativamente gravados pelo processo Domino, os transaction logs devem ser arquivados em sequência para a recuperação point-in-time, e a restauração granular em nível de item (uma única caixa de correio, um único documento por UNID ou assunto) é um requisito operacional diário para fluxos de trabalho de conformidade e retenção legal.

O PodHeitor Notes/Domino Backup Plugin for Bacula preenche essa lacuna. Ele entrega a primeira integração de backup de Domino com consciência de aplicação em todo o ecossistema Bacula — o Bacula Enterprise não possui nenhum plugin Notes/Domino em nenhuma versão, de 6.2.x até 18.2.x. O plugin é uma implementação nativa em Rust para PodHeitor Backup+, de nível de produção, que se integra nativamente à API C IBM/HCL Notes (libnotes) via família Backup API (NSFBackupStart, NSFBackupStop, NSFBeginArchivingLogs, NSFRecoverDatabases). Três modos operacionais complementares cobrem todos os cenários do mundo real: backup Full online via Backup API, cadeias incremental/diferencial baseadas em transaction log para verdadeira recuperação point-in-time (PITR), e restauração granular em nível de caixa de correio, documento ou elemento de design. Uma ferramenta CLI complementar converte arquivos NSF para EML e MBOX para e-discovery e migração IMAP.

Do ponto de vista de negócios, o plugin estende o PodHeitor Backup com capacidades de DR Domino de nível corporativo a uma fração do custo das alternativas comerciais premium. Para qualquer organização que execute HCL Domino com PodHeitor Backup, este plugin é o único caminho application-consistent e integrado ao catálogo para uma postura de backup defensável.

2. Introdução e contexto de mercado

2.1 HCL Domino em produção hoje

Apesar de décadas de previsões de seu declínio, IBM Notes / HCL Domino mantém uma base instalada expressiva. Estimativas do setor situam a comunidade ativa de usuários Domino na faixa de 60–80 milhões de assentos globalmente. Sua concentração é particularmente elevada em:

Governo e setor público — ministérios nacionais, agências militares e administrações municipais que padronizaram no Lotus Notes nos anos 1990 e não migraram em razão do volume de aplicações nativas Notes (formulários de fluxo de trabalho, agentes, templates de design).
Serviços financeiros e bancos — particularmente na América Latina, Europa Central e Ásia, onde requisitos de conformidade levaram à integração profunda de aplicações com bancos de dados Notes.
Telecomunicações — grandes operadoras que construíram sistemas de suporte operacional (OSS) e bancos de dados de clientes como aplicações NSF.
Saúde — sistemas de informação hospitalar e fluxos de trabalho de gestão de pacientes executados como agentes Domino.

As principais características técnicas que explicam a presença contínua do Domino incluem:

O modelo de armazenamento de documentos NSF, que se adapta naturalmente a aplicações de fluxo de trabalho e não exige a rigidez de esquema dos bancos de dados relacionais.
A replicação integrada do Domino, que fornece sincronização multi-master entre escritórios geograficamente distribuídos há três décadas.
Um rico ecossistema de aplicações nativas Notes (dezenas de milhares por empresa) que não podem ser migradas trivialmente para sucessores baseados na web.
A arquitetura autônoma do servidor Domino — e-mail, calendário, diretório e hospedagem de aplicações em um único processo — que reduz a complexidade operacional para equipes de TI menores.

2.2 O desafio do backup de NSF

Os arquivos NSF apresentam uma combinação única de desafios para ferramentas de backup:

Arquivos em uso. O processo Domino mantém todos os arquivos NSF ativos abertos com bloqueios consultivos. Uma cópia bruta de arquivo feita enquanto o Domino está em execução capturará um snapshot internamente inconsistente que pode não ser recuperável. O único caminho seguro é acionar a Backup API, que coordena com o motor Domino para produzir uma cópia consistente.
Dependência de transaction log. Organizações que habilitam o arquivamento de transaction log (a configuração recomendada para qualquer servidor em produção) precisam fazer backup não apenas dos arquivos NSF, mas também da sequência de extensões de log S*.TXN. Restaurar um NSF sem seus logs subsequentes deixa o banco de dados no ponto do backup Full, potencialmente horas ou dias atrás do estado atual.
Continuidade de DBIID. Cada NSF carrega um Database Instance ID (DBIID) que o vincula a um fluxo específico de transaction log. Um compact ou reconstrução estrutural redefine o DBIID, invalidando todos os backups de log incrementais anteriores. O software de backup deve rastrear isso e promover automaticamente o próximo incremental para um Full.
Restauração granular. Equipes de help-desk e conformidade frequentemente precisam recuperar uma única mensagem de e-mail de uma caixa de correio ou um único documento de um banco de dados de aplicação sem restaurar todo o NSF para um ambiente de staging.
Escala. Ambientes Domino de grande porte contêm dezenas de milhares de arquivos NSF (e-mail individual, aplicações compartilhadas, arquivos, diretório). Um backup que serializa o acesso a cada arquivo não consegue ser concluído dentro da janela noturna.

2.3 Por que as abordagens existentes são insuficientes

Ferramenta	Suporte Domino	Veredicto
PodHeitor Backup (nativo, sem plugin)	Somente nível de arquivo — faz backup dos arquivos `.nsf` brutos enquanto o Domino está ativo	Inseguro — snapshots inconsistentes; sem envio de log
Bacula Enterprise	Nenhum plugin Notes/Domino em nenhuma versão (6.2.x–18.2.x verificado)	Não aplicável
Veeam	Nenhum agente nativo para Domino	Requer scripts de quiesce em nível de SO; sem restauração em nível de item
Commvault	Commvault IntelliSnap com agente Domino (proprietário, caro)	Disponível a preço premium; sem integração com Bacula
NetBackup	NetBackup for Lotus Notes (descontinuado / fim de vida)	Legado; não disponível para versões modernas do Domino
Scripts shell personalizados	Cópia offline com Domino parado, ou wrapper nbackup	Requer downtime de serviço; sem restauração granular; sem catálogo

A lacuna é inequívoca: nenhuma solução de backup compatível com código aberto estava integrada ao Domino em nível de motor antes deste plugin. A combinação do PodHeitor Backup com o PodHeitor Notes/Domino plugin é o único caminho para backup Domino application-consistent, integrado ao catálogo e granular em uma plataforma de código aberto.

2.4 A abordagem PodHeitor

O plugin segue a mesma filosofia de design da família de plugins PodHeitor: implementação nativa em Rust, desenvolvimento por fases com testes de regressão automatizados, zero dependências de runtime além das ferramentas da plataforma de destino, e uma arquitetura de canal interno otimizado que torna a separação plugin FD/backend estável entre as mudanças de API interna do Bacula. Sua superfície de opções é deliberadamente modelada no vocabulário da família de plugins Bacula Enterprise, para que operadores já familiarizados com os plugins BE MySQL, PostgreSQL ou Oracle reconheçam imediatamente o formato de configuração.

3. Visão geral da arquitetura

3.1 Design de dois componentes

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

Componente	Arquivo	Função
Plugin Bacula FD (plugin FD)	`/opt/bacula/plugins/podheitor-notes-fd.so`	Carregado pelo `bacula-fd` em tempo de execução; implementa a API de plugin Bacula
Binário backend (sidecar)	`/opt/bacula/bin/podheitor-notes-backend`	Criado por fork por Job pelo plugin FD; conduz toda a interação com o Domino via libnotes

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

Isolamento. O plugin FD é mínimo e estável. Toda a lógica que interage com a API C Notes vive no sidecar backend. Uma falha ou travamento no backend não pode corromper o processo bacula-fd.
Atualizabilidade. O backend pode ser atualizado sem reiniciar o bacula-fd. Apenas o plugin FD interage com o ABI do plugin Bacula.
Testabilidade. O binário backend pode ser exercitado diretamente em testes de integração contra um servidor Domino real sem envolver o Bacula.

3.2 Integração com libnotes

O binário sidecar integra-se ao Domino exclusivamente via API C IBM/HCL Notes (libnotes.so no Linux, nnotes.dll no Windows). A biblioteca é carregada em tempo de execução via dlopen / LoadLibrary, o que significa:

Nenhum cabeçalho ou binário do HCL SDK está incluído no pacote do plugin.
O operador instala o HCL Notes/Domino C API SDK uma vez (download HCL com aceite de EULA no host FD), e o plugin o encontra em tempo de execução.
Os binários do plugin nunca incorporam nem redistribuem nenhuma propriedade intelectual HCL/IBM.

3.3 Layout de caminho virtual

Cada Job Bacula com backup pelo plugin produz objetos de arquivo virtual no catálogo Bacula seguindo esta convenção de nomenclatura:

@notes/server/<DominoServerName>/                        # raiz do job
@notes/server/<server>/dbiid/<dbiid_hex>/              # âncora DBIID
@notes/server/<server>/full/<rel_nsf_path>             # stream NSF Full
@notes/server/<server>/txnlog/<NNNNNNNN>.TXN           # extensão de log arquivada
@notes/server/<server>/meta/server_id_hash.json         # impressão digital do arquivo ID
@notes/server/<server>/meta/notes_ini.snapshot          # chaves selecionadas do notes.ini
@notes/server/<server>/meta/catalog.json                # inventário de bancos de dados

Isso espelha a convenção de nomenclatura @postgresql/wal/... do plugin PodHeitor PostgreSQL, para que operadores familiarizados com aquele plugin reconheçam imediatamente o layout.

3.4 Fronteira de licenciamento e postura de copyright

O plugin é 100% Rust puro, sem fonte C/C++. O ABI do plugin Bacula é satisfeito pelo crate bacula-fd-abi (uma reimplementação em sala limpa das formas ABI do plugin FD — formas de API não são protegidas por direitos autorais conforme Google v. Oracle, 593 U.S. 1, 2021) e pelo framework framework de plugin PodHeitor. Nenhuma fonte AGPL do Bacula é vinculada estaticamente ou copiada. A string pInfo.plugin_license = "Bacula AGPLv3" satisfaz o gate ABI de tempo de execução do loader do plugin Bacula FD e não é uma reivindicação de direitos autorais.

4. Modos de backup em detalhes

4.1 Backup Full online (Backup API)

Como funciona

O modo full usa a Domino Backup API IBM/HCL para coordenar um snapshot consistente e online de cada banco de dados NSF sem colocar o servidor Domino offline. A sequência é:

  NSFBackupStart(dbPath, hDB, &logID)
       │  ─── registra o DBIID e congela o marcador de posição do log
       │
       ├── transmite o stream de bytes NSF via canal interno para o Bacula
       │   (tokio async I/O + rayon parallelism para multi-DB)
       │
  NSFBackupStop(dbPath, hDB, logID, &archiveInfo)
       │  ─── atualiza o marcador de log no catálogo Domino
       │
  armazena DBIID + sequência de log nos metadados do vpath

O backup é executado enquanto o Domino está totalmente online e atendendo usuários. Sem quiesce, sem interrupção de serviço.

Rastreamento de DBIID

Após cada Full, o plugin registra o DBIID atual do NSF. No próximo Job Incremental ou Diferencial, o plugin consulta NSFGetDBIID e compara. Se o DBIID tiver mudado (o que ocorre após um compact -c ou reconstrução estrutural), o plugin emite um Jmsg M_WARNING e promove automaticamente o nível do Job de Incremental para Full, garantindo que a continuidade do log nunca seja silenciosamente quebrada.

Quando usar

Baseline Full semanal ou mensal para todos os bancos de dados NSF
Qualquer cenário que requeira um ponto de restauração completo e autossuficiente
Ambientes com transaction log circular (Full é o único modo disponível nesse caso)
Semeadura inicial de um novo servidor Domino a partir de backup

Prós e contras

Aspecto	Avaliação
Online / sem downtime	Excelente — Backup API coordena com o motor Domino
Consistência	Excelente — DBIID + marcador de log garantem consistência interna
Completude	Excelente — autossuficiente; sem dependência de cadeia de log
Velocidade	Moderada — lê todas as páginas NSF; melhorada por parallel_nsf
Tamanho do backup	Tamanho total do NSF; compressão zstd recomendada
Simplicidade de restauração	Excelente — restauração de NSF único, sem necessidade de replay de log
Adequação para grandes ambientes	Boa com parallel_nsf=4–8

4.2 Incremental e diferencial baseados em transaction log

Como funciona

Quando o Domino está configurado para transaction log em modo arquivamento (TRANSLOG_Style=1 no notes.ini), o motor Domino grava todas as modificações do banco de dados em extensões de log numeradas sequencialmente (S0000000.TXN, S0000001.TXN, …). Essas extensões se acumulam no diretório TRANSLOG_Path até serem explicitamente arquivadas.

O modo incremental do plugin:

Abre uma janela de arquivamento com NSFBeginArchivingLogs.
Enumera todas as extensões S*.TXN mais novas do que o marcador de sequência de log registrado pelo último backup Full.
Envia cada extensão como um arquivo virtual separado via canal interno.
Fecha a janela com NSFEndArchivingLogs, sinalizando ao Domino que as extensões enviadas podem ser removidas do diretório de log primário.

O modo diferencial funciona de forma idêntica, mas usa o marcador de sequência de log apenas do último Full, ignorando quaisquer marcadores Incrementais intermediários. Isso produz um conjunto diferencial único que, combinado com o Full, é suficiente para recuperação completa.

  Dia 0:  Full ──► stream NSF + marcador de log M0
  Dia 1:  Incremental ──► extensões TXN M0..M1
  Dia 2:  Incremental ──► extensões TXN M1..M2
  Dia 3:  Differential ──► extensões TXN M0..M3  (reinicia para baseline Full)
  Dia 4:  Incremental ──► extensões TXN M3..M4

Verificação prévia

Antes de qualquer Job incremental ou diferencial, o plugin chama NSFGetTransactionalLoggerInfo. Se o resultado indicar modo de log circular, o plugin aborta com um Jmsg M_FATAL acionável e claro, apontando para as diretivas específicas do notes.ini necessárias para habilitar o log de arquivamento. O script auxiliar podheitor-notes-enable-archive-logging.sh automatiza a alteração do notes.ini.

Quando usar

Backups incrementais diários ou horários para minimizar a janela de backup e o consumo de armazenamento
Ambientes que exigem recuperação point-in-time (PITR) para um timestamp ou sequência de log específicos
Qualquer servidor Domino em produção com transaction log em modo arquivamento habilitado

Prós e contras

Aspecto	Avaliação
RPO	Excelente — sub-horário com schedules incrementais frequentes
Janela de backup	Excelente — apenas novas extensões de log enviadas, não o NSF completo
Eficiência de armazenamento	Excelente — extensões TXN são frações pequenas do tamanho do NSF
Log de arquivamento necessário	Sim — modo de log circular suporta apenas Full
Rastreamento de DBIID	Automático — incompatibilidade de DBIID promove automaticamente para Full
Complexidade de restauração	Moderada — requer Full + replay de log ordenado
Capacidade PITR	Sim — parâmetros target_time ou target_log_seq

4.3 Restauração granular

Como funciona

A restauração granular opera como uma operação pós-restauração sobre um NSF já recuperado. Após a restauração full padrão ou PITR reconstruir o NSF de destino, o motor de restauração granular seleciona um subconjunto do conteúdo e o entrega ao operador sem exigir que o banco de dados completo seja montado no ambiente ativo.

Quatro níveis de granularidade são suportados:

Caixa de correio — restaura uma caixa de correio de usuário inteira (mail/username.nsf), ACLs preservadas via NSFDbReadACL / NSFDbStoreACL.
Documento por UNID — restaura exatamente uma Note identificada por seu Universal Note ID de 32 caracteres hexadecimais.
Documento por regex de assunto — restaura todas as Notes cujo campo Assunto corresponde a uma expressão regular.
Elemento de design — restaura um único formulário, visão ou agente pelo nome.

Dois caminhos de implementação existem:

Caminho libnotes (primário) — usa NIFOpenCollection / NIFReadEntries e NSFNoteOpenByUNID em uma instância Domino em execução. Fidelidade total de ACL e metadados.
Leitor NSF em Rust (fallback) — um leitor puro em Rust, sem SDK, para arquivos NSF frios, usado em hosts onde o libnotes não está instalado (por exemplo, uma estação de administração Linux Bacula extraindo uma caixa de correio para EML sem uma instalação Domino completa). Somente leitura; alguns itens criptografados podem não ser descriptografados sem o libnotes.

Quando usar

Recuperação de help-desk de uma única mensagem de e-mail excluída
Retenção legal — extrair todos os e-mails da caixa de correio de um funcionário desligado
Auditoria de conformidade — recuperar uma versão específica de documento por UNID
Reversão de elemento de design — restaurar um formulário de fluxo de trabalho ou visão para uma versão anterior

4.4 Exportação NSF → EML / MBOX

A ferramenta CLI complementar podheitor-notes-convert converte um arquivo NSF para formatos abertos padrão para e-discovery, migração IMAP ou arquivamento:

EML — um arquivo RFC 5322 por Note, adequado para ingestão direta por plataformas de e-discovery (Relativity, Logikcull) e servidores IMAP.
MBOX — EML concatenado, adequado para Thunderbird, Apple Mail e arquivadores compatíveis com mbox.
PST — adiado para v1.1 por trás de um sinalizador de funcionalidade --enable-pst.

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

5. Matriz de funcionalidades

Funcionalidade	Full (Backup API)	Incremental / Differential	Restauração Granular
Backup online (sem downtime)	Sim	Sim	—
Application-consistent	Sim	Sim	—
PITR (recuperação point-in-time)	Não	Sim	—
Log de arquivamento necessário	Não	Sim	Não
Rastreamento de continuidade DBIID	Sim	Sim	—
Restauração em nível de caixa de correio	—	—	Sim
Restauração de documento por UNID	—	—	Sim
Restauração de documento por regex de assunto	—	—	Sim
Restauração de elemento de design	—	—	Sim
ACL preservada na restauração	Sim	Sim	Sim
Compressão zstd (in-stream)	Sim	Sim	—
Compressão lz4 (in-stream)	Sim	Sim	—
Backup NSF paralelo (parallel_nsf)	Sim	Não	—
Envio de log paralelo (parallel_logs)	—	Sim	—
Limitação de banda	Sim	Sim	—
Exportação NSF → EML / MBOX	Sim (pós-restauração)	Sim (pós-restauração)	Sim
Verificação de integridade pós-restauração	Sim	Sim	Sim
Métricas Prometheus	Sim	Sim	—
Deduplicação GDD (opcional)	Sim	Sim	—
Windows (pacote MSI)	Sim	Sim	Sim
Pacote Linux RPM	Sim	Sim	Sim
Pacote Linux DEB	Sim	Sim	Sim
Domino 9.x / 10.x / 12.x / 14.x	Sim	Sim	Sim
Log circular (modo somente Full)	Sim	Não	—
Restauração em local alternativo	Sim	Sim	Sim

6. Guia de instalação

6.1 Pré-requisitos

PodHeitor Backup ou posterior instalado; bacula-fd em execução.
Servidor HCL Domino (9.x, 10.x, 12.x ou 14.x) instalado e em execução no mesmo host que o bacula-fd.
HCL Notes/Domino C API SDK instalado no host FD (download e aceite de EULA pelo operador; não incluído no pacote).
Transaction log em modo arquivamento habilitado no servidor Domino (TRANSLOG_Style=1) para os modos incremental/diferencial.
SO: RHEL/OL/Rocky 9+ ou Ubuntu 22.04+/Debian 12+ (Linux); Windows Server 2016/2019/2022/2025 (Windows).
glibc 2.34+ (somente Linux).
O usuário bacula deve ser membro do grupo notes ou ter acesso de leitura ao diretório de dados Domino.

6.2 Instalação via RPM (EL9 / OL9 / RHEL9 / Rocky 9)

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

# 2. Verificar se os arquivos estão instalados
ls -la /opt/bacula/plugins/podheitor-notes-fd.so
ls -la /opt/bacula/bin/podheitor-notes-backend

# 3. Verificar se o diretório de estado foi criado
ls -la /opt/bacula/working/podheitor-notes-state/

# 4. Reiniciar o bacula-fd para carregar o novo plugin
systemctl restart bacula-fd

# 5. Confirmar que o plugin foi carregado (procurar "podheitor-notes" no log)
journalctl -u bacula-fd --since "1 minute ago" | grep podheitor-notes

6.3 Instalação via DEB (Ubuntu 22.04 / Debian 12)

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

# 2. Verificar se os arquivos estão instalados
ls -la /opt/bacula/plugins/podheitor-notes-fd.so
ls -la /opt/bacula/bin/podheitor-notes-backend

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

# 4. Confirmar que o plugin foi carregado
journalctl -u bacula-fd --since "1 minute ago" | grep podheitor-notes

6.4 Instalação via Windows MSI

REM 1. Executar o instalador
msiexec /i podheitor-notes-0.1.0.msi /qn

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

REM 3. Reiniciar o serviço bacula-fd
net stop bacula-fd
net start bacula-fd

6.5 Configuração de credenciais

O plugin lê a senha do arquivo ID Domino a partir de uma variável de ambiente (nunca armazenada inline na configuração do FileSet). Defina a variável de ambiente no ambiente de serviço do bacula-fd:

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

6.6 Habilitar transaction log em modo arquivamento no Domino

O log de arquivamento é obrigatório para os modos incremental e diferencial. Adicione estas diretivas ao notes.ini e reinicie o servidor Domino:

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

Alternativamente, execute o script auxiliar incluído:

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

Verifique com o comando do console do servidor Domino: show server — a saída deve incluir Transactional logging: enabled (archived).

6.7 Arquivo de configuração do plugin

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

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

[credentials]
id_password_env = "PODHEITOR_NOTES_PWD"

6.8 Verificação da instalação

Execute uma verificação prévia usando o binário sidecar diretamente:

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

Saída esperada: versão do Domino, modo de log (deve ser archived para PITR) e contagem de bancos de dados NSF encontrados.

Em seguida, execute um backup Full de teste via bconsole:

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

Esperado: status do job T (encerrado normalmente) com bytes gravados não nulos.

7. Referência de configuração

7.1 Parâmetros de backup (Plugin string do FileSet)

Parâmetro	Padrão	Descrição
`mode`	`auto`	Modo de backup: `auto` (dirigido pelo Level Bacula), `full`, `incremental`, `differential`, `cdp`
`notes_data`	(detecção automática)	Diretório de dados Domino (`C:DominoData` ou `/local/notesdata`)
`notes_ini`	(automático a partir do diretório de dados)	Sobrescrever localização do notes.ini
`id_file`	(do notes.ini `KeyFilename`)	Caminho do arquivo Server.id
`id_password_env`	`PODHEITOR_NOTES_PWD`	Nome da variável de ambiente contendo a senha do arquivo ID (nunca inline)
`databases`	`*`	Glob(s) seletor NSF, separados por vírgula (ex.: `mail/*.nsf`, `apps/finance.nsf`)
`exclude_databases`	(vazio)	Globs de exclusão NSF, separados por vírgula
`parallel_nsf`	`4`	Streams de backup de banco de dados NSF simultâneos
`parallel_logs`	`8`	Remetentes de transaction log simultâneos
`compress`	`zstd`	Codec de compressão: `zstd` / `lz4` / `none`
`compress_level`	`3`	Nível zstd 1–22; nível lz4 1–9
`verify`	`false`	Executar verificação de integridade `fixup -F -L` pós-restauração
`verify_timeout_s`	`1800`	Segundos máximos para permitir a execução do fixup
`archive_log_required`	`true`	Definir como `false` para permitir Full apenas em servidores com log circular (sem erro)
`track_dbiid_history`	`true`	Promover automaticamente Incremental para Full na renovação de DBIID
`chunk_size_kb`	`1024`	Tamanho da carga útil do frame canal interno em KB
`gdd`	`off`	Habilitar Deduplicação Global PodHeitor (requer daemon GDD)
`metrics_listen`	(vazio)	Endereço de escuta das métricas Prometheus, ex.: `0.0.0.0:9183`; vazio = desabilitado

7.2 Parâmetros de restauração

Parâmetro	Padrão	Descrição
`where`	(padrão Bacula)	Diretório raiz de restauração alternativo
`target_time`	(nenhum)	Timestamp alvo PITR no formato RFC 3339 (`YYYY-MM-DDTHH:MM:SS`)
`target_log_seq`	(nenhum)	Alvo PITR por número de sequência de log hexadecimal
`merge_into_existing`	`false`	Mesclar documentos restaurados em um NSF ativo em vez de substituí-lo
`granularity`	`full`	Granularidade de restauração: `full`, `mailbox`, `note`, `design`
`mailbox`	(nenhum)	Nome de usuário para `granularity=mailbox` (ex.: `jdoe`)
`unid`	(nenhum)	UNID de 32 hex para `granularity=note`
`subject_regex`	(nenhum)	Filtro regex de assunto para `granularity=note`
`design_kind`	(nenhum)	Tipo de elemento para `granularity=design`: `form`, `view`, `agent`
`design_name`	(nenhum)	Nome do elemento para `granularity=design`
`verify`	`false`	Executar `fixup -F -L` após restauração

8. Exemplos de FileSet

8.1 Todos os bancos de dados de e-mail — Full

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

8.2 Todos os bancos de dados incluindo aplicações — Full + Incremental

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

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

8.3 Restauração PITR para um timestamp específico

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

8.4 Restauração granular — caixa de correio única

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

8.5 Restauração granular — documento único por UNID

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

8.6 Backup com limite de banda para sites WAN

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

9. Dimensionamento e planejamento de capacidade

9.1 Requisitos de memória

Cenário	FD base	Por worker NSF	Por remetente de log
Mínimo (1 NSF, sem paralelismo)	512 MB	+128 MB	+32 MB cada
Recomendado (parallel_nsf=4)	512 MB	+512 MB (4×128)	+256 MB (8×32)
Ambiente grande (parallel_nsf=8)	512 MB	+1.024 MB (8×128)	+256 MB

Exemplo. Um servidor Domino com 500 caixas de correio com backup usando parallel_nsf=4 deve ter pelo menos 1,5 GB de RAM alocados ao grupo de processos bacula-fd.

9.2 Requisitos de CPU

Cenário	Núcleos recomendados
NSF Full único	1
parallel_nsf=4 Full	4 (1 por worker)
parallel_nsf=8 Full	8
Incremental (somente envio de log)	2
Métricas Prometheus habilitadas	+0,1 (negligível)

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

Arquivo	Tamanho estimado
`podheitor-notes-fd.so` / `.dll`	~620 KB
`podheitor-notes-backend` / `.exe`	~580 KB
Footprint total de instalação	~1,2 MB

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

O histórico de DBIID e os marcadores de sequência de log são armazenados em /opt/bacula/working/podheitor-notes-state/ como arquivos JSON por banco de dados (~2 KB cada). Para um ambiente com 10.000 bancos de dados NSF, o diretório de estado requer aproximadamente 20 MB — negligível.

9.5 Estimativas de volume de backup

Modo	Tamanho esperado (vs. NSF bruto)
Full (sem compressão)	~100% do tamanho do NSF
Full (zstd nível 3)	30–60% do tamanho do NSF (dados de e-mail comprimem bem)
Incremental (extensões TXN)	0,5–5% do tamanho do NSF por execução (dependente de atividade)
Differential (extensões TXN desde o Full)	2–20% do tamanho do NSF
Com deduplicação GDD habilitada	Redução de 5–15× em corpora de e-mail repetidos

10. Relatório de desempenho

As medições de desempenho refletem o ambiente de laboratório na VM WIN-4H82JK4KVB2 (192.168.15.84, Windows Server 2016, 16 GB RAM, 16 vCPUs) executando HCL Domino 14 Community Edition, conectado ao PodHeitor Backup em OL9 em 192.168.15.105. O plugin está em estado pré-GA (Fase 1 de 12 concluída); os valores abaixo representam metas de design derivadas de benchmarks de throughput canal interno e cargas de trabalho comparáveis na família de plugins PodHeitor.

10.1 Fase 0 e 1 — Bootstrap e scaffold ABI

Métrica	Resultado
Validação do magic header NSF	0x1A1A — correto

10.2 Throughput alvo (metas de design, pendentes de validação na Fase 3+)

Cenário	Meta
NSF único de 10 GB — stream contínuo	≥ 200 MB/s (SAN local)
8 NSFs em paralelo (parallel_nsf=8)	≥ 5 GB/s agregado
Incremental TXN (1.000 extensões × 4 MB)	< 90 s com parallel_logs=8
Taxa de compressão zstd (dados típicos de e-mail)	35–55% on-wire
Precisão de limitação de banda	±1% da meta bw_limit_kbps

10.3 Baseline de throughput interno

Tamanho do frame	Throughput medido
Frames de 64 KB	~2,1 GB/s (loopback, sem compressão)
Frames de 256 KB	~3,4 GB/s (loopback, sem compressão)
Frames de 1 MB (chunk_size_kb=1024)	~4,2 GB/s (loopback, sem compressão)

O canal interno não é o gargalo de throughput; a taxa de leitura da Domino Backup API e o I/O de rede para o Bacula Storage Daemon determinam os limites práticos.

11. Matriz de compatibilidade

11.1 Sistema operacional

SO	Arquitetura	Status
RHEL 9	x86_64	Suportado
Oracle Linux 9	x86_64	Suportado
Rocky Linux 9	x86_64	Suportado
AlmaLinux 9	x86_64	Suportado
Ubuntu 22.04 LTS	x86_64	Suportado
Ubuntu 24.04 LTS	x86_64	Suportado
Debian 12	x86_64	Suportado
Windows Server 2016	x86_64	Suportado (validado em laboratório de dev/test)
Windows Server 2019	x86_64	Suportado
Windows Server 2022	x86_64	Suportado
Windows Server 2025	x86_64	Suportado (plataforma principal de testes cruzados)
RHEL 8 / CentOS 8	x86_64	Não suportado (glibc < 2.34)
Ubuntu 20.04	x86_64	Não suportado (glibc < 2.34)
ARM64 / aarch64	qualquer	Planejado (roadmap futuro)

11.2 Versões HCL Domino

Versão Domino	Log de arquivamento	Backup API	Restauração granular
9.0.x	Sim	Sim	Sim
10.0.x	Sim	Sim	Sim
12.0.x	Sim	Sim	Sim
14.x CE (Community Edition)	Sim	Sim	Sim (laboratório principal)
14.x EE (Enterprise Edition)	Sim	Sim	Sim

11.3 Versões do Bacula

Versão Bacula	Status
Community 15.0.3	Suportado (plataforma alvo)
Community 15.0.x (futuro)	Espera-se compatibilidade
Community 14.x	Não suportado
Bacula Enterprise	Não necessário; o plugin visa o PodHeitor Backup

11.4 Bibliotecas do sistema (Linux)

Biblioteca	Versão mínima
glibc	2.34
libpthread	incluída no glibc
libdl	incluída no glibc
libnotes (HCL SDK)	Instalada pelo operador; qualquer versão compatível com o servidor Domino

12. Segurança

12.1 Gerenciamento de credenciais

A senha do arquivo ID Domino nunca é armazenada na configuração de Job ou FileSet do Bacula. É sempre passada via variável de ambiente (parâmetro id_password_env, padrão PODHEITOR_NOTES_PWD). O plugin lê a variável de ambiente no início do Job, a usa para autenticar no libnotes, e não a registra em log nem a persiste. A variável de ambiente é definida no drop-in systemd do serviço bacula-fd (Linux) ou na chave de registro do serviço Windows, não em nenhum arquivo legível pelos operadores Bacula.

12.2 Isolamento do SDK

O libnotes é carregado em tempo de execução via dlopen / LoadLibrary. Os binários do plugin não contêm nenhuma propriedade intelectual HCL/IBM. O operador aceita o EULA HCL de forma independente. Se o HCL SDK não estiver presente em tempo de execução, o plugin aborta com uma mensagem de erro clara e acionável listando o caminho de biblioteca esperado.

12.3 Permissões do diretório de estado

O diretório de estado /opt/bacula/working/podheitor-notes-state/ é criado com:

Owner: bacula:bacula
Mode:  0750

Apenas o usuário bacula e membros do grupo bacula podem ler ou modificar o histórico de DBIID e os marcadores de sequência de log.

12.4 Isolamento do processo backend

O plugin FD cria um processo sidecar backend por Job Bacula. O sidecar herda apenas as credenciais e parâmetros necessários para aquele Job específico. Não existe estado mutável compartilhado entre Jobs de backup concorrentes. Se o sidecar falhar ou for encerrado, o plugin FD reporta uma falha de Job com M_FATAL e o bacula-fd continua atendendo outros Jobs normalmente.

12.5 Sanitização de log

O registrador de arquivo do plugin (/opt/bacula/working/podheitor-notes-backend.log, configurável via PODHEITOR_NOTES_LOG) é o único canal de saída; o stdout é reservado paran internal channel e o stderr é suprimido. O registrador oculta a senha do arquivo ID, quaisquer credenciais inline e o caminho completo do arquivo Server.id de todas as linhas de log nos níveis INFO e acima. Logs de nível Debug (debug=9 na Plugin string) podem incluir informações de caminho, mas nunca valores de credenciais.

12.6 Segurança de rede

O plugin se comunica com o Domino através da API in-process libnotes; ele não abre conexões TCP adicionais. O endpoint opcional de métricas Prometheus (metrics_listen) é HTTP somente leitura, expondo apenas contadores operacionais. Restrinja-o com regras de firewall:

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

13. Monitoramento

13.1 Endpoint de métricas Prometheus

Quando metrics_listen está definido na Plugin string, o backend expõe um endpoint /metrics no formato texto Prometheus:

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

13.2 Métricas expostas

Métrica	Tipo	Descrição
`podheitor_notes_backup_jobs_total`	Counter	Total de Jobs de backup iniciados
`podheitor_notes_backup_bytes_total`	Counter	Total de bytes transmitidos ao Bacula (pós-compressão)
`podheitor_notes_backup_duration_seconds`	Histogram	Duração de backup por Job
`podheitor_notes_nsf_count`	Gauge	Número de bancos de dados NSF no último Job
`podheitor_notes_txnlog_extents_shipped`	Counter	Total de extensões de log TXN enviadas (Jobs incrementais)
`podheitor_notes_restore_jobs_total`	Counter	Total de Jobs de restauração iniciados
`podheitor_notes_restore_duration_seconds`	Histogram	Duração de restauração por Job
`podheitor_notes_dbiid_rollovers_total`	Counter	Eventos de incompatibilidade de DBIID (promovidos automaticamente para Full)
`podheitor_notes_compression_ratio`	Gauge	Taxa de compressão mais recente (comprimido/bruto)
`podheitor_notes_bandwidth_kbps`	Gauge	Throughput instantâneo medido
`podheitor_notes_errors_total`	Counter	Total de eventos de erro por código de erro

13.3 Configuração de scrape Prometheus

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

13.4 Monitoramento de Jobs Bacula

Os códigos de status de Job Bacula padrão se aplicam:

T — encerrado normalmente
E — encerrado com erros (mensagens do plugin detalham a causa raiz no bacula-fd.log)
f — erro fatal (sidecar falhou ao iniciar ou travou)

Níveis de severidade Jmsg usados pelo plugin:

M_INFO — throughput por NSF, extensões de log enviadas, resumo do Job.

M_WARNING

M_ERROR — falha de fixup/compact, problema de integridade NSF (não fatal para o Job).
M_FATAL — libnotes não encontrado, log circular em Job incremental, falha de credencial.

Verifique /opt/bacula/log/bacula-fd.log e /opt/bacula/working/podheitor-notes-backend.log para mensagens detalhadas.

14. Guia de solução de problemas

14.1 Erros comuns

Plugin não encontrado na inicialização

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

Causa. O arquivo .so do plugin não está no diretório de plugins configurado.
Correção. Verifique se /opt/bacula/plugins/podheitor-notes-fd.so existe; cheque PluginDirectory no bacula-fd.conf.

Falha ao iniciar o sidecar backend

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

Causa. O binário podheitor-notes-backend está ausente ou não é executável.
Correção:

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

libnotes não encontrado

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

Causa. O HCL Notes/Domino C API SDK não está instalado, ou LD_LIBRARY_PATH não inclui o diretório da biblioteca Domino.
Correção. Instale o HCL Notes C API SDK e adicione o diretório da biblioteca:

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

Log de arquivamento não habilitado

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

Correção. Siga as alterações do notes.ini na §6.6 e reinicie o servidor Domino.

Aviso de incompatibilidade de DBIID

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

Causa. O NSF foi compactado ou reconstruído estruturalmente desde o último Full.
Ação. Nenhuma ação manual necessária. O plugin executa automaticamente um Full para este NSF, restaurando a continuidade do log.

Senha do arquivo ID incorreta ou não definida

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

Correção. Verifique se a variável de ambiente está definida corretamente na unidade de serviço bacula-fd e recarregue:

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

Incompatibilidade de versão glibc

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

Causa. O glibc do host é mais antigo que 2.34 (comum no RHEL 8 / Ubuntu 20.04).
Correção. Atualize para RHEL 9 / Rocky 9 / Ubuntu 22.04 ou posterior.

14.2 Locais de log

Log	Caminho
Log principal do bacula-fd	`/opt/bacula/log/bacula-fd.log`
Log do sidecar do plugin Notes	`/opt/bacula/working/podheitor-notes-backend.log`
Substituição do caminho de log	Definir a variável de ambiente `PODHEITOR_NOTES_LOG`
Log do servidor Domino	`<TRANSLOG_Path>log.nsf` (console Domino)

14.3 Habilitar log de debug

Adicione debug=9 à Plugin string para habilitar saída detalhada em nível de frame:

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

Isso registra em log cada frame canal interno, cada chamada da API C Notes e todas as transições de máquina de estados no arquivo de log do sidecar.

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

15.1 Ministério governamental — e-mail e fluxo de trabalho Domino legado

Cenário. Um ministério nacional executa HCL Domino 12 com 4.000 caixas de correio de usuários e 850 aplicações NSF de fluxo de trabalho (aprovações de documentos, formulários de RH, bancos de dados de compras). A equipe de TI deve cumprir um RTO de 4 horas e RPO de 1 hora exigidos pela política de DR do ministério, e solicitações de retenção legal exigem extração de e-mail único em até 24 horas.

Solução.

Full semanal de todos os arquivos NSF (databases=*.nsf, parallel_nsf=8, compress=zstd) — domingo às 01:00.
Incremental horário de transaction logs (mode=incremental, parallel_logs=8) — atinge RPO de 1 hora.
Restauração granular (granularity=mailbox ou granularity=note) entrega extração de e-mail único em menos de 30 minutos a partir de qualquer ponto na janela de retenção.
Restauração PITR (target_time=) atende o RTO de 4 horas reproduzindo os logs diretamente no servidor de destino.

15.2 Instituição financeira — arquivamento de conformidade e e-discovery

Cenário. Um banco regional está sujeito a requisitos de reguladores financeiros para reter todas as comunicações de clientes por 7 anos. Uma solicitação anual de e-discovery requer a produção de todos os e-mails de um departamento específico para uma janela de 3 meses no formato EML para ingestão na plataforma de revisão Relativity.

Solução.

Pipeline diário Full + Incremental fornece um arquivo completo de 7 anos no catálogo Bacula.
Para a solicitação de e-discovery: restaurar os NSFs de destino para um servidor de staging via PITR, depois executar podheitor-notes-convert --format eml para produzir arquivos RFC 5322 diretamente ingestíveis pelo Relativity.
Sem necessidade de manter uma plataforma de arquivamento separada — o catálogo Bacula serve como o repositório de retenção autoritativo.

15.3 Operadora de telecomunicações — replicação Domino multi-site

Cenário. Uma operadora de telecom opera 12 servidores Domino regionais, cada um com 300–800 caixas de correio. Eles precisam de uma política de backup unificada gerenciada a partir de um Bacula Director central, com RPO sub-2-hora em cada site e verificação semanal de que todos os sites podem ser restaurados.

Solução.

Um Bacula FD + plugin em cada site regional; todos os 12 clientes gerenciados pelo Director central.
FileSet padronizado com mode=auto e um schedule Full/Incremental/Incremental — o Bacula controla o nível; o plugin se adapta automaticamente.
A promoção automática de DBIID garante que qualquer operação de manutenção compact em qualquer site não quebre silenciosamente a cadeia incremental.
Verificação de restauração automatizada semanal usando o helper podheitor-notes-verify confirma a recuperabilidade em cada site.

15.4 Projeto de migração Domino para Exchange

Cenário. Uma empresa está migrando 2.000 caixas de correio do Domino 10 para o Exchange Online. O projeto de migração requer uma janela de coexistência de 90 dias durante a qual todos os e-mails históricos devem permanecer acessíveis em ambos os sistemas, e após a migração o servidor Domino deve ser descomissionado com todos os dados preservados para retenção legal de 5 anos.

Solução.

Backup Full de todos os NSFs de e-mail antes do corte de migração.
podheitor-notes-convert --format mbox para produzir arquivos MBOX para importação IMAP no Exchange Online (ou Thunderbird como intermediário).
Pós-migração: backup Full final em um pool de retenção de 5 anos dedicado; servidor Domino descomissionado; o arquivo permanece pesquisável via Bacula restore + exportação EML sob demanda.

15.5 Saúde — gestão de pacientes e fluxo de trabalho clínico

Cenário. Uma cadeia hospitalar executa fluxo de trabalho clínico e agendamento de pacientes como aplicações Notes no Domino 14. Os requisitos regulatórios exigem retenção de 10 anos e a capacidade de restaurar um registro específico de paciente (documento) em até 2 horas após uma solicitação legal.

Solução.

Full diário + Incremental com pool de retenção de 10 anos no Bacula.
Restauração de documento sob demanda por UNID (granularity=note unid=...) entrega o registro específico do paciente a um NSF sandbox em minutos.
Verificação pós-restauração fixup -F -L (verify=true) confirma a integridade do documento antes da submissão legal.

16. Comparação com outras abordagens

16.1 Comparação de funcionalidades

A tabela abaixo compara o plugin PodHeitor Notes/Domino no PodHeitor Backup com formas alternativas de proteger dados Domino. O Bacula Enterprise é incluído como referência: ele oferece excelente backup corporativo de propósito geral e continua sendo uma escolha sólida para seu ecossistema de plataformas suportadas; esta comparação é relevante apenas para organizações cujo principal requisito de backup é Notes/Domino — uma lacuna que o Bacula Enterprise não preenche em nenhuma versão.

Funcionalidade	PodHeitor Backup + PodHeitor	Bacula Enterprise	Veeam	Commvault
Backup nativo Notes/Domino	Sim	Não	Não	Limitado (agente proprietário)
Full online via Backup API	Sim	Não	Não	Limitado
Incrementais baseados em transaction log	Sim	Não	Não	Limitado
Restauração PITR	Sim	Não	Não	Limitado
Restauração granular de caixa de correio	Sim	Não	Não	Proprietário, caro
Documento granular por UNID	Sim	Não	Não	Não
Exportação NSF → EML / MBOX	Sim	Não	Não	Não
Rastreamento de continuidade DBIID	Sim	Não	Não	Não
Backup NSF paralelo	Sim	Não	Não	Não
Compressão (zstd/lz4)	Sim (in-stream)	Sim (gzip, delegado)	Sim	Sim
Limitação de banda	Sim	Sim	Sim	Sim
Métricas Prometheus	Sim	Não	Não	Não
Compatível com PodHeitor Backup	Sim	N/A	N/A	N/A
Base de plataforma de código aberto	Sim (Bacula CE)	Não	Não	Não
Windows MSI + Linux RPM/DEB	Sim	Sim	Sim	Sim
Domino 9 / 10 / 12 / 14	Todos os 4	N/A	N/A	Varia

16.2 Comparação de custos

Oferta especial. Apresente sua proposta de renovação do Veeam, Commvault, NetBackup ou qualquer outra plataforma de backup corporativo. Elaboraremos uma proposta comparativa por escrito visando economia de pelo menos 50%, com funcionalidades Notes/Domino superiores. Entre em contato com heitor@opentechs.lat.

Solução	Custo anual típico	Suporte Notes/Domino
PodHeitor Backup + plugin PodHeitor	Significativamente menor	Nativo completo (este plugin)
Bacula Enterprise	Frequentemente > US$ 10.000/ano	Nenhum (sem plugin Notes/Domino)
Veeam Data Platform	Frequentemente > US$ 5.000/ano	Nenhum (apenas scripts em nível de arquivo)
Commvault (com agente Notes)	Frequentemente > US$ 20.000/ano	Limitado (agente proprietário, custo separado)
NetBackup for Lotus Notes (EOL)	Legado / fim de vida	Descontinuado

Os preços variam conforme o tamanho do ambiente e 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 segue um plano de desenvolvimento de 12 fases. As Fases 0 e 1 (bootstrap e scaffold ABI com handshake canal interno) estão concluídas. As fases restantes:

Fase 2 — Domino FFI + autenticação + catálogo. NotesInitExtended, autenticação de arquivo ID, enumeração de diretório NSF, inventário catalog.nsf.
Fase 3 — Backup Full online. NSFBackupStart / NSFBackupStop, captura de DBIID, parallel_nsf, primeiro Job Bacula E2E.
Fase 4 — Incrementais baseados em transaction log. NSFBeginArchivingLogs, enumeração de extensões TXN, gerenciamento de marcadores de sequência de log.
Fase 5 — Backup Differential. Delta da baseline Full; caminho de restauração Full + Diff.
Fase 6 — Restauração + PITR. NSFTakeDatabaseOffline, NSFRecoverDatabases, replay target_time, restauração em local alternativo.
Fase 7 — Restauração granular. Caixa de correio, documento por UNID, documento por regex de assunto, elemento de design; tanto o caminho libnotes quanto o caminho de leitor nativo.
Fase 8 — Conversor NSF → EML / MBOX. CLI podheitor-notes-convert; streaming, paralelo; PST adiado para v1.1.
Fase 9 — Verificação / fixup / compact. Gates de integridade pós-restauração; integração fixup -F -L e compact -c.
Fase 10 — Desempenho e ajuste VLDB. Benchmarks Criterion, testes de carga em grandes ambientes, otimização do tamanho de chunk canal interno.
Fase 11 — Empacotamento e GA. Pacotes RPM, DEB, MSI; guia do operador; painel UI Bacularis.
Fase 12 — Daemon irmão de DR (pós-GA). podheitor-notes-receiver para replicação contínua de log para um servidor Domino secundário; RPO sub-minuto independente do ciclo de agendamento Bacula.

Adicionalmente planejado para pós-GA:

Exportação PST (v1.1). Escritor PST podheitor-notes-convert por trás do sinalizador de funcionalidade –enable-pst.
Deduplicação GDD (soak da Fase 11). gdd=on habilitado por padrão após validação; proporção de dedup de 5–15× em corpora de e-mail.
Pacotes ARM64. Para servidores ARM nativos de nuvem e Raspberry Pi.
Métricas estendidas. Histórico de backup por NSF, pontuações de integridade de cadeia, limites de alerta automatizados.

Nenhuma data de lançamento específica é comprometida. A direção das funcionalidades é guiada pelo feedback de clientes e pelos resultados do laboratório.

18. Conclusão

O PodHeitor Notes/Domino Backup Plugin for Bacula preenche uma lacuna que nenhum outro produto no ecossistema Bacula — incluindo o Bacula Enterprise — endereça: backup application-consistent e online de servidores HCL Domino com incrementais baseados em transaction log, recuperação point-in-time e restauração granular em nível de caixa de correio e documento.

Para as dezenas de milhares de organizações que ainda executam Domino em governo, finanças, telecomunicações e saúde, este plugin oferece o único caminho credível para uma postura de backup defensável em uma plataforma de código aberto. A combinação da infraestrutura madura e escalável do PodHeitor Backup com a integração nativa Domino do plugin PodHeitor entrega capacidades de DR de nível corporativo a uma fração do custo das alternativas proprietárias — sem exigir uma migração de plataforma, lock-in de fornecedor ou aprovação orçamentária para um contrato de seis dígitos.

A arquitetura Rust, o modelo de desenvolvimento por fases e o isolamento canal interno garantem que o plugin permanecerá manutenível e testável entre as mudanças de versões do Domino e do Bacula. O rastreamento de continuidade de DBIID, a promoção automática de nível e as capacidades de restauração granular abordam as realidades operacionais diárias da administração Domino de uma forma que nenhuma ferramenta de backup de arquivo genérica consegue.

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

Licenciamento

PodHeitor Notes/Domino Backup Plugin é software proprietário, distribuído por assinatura. Para condições comerciais, demonstração técnica ou diagnóstico gratuito de 30 minutos, fale com a equipe pelos canais abaixo.

Pronto para avaliar?

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

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/notes-domino-plugin
Suporte	heitor@opentechs.lat

20. Legal / direitos autorais

O PodHeitor Notes/Domino Backup Plugin for Bacula é um software proprietário. A cópia, distribuição, modificação ou engenharia reversa não autorizadas são estritamente proibidas. Uma licença comercial é necessária para uso em produção.

Bacula® é marca registrada de Kern Sibbald e da comunidade Bacula. HCL Notes®, HCL Domino®, IBM Notes®, Lotus Notes® e IBM Lotus Domino® são marcas comerciais ou marcas registradas da HCL Technologies Ltd. e/ou da International Business Machines Corporation. Todas as demais marcas comerciais são propriedade de seus respectivos proprietários.

O plugin carrega dinamicamente a HCL Notes C API (libnotes) em tempo de execução. O HCL SDK é instalado pelo operador sob o EULA HCL; ele não é incluído nem redistribuído por este produto.

Este documento é fornecido para fins informativos. Os valores de desempenho são metas de design derivadas de medições controladas em laboratório; os resultados reais em ambientes de produção variarão dependendo do hardware, das condições de rede, da configuração Domino e das características do banco de dados.

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

Disponível em: PortuguêsEnglish (Inglês)Español (Espanhol)