Blog

Whitepaper técnico — PodHeitor SFTP para Bacula

Whitepaper técnico — PodHeitor SFTP para Bacula

Whitepaper Técnico — Versão 2.0.0 — Maio 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. Elaboramos uma proposta comparativa com meta de pelo menos 50% de economia e funcionalidade SSH/SFTP superior. Contato: heitor@opentechs.lat.

Índice

  1. Sumário executivo
  2. Introdução e contexto de mercado
  3. Visão geral da arquitetura
  4. Modos de backup em profundidade
  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. Considerações 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. Sumário executivo

A infraestrutura de TI moderna é heterogênea. Uma empresa típica opera servidores Linux ao lado de switches Cisco, firewalls Juniper, appliances NAS Synology, gateways IoT Raspberry Pi, máquinas legadas AIX ou Solaris e dezenas de VMs em nuvem distribuídas entre AWS, GCP e Azure. Fazer backup de todos esses ativos com uma única plataforma historicamente exigiu instalar um agente de backup em cada dispositivo — impossível para equipamentos de rede e muitos sistemas embarcados — ou implantar uma sequência de cron jobs, scripts rsync e mecanismos de transferência ad-hoc que não oferecem catálogo, política de retenção nem caminho confiável de restauração.

O PodHeitor SFTP Backup Plugin for Bacula resolve essa fragmentação. Ele estende o Bacula Community Edition com capacidades nativas de backup e restauração via SSH/SFTP, permitindo que qualquer dispositivo acessível por SSH — servidor, NAS, switch, roteador, firewall, gateway IoT ou serviço em nuvem — seja incorporado ao mesmo ambiente Bacula que já cobre o restante da infraestrutura. Nenhuma instalação de software é necessária no lado remoto. A porta 22 é o único requisito.

O plugin é construído inteiramente em Rust, seguindo a arquitetura oficial de Metaplugin do Bacula — o mesmo framework utilizado pelos plugins upstream de Kubernetes e Docker. Dois componentes são distribuídos no mesmo pacote: uma cdylib leve carregada pelo bacula-fd, e um binário backend em Rust que realiza toda a E/S SSH/SFTP via libssh2. A separação cdylib-backend mantém o processo FD estável mesmo que um dispositivo de rede se comporte de forma inadequada durante a transferência. Os níveis de backup (Full, Incremental, Differential) são determinados por comparação padrão de mtime. Filtros glob de include/exclude, FileSets com múltiplos servidores, assinaturas SHA256, compressão LZ4/GZIP e criptografia AES pertencem ao conjunto nativo de funcionalidades do Bacula sem custo adicional.

A versão 2.0.0, lançada em abril de 2026, concluiu uma reescrita completa de ambos os componentes de C++/Python legado para Rust puro, eliminou a dependência do runtime Python e selou ambos os artefatos sob licença proprietária sem dependências estáticas licenciadas sob AGPL. O resultado é um plugin mais enxuto, mais rápido e totalmente proprietário que se encaixa em qualquer instalação existente do Bacula Community sem alterações de configuração no lado do Director.

2. Introdução e contexto de mercado

2.1 O problema do backup sem agente

O modelo padrão de implantação do Bacula Community requer um File Daemon (FD) em execução em cada host a ser copiado. O FD escuta na porta TCP 9102, transfere dados de arquivos para o Storage Daemon e mantém metadados para o catálogo. Esse modelo funciona bem para frotas homogêneas de servidores Linux ou Windows onde pacotes estão disponíveis e o acesso à porta é controlável.

O modelo falha em cinco classes de ambientes cada vez mais comuns:

  • Equipamentos de rede. Cisco IOS-XE, Junos, FortiOS, PAN-OS, RouterOS e sistemas operacionais de rede similares não suportam pacotes Linux. Esses dispositivos expõem SSH/SFTP como única interface programática de acesso a arquivos. O backup de configuração — o artefato de DR mais crítico para operações de rede — fica, portanto, fora do alcance do Bacula padrão sem scripts externos.
  • Appliances NAS. Synology DSM, QNAP QTS, TrueNAS e plataformas similares executam ambientes Linux altamente customizados onde instalar daemons de terceiros é não suportado ou impraticável. Todos possuem SFTP/SSH nativos.
  • Servidores legados e multiplataforma. Sistemas AIX, HP-UX e Solaris podem não ter pacotes FD atuais do Bacula. Servidores antigos CentOS 5/6 ainda em produção frequentemente não possuem FD compatível. Qualquer sistema onde SSH é o único mecanismo viável de acesso remoto.
  • Dispositivos IoT e embarcados. Gateways Raspberry Pi, PLCs industriais e dispositivos similares com armazenamento e CPU limitados não comportam a sobrecarga de um daemon persistente. O acesso SFTP é leve e universalmente disponível.
  • Serviços SFTP em nuvem. AWS Transfer Family, Azure Blob SFTP, Hetzner Storage Box e serviços gerenciados similares expõem dados exclusivamente via SFTP. Nenhum agente pode ser instalado no lado do servidor.

2.2 Por que as abordagens existentes são insuficientes

Ferramenta Abordagem Limitação
Bacula Community (nativo, sem plugin) Requer FD em cada host Impossível em equipamentos de rede, NAS, serviços SFTP em nuvem
Veeam Baseado em agente ou agentless via hypervisor Sem caminho SSH/SFTP nativo; sem suporte a dispositivos de rede
Commvault File System iDataAgent Instalação de agente necessária; sem suporte a OS de rede
NetBackup Agente cliente Mesma limitação; proprietário e caro
rsync + cron SSH sem agente Sem catálogo, sem retenção, sem restauração pontual, sem monitoramento
Scripts scp customizados Cópia de arquivo ad-hoc Sem versionamento, sem verificação, ingerenciável em escala
Pontos de montagem SSHFS Montagem FUSE sobre SSH Montagens obsoletas, módulo kernel FUSE necessário, chamadas stat travadas bloqueando o FD

2.3 A abordagem PodHeitor

O plugin transforma o Bacula Community em uma plataforma de backup verdadeiramente sem agente para recursos acessíveis via SSH. Um único Bacula File Daemon, com o plugin instalado, pode fazer backup de um número ilimitado de sistemas remotos. O Bacula Director, catálogo, pool de storage, políticas de retenção, agendamentos e fluxo de restauração se aplicam de forma idêntica — o plugin simplesmente adiciona SSH/SFTP como camada de transporte de dados.

Essa abordagem é consistente com a filosofia mais ampla de plugins PodHeitor: nativo em Rust, sem dependências de runtime além de libssh2 e OpenSSL, arquitetura de protocolo PTCOMM para separação limpa cdylib/backend, e integração completa com as funcionalidades nativas do Bacula em vez de reimplementá-las.

3. Visão geral da arquitetura

3.1 Design de dois componentes

O plugin é distribuído como dois binários no mesmo pacote:

Componente Arquivo Função
Plugin FD do Bacula (cdylib) /opt/bacula/plugins/podheitor-sftp-fd.so Carregado pelo bacula-fd na inicialização; implementa API de plugin do Bacula; define o namespace @sftp; inicializa e faz a ponte com o backend
Binário backend /opt/bacula/bin/podheitor-sftp-backend Iniciado por job pela cdylib; realiza toda E/S SSH/SFTP via libssh2; gerencia percurso de diretórios, filtragem mtime e transferência de arquivos

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

  1. Isolamento. Toda E/S de rede e lógica SSH residem no backend. Uma falha, travamento ou timeout no backend não pode corromper o processo FD do Bacula nem afetar outros jobs concorrentes.
  2. Atualizabilidade. O binário backend pode ser substituído sem reiniciar o bacula-fd, pois somente a cdylib toca a ABI de plugins do Bacula.
  3. Testabilidade. O backend pode ser executado diretamente em testes de integração sem envolver o Bacula — comportamento SSH, lógica include/exclude e enquadramento PTCOMM são todos verificáveis independentemente.

3.2 Protocolo PTCOMM

A cdylib e o backend se comunicam pelo stdin/stdout do processo filho usando o PTCOMM (PodHeitor Transport Communications), um protocolo de enquadramento com marcação de comprimento compartilhado por todos os plugins PodHeitor:

┌───────┬──────────────┬─────┬──────────────────────┐
│ Status│ Comprimento  │ n  │ Payload (N bytes)    │
│ 1 byte│  6 bytes     │1byte│ 0..999999 bytes      │
└───────┴──────────────┴─────┴──────────────────────┘

Tipos de pacote utilizados pelo plugin SFTP:

Status Tipo Direção Descrição
C Comando Bidirecional FNAME, STAT, HELLO, BackupStart, etc.
D Dados Backend → FD Payload de dados brutos do arquivo (blocos de 64 KB)
F EOD Bidirecional Fim dos Dados / ACK
E Erro Backend → FD Mensagem de erro
I Info Backend → FD Mensagem informativa / de progresso
A Abortar Backend → FD Abortar o job atual
T Terminar FD → Backend Sinal de desligamento gracioso

3.3 Diagrama de arquitetura

┌─────────────────────────────────────────────────────────────────────┐
│                        BACULA DIRECTOR                              │
│                                                                     │
│   Job "SFTP-Daily"  ──▶  FileSet "SFTP-Backup"                     │
│   Type = Backup          Plugin = "podheitor-sftp: host=... "       │
│   Level = Incremental    Signature = SHA256; Compression = LZ4      │
└───────────────────────────────────┬─────────────────────────────────┘
                                    │  Protocolo Bacula Director
                                    ▼
┌─────────────────────────────────────────────────────────────────────┐
│                      BACULA FILE DAEMON (FD)                        │
│                                                                     │
│   ┌──────────────────────────────────────────────────────────────┐  │
│   │  podheitor-sftp-fd.so  (Rust cdylib puro, metaplugin-rs)     │  │
│   │  • Registro no FD via bpFuncs API                            │  │
│   │  • Define namespace @sftp                                    │  │
│   │  • Inicializa subprocess backend em Rust                     │  │
│   │  • Faz ponte callbacks FD <—> pacotes PTCOMM                │  │
│   └───────────────────────┬──────────────────────────────────────┘  │
│                           │ stdin/stdout (protocolo binário PTCOMM) │
│   ┌───────────────────────▼──────────────────────────────────────┐  │
│   │  podheitor-sftp-backend  (Rust binary, ssh2 crate/libssh2)   │  │
│   │  • Gerenciador de protocolo PTCOMM                           │  │
│   │  • Conexão SSH/SFTP via libssh2                              │  │
│   │  • Percurso recursivo de diretórios com include/exclude      │  │
│   │  • Transferência de dados de arquivo (FNAME/STAT/DATA)       │  │
│   │  • Full/Incremental/Differential por comparação mtime        │  │
│   └───────────────────────┬──────────────────────────────────────┘  │
│                           │ SSH/SFTP (porta TCP 22)                 │
└───────────────────────────┼─────────────────────────────────────────┘
                            ▼
┌─────────────────────────────────────────────────────────────────────┐
│                      HOST SFTP REMOTO                               │
│   Servidor OpenSSH — nenhum agente Bacula necessário                │
│   Apenas acesso de leitura nos caminhos de backup                   │
└─────────────────────────────────────────────────────────────────────┘

3.4 Separação de responsabilidades

podheitor-sftp-fd.so (Rust cdylib) podheitor-sftp-backend (Rust binary)
Registro e ciclo de vida no FD SSH/SFTP via libssh2
Ponte PTCOMM para callbacks FD Percurso recursivo de diretórios
Definição do namespace @sftp Leitura de arquivos e fragmentação de dados
Zero lógica SFTP — ~600 LOC Comparação incremental baseada em mtime
Framework metaplugin-rs Filtragem glob include/exclude
Superfície ABI do Bacula Protocolo PTCOMM completo — ~1500 LOC

4. Modos de backup em profundidade

4.1 Backup Full

Um backup Full transfere todos os arquivos e diretórios sob o path configurado, independentemente do tempo de modificação. O backend se conecta ao servidor SFTP, realiza um percurso recursivo de diretórios e envia todos os arquivos para o plugin FD via pacotes PTCOMM DATA.

Since = 0 (todos os timestamps incluídos)

/data/
├── relatorio.pdf       ──▶ TRANSFERIR
├── planilha.xlsx       ──▶ TRANSFERIR
├── notas.txt           ──▶ TRANSFERIR
└── arquivo/
    ├── 2024-q1.pdf     ──▶ TRANSFERIR
    └── 2024-q2.pdf     ──▶ TRANSFERIR

Total: TODOS os arquivos

Um backup Full é autossuficiente — pode ser restaurado sem nenhum outro conjunto de backup. Backups Full são o ponto de partida recomendado para todos os agendamentos e devem ser executados no mínimo semanalmente na maioria dos ambientes.

4.2 Backup Incremental

Um backup Incremental transfere apenas os arquivos cujo mtime (timestamp de modificação) seja maior ou igual ao timestamp do backup mais recente — seja esse backup um Full, Differential ou Incremental anterior.

Since = <timestamp do último backup>

/data/
├── relatorio.pdf  (mtime: antes de Since) ──▶ IGNORAR
├── rascunho.pdf   (mtime: depois de Since) ──▶ TRANSFERIR
├── notas.txt      (mtime: antes de Since) ──▶ IGNORAR
└── arquivo/                               ──▶ SEMPRE percorrido (dirs)
    ├── 2024-q1.pdf (mtime: antes)         ──▶ IGNORAR
    └── 2025-q1.pdf (mtime: depois)        ──▶ TRANSFERIR

Total: apenas arquivos MODIFICADOS

Incrementais são os menores e mais rápidos. A desvantagem é que uma restauração requer o backup Full mais cada Incremental na cadeia. Para a maioria dos casos de uso SFTP (arquivos de configuração, documentos, dados NAS), a taxa de mudança é baixa e as cadeias de Incrementais permanecem curtas.

4.3 Backup Differential

Um backup Differential transfere todos os arquivos modificados desde o último backup Full, ignorando quaisquer Incrementais intermediários. Cada Differential é, portanto, maior que um Incremental mas menor que um Full.

Restaurar a partir de Differential:
  Full (Dia 1) + Differential (Dia 4) = apenas 2 volumes

Restaurar a partir de cadeia Incremental:
  Full (Dia 1) + Incr (Dia 2) + Incr (Dia 3) + Incr (Dia 4) = 4 volumes

Differentials são particularmente úteis para backups de configuração de equipamentos de rede, onde a frequência de mudanças é baixa mas o corpus total de configuração é pequeno e um caminho de restauração mais simples é preferível.

4.4 Comparação de níveis de backup

Nível O que é transferido Restauração requer Melhor para
Full Todos os arquivos Apenas este volume Âncora semanal; primeiro backup
Incremental Arquivos modificados desde o último backup (qualquer nível) Full + todos os Incrementais Backups diários; alvos SFTP de baixa mudança
Differential Arquivos modificados desde o último Full Full + este Differential Configurações de rede; caminho de restauração mais simples

4.5 Filtragem include/exclude

Antes de transferir qualquer arquivo, o backend aplica filtros glob de include e exclude correspondidos ao nome do arquivo (não ao caminho completo). A ordem de avaliação é: exclude primeiro, depois include.

Parâmetro Sintaxe Efeito
include Padrões glob separados por vírgula Apenas arquivos que correspondem a pelo menos um padrão são transferidos. Diretórios são sempre percorridos.
exclude Padrões glob separados por vírgula Arquivos e diretórios que correspondem a qualquer padrão são ignorados.

Quando include é especificado, todos os arquivos que não correspondem a nenhum padrão include são silenciosamente ignorados. Esta é a abordagem recomendada para backups de configuração de equipamentos de rede, onde apenas arquivos *.conf, *.cfg, *.backup ou *.rsc são relevantes.

5. Matriz de funcionalidades

Funcionalidade Suportado Notas
Backup sem agente (somente SSH) Sim Sem instalação de software no host remoto
Backup Full Sim Todos os arquivos no path configurado
Backup Incremental Sim Comparação baseada em mtime
Backup Differential Sim mtime desde o último Full
Autenticação por chave SSH (ed25519) Sim Recomendado para produção
Autenticação por chave SSH (RSA, ECDSA) Sim Tipos de chave legados
Autenticação SSH por senha Sim Não recomendado para produção
Encaminhamento de agente SSH Sim Integra com ssh-agent do sistema
Verificação de host key (known_hosts) Sim Proteção MITM; habilitado por padrão
Porta SSH personalizada Sim Parâmetro port=; padrão 22
Timeout de conexão personalizado Sim timeout= em segundos; padrão 30
Filtros glob de include Sim Glob POSIX; separados por vírgula
Filtros glob de exclude Sim Glob POSIX; separados por vírgula
Metadados preservados (permissões, UID/GID, timestamps) Sim Restaurados no FS local
Tratamento de links simbólicos Sim Symlinks catalogados como tipo S
Múltiplos servidores SFTP em um FileSet Sim N linhas Plugin= no bloco Include
Assinaturas SHA256 Sim Options nativo do Bacula
Compressão LZ4 / GZIP Sim Options nativo do Bacula
Criptografia AES Sim Options nativo do Bacula
Listagem de arquivos pré-backup (estimate) Sim estimate job=… listing
Consulta ao catálogo pós-backup Sim list files jobid=X
Navegação interativa na árvore de restauração Sim restore → cd/ls/mark
Restauração seletiva de arquivos Sim mark arquivos individuais no bconsole
Abortar em erro de arquivo Sim Parâmetro abort_on_error=
Log de debug Sim Variável de ambiente PODHEITOR_DEBUG=1
Pacote RPM (RHEL/OL/Rocky 9) Sim Instalação com um único comando
Arch Linux PKGBUILD Sim makepkg -si
Compilação a partir do código-fonte Sim make all; sem necessidade de código-fonte do Bacula
Destino Windows OpenSSH Server Sim OpenSSH nativo no Windows 10/11/Server 2019+
Destinos de equipamentos de rede (Cisco, Juniper, MikroTik, etc.) Sim Qualquer dispositivo com SSH/SFTP
Suporte a arquivos grandes (> 1 GB) Sim Transmitido em blocos de 64 KB; sem limite de tamanho

6. Guia de instalação

6.1 Pré-requisitos

  • Bacula Community 13.0.0 ou posterior instalado com bacula-fd em execução
  • Plugin Directory configurado em bacula-fd.conf (geralmente /opt/bacula/plugins)
  • Bibliotecas de runtime: libssh2 e openssl (pacotes do sistema)
  • Par de chaves SSH gerado para operações de backup (ed25519 recomendado)
  • Acesso de leitura concedido ao usuário SSH em todos os caminhos remotos a serem copiados

6.2 Instalação RPM (RHEL / Oracle Linux / Rocky Linux 9)

# 1. Instalar dependências de runtime
sudo dnf install libssh2 openssl-libs

# 2. Instalar o RPM do plugin
sudo rpm -ivh podheitor-sftp-fd-plugin-2.0.0-1.el9.x86_64.rpm

# 3. Verificar arquivos instalados
ls -l /opt/bacula/plugins/podheitor-sftp-fd.so
ls -l /opt/bacula/bin/podheitor-sftp-backend

# 4. Confirmar que libssh2 está acessível
ldconfig -p | grep libssh2

# 5. Reiniciar FD para carregar o plugin
sudo systemctl restart bacula-fd

# 6. Confirmar que o plugin foi carregado
echo "status client" | bconsole | grep -i podheitor
# Esperado: Plugin: podheitor-sftp-fd.so

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

# 1. Instalar dependências de runtime
sudo apt install libssh2-1 openssl

# 2. Instalar o pacote DEB
sudo dpkg -i podheitor-sftp-fd-plugin_2.0.0-1_amd64.deb

# 3. Verificar arquivos instalados
ls -l /opt/bacula/plugins/podheitor-sftp-fd.so
ls -l /opt/bacula/bin/podheitor-sftp-backend

# 4. Reiniciar FD
sudo systemctl restart bacula-fd

6.4 Arch Linux (PKGBUILD)

makepkg -si

6.5 Compilar a partir do código-fonte

# Dependências de build: Rust 1.75+, cargo, libssh2-dev, libssl-dev, pkg-config
# Código-fonte do Bacula NÃO é necessário.

git clone https://github.com/podheitor/podheitor-sftp-bacula.git
cd podheitor-sftp-bacula
make all
sudo make install PREFIX=/opt/bacula

Arquivos instalados:

/opt/bacula/
├── plugins/
│   └── podheitor-sftp-fd.so       ← módulo plugin FD (Rust cdylib)
└── bin/
    └── podheitor-sftp-backend     ← binário backend Rust

6.6 Configuração do diretório de plugins FD

Certifique-se de que bacula-fd.conf aponta para o diretório correto:

FileDaemon {
  Name = meuservidor-fd
  Plugin Directory = /opt/bacula/plugins
}

6.7 Configuração de chave SSH

# Gerar uma chave ed25519 dedicada para o Bacula (sem passphrase para automação)
sudo mkdir -p /etc/bacula/.ssh
sudo ssh-keygen -t ed25519 -f /etc/bacula/.ssh/id_ed25519 -N "" -C "bacula-backup"

# Definir permissões seguras
sudo chown -R root:bacula /etc/bacula/.ssh
sudo chmod 700 /etc/bacula/.ssh
sudo chmod 640 /etc/bacula/.ssh/id_ed25519
sudo chmod 644 /etc/bacula/.ssh/id_ed25519.pub

# Copiar chave pública para o servidor remoto
sudo ssh-copy-id -i /etc/bacula/.ssh/id_ed25519.pub backup@servidor.local

# Pré-popular known_hosts para verificação de host key
sudo ssh-keyscan -H servidor.local | sudo tee -a /etc/bacula/.ssh/known_hosts

7. Referência de configuração

7.1 String de parâmetros do plugin

Plugin = "podheitor-sftp: <param1>=<valor1> <param2>=<valor2> ..."

7.2 Referência de parâmetros

Parâmetro Obrigatório Padrão Tipo Descrição
host Sim — string Hostname ou endereço IP do servidor SFTP
port Não 22 int Número de porta SSH/SFTP
user Sim — string Nome de usuário SSH no servidor remoto
password Não — string Senha SSH (prefira keyfile)
keyfile Não — string Caminho para arquivo de chave privada SSH
passphrase Não — string Passphrase para chave privada criptografada
path Sim / string Diretório base remoto para backup
known_hosts Não — string Caminho para arquivo SSH known_hosts
verify_host Não yes bool Verificar host key SSH (proteção MITM)
timeout Não 30 int Timeout de conexão em segundos
include Não — string Padrões glob separados por vírgula para incluir (ex.: *.pdf,*.docx)
exclude Não — string Padrões glob separados por vírgula para excluir (ex.: *.tmp,*.log)
abort_on_error Não no bool Abortar job em erro de leitura de arquivo

7.3 Configuração mínima de FileSet

FileSet {
  Name = "SFTP-Minimal"
  Include {
    Options { Signature = SHA256 }
    Plugin = "podheitor-sftp: host=servidor.local user=backup keyfile=/etc/bacula/.ssh/id_ed25519 path=/dados"
  }
}

7.4 Configuração completa com todas as opções

FileSet {
  Name = "SFTP-Completo"
  Include {
    Options {
      Signature = SHA256
      Compression = LZ4
    }
    Plugin = "podheitor-sftp: host=fileserver.exemplo.com.br port=22 user=svc-backup keyfile=/etc/bacula/.ssh/id_ed25519 path=/srv/dados known_hosts=/etc/bacula/.ssh/known_hosts verify_host=yes timeout=60 include=*.pdf,*.docx,*.xlsx exclude=*.tmp,*.cache,*.log"
  }
}

Job {
  Name = "SFTP-Documentos-Backup"
  Type = Backup
  Level = Incremental
  Client = meubacula-fd
  FileSet = "SFTP-Completo"
  Schedule = "SFTP-CicloSemanal"
  Storage = File1
  Pool = Default
  Messages = Standard
  Priority = 10
}

Schedule {
  Name = "SFTP-CicloSemanal"
  Run = Full 1st sun at 23:05
  Run = Differential 2nd-5th sun at 23:05
  Run = Incremental mon-sat at 23:05
}

7.5 Job de restauração

Job {
  Name = "SFTP-Documentos-Restore"
  Type = Restore
  Client = meubacula-fd
  FileSet = "SFTP-Completo"
  Storage = File1
  Pool = Default
  Messages = Standard
  Where = /tmp/sftp-restore
}

8. Exemplos de FileSet

8.1 Backup de pasta compartilhada NAS

FileSet {
  Name = "NAS-Synology"
  Include {
    Options { Signature = SHA256; Compression = LZ4 }
    Plugin = "podheitor-sftp: host=synology.local user=admin keyfile=/etc/bacula/.ssh/nas_key path=/volume1/shared"
    Plugin = "podheitor-sftp: host=synology.local user=admin keyfile=/etc/bacula/.ssh/nas_key path=/volume1/photos"
    Plugin = "podheitor-sftp: host=synology.local user=admin keyfile=/etc/bacula/.ssh/nas_key path=/volume1/documents"
  }
}

8.2 Backup de configuração de equipamentos de rede

FileSet {
  Name = "Configs-Equipamentos-Rede"
  Include {
    Options { Signature = SHA256 }
    # Cisco Catalyst — apenas running-config
    Plugin = "podheitor-sftp: host=10.0.0.1 user=admin keyfile=/etc/bacula/.ssh/net_key path=/ include=*.conf,*.cfg verify_host=no"
    # Juniper SRX — diretório /config
    Plugin = "podheitor-sftp: host=10.0.0.2 user=backup keyfile=/etc/bacula/.ssh/net_key path=/config verify_host=no"
    # MikroTik RouterOS — arquivos de backup e exportação
    Plugin = "podheitor-sftp: host=10.0.0.3 user=admin keyfile=/etc/bacula/.ssh/net_key path=/ include=*.backup,*.rsc verify_host=no"
    # FortiGate — backup de configuração
    Plugin = "podheitor-sftp: host=10.0.0.4 user=admin keyfile=/etc/bacula/.ssh/net_key path=/ include=*.conf verify_host=no"
  }
}

Schedule {
  Name = "Rede-Diario"
  Run = Full daily at 02:00
}

Job {
  Name = "Backup-Config-Rede"
  Type = Backup
  Level = Full
  Client = bacula-fd
  FileSet = "Configs-Equipamentos-Rede"
  Schedule = "Rede-Diario"
  Storage = File1
  Pool = Default
  Messages = Standard
}

8.3 Múltiplos servidores web

FileSet {
  Name = "ServidoresWeb-Backup"
  Include {
    Options { Signature = SHA256; Compression = LZ4 }
    Plugin = "podheitor-sftp: host=web1.prod.com.br user=deploy keyfile=/etc/bacula/.ssh/web_key path=/var/www exclude=*.log,*.tmp,cache"
    Plugin = "podheitor-sftp: host=web1.prod.com.br user=deploy keyfile=/etc/bacula/.ssh/web_key path=/etc/nginx"
    Plugin = "podheitor-sftp: host=web2.prod.com.br user=deploy keyfile=/etc/bacula/.ssh/web_key path=/var/www exclude=*.log,*.tmp,cache"
    Plugin = "podheitor-sftp: host=web2.prod.com.br user=deploy keyfile=/etc/bacula/.ssh/web_key path=/etc/nginx"
  }
}

8.4 Serviços SFTP em nuvem

FileSet {
  Name = "Servicos-SFTP-Nuvem"
  Include {
    Options { Signature = SHA256; Compression = LZ4 }
    # AWS Transfer Family
    Plugin = "podheitor-sftp: host=s-1234abcd.server.transfer.us-east-1.amazonaws.com user=meuusuario keyfile=/etc/bacula/.ssh/aws_sftp_key path=/dados"
    # Hetzner Storage Box (porta 23)
    Plugin = "podheitor-sftp: host=u12345.your-storagebox.de port=23 user=u12345 keyfile=/etc/bacula/.ssh/hetzner_key path=/backups"
  }
}

8.5 IoT e sistemas legados

FileSet {
  Name = "IoT-E-Legados"
  Include {
    Options { Signature = SHA256 }
    # Gateway IoT Raspberry Pi
    Plugin = "podheitor-sftp: host=iot-gw.local user=pi keyfile=/etc/bacula/.ssh/iot_key path=/etc timeout=15"
    Plugin = "podheitor-sftp: host=iot-gw.local user=pi keyfile=/etc/bacula/.ssh/iot_key path=/opt/iot/config timeout=15"
    # Servidor legado AIX
    Plugin = "podheitor-sftp: host=aix-prod.local user=root keyfile=/etc/bacula/.ssh/legacy_key path=/etc"
    # Servidor Solaris
    Plugin = "podheitor-sftp: host=solaris.local user=root keyfile=/etc/bacula/.ssh/legacy_key path=/export/home"
  }
}

9. Dimensionamento e planejamento de capacidade

9.1 Estimando o tamanho do backup

Use estimate no bconsole antes de comprometer um agendamento:

* estimate job=SFTP-Documentos-Backup level=Full listing

Isso se conecta ao servidor SFTP, percorre a árvore de diretórios aplicando todos os filtros include/exclude e reporta a contagem de arquivos e o tamanho estimado — sem transferir nenhum dado:

@sftp/fileserver.local:22/dados/relatorio.pdf              1.234.567
@sftp/fileserver.local:22/dados/planilha.xlsx                456.789
@sftp/fileserver.local:22/dados/imagens/foto1.jpg          2.345.678
...
2.000 arquivos encontrados, tamanho estimado: 1,2 GB

9.2 Requisitos de armazenamento

Tipo de backup Tamanho típico relativo ao Full Recomendação de retenção
Full 100% 4 semanas (rotação mensal)
Differential 5–40% do Full Manter os últimos 7 Differentials
Incremental 0,1–5% do Full por dia Manter os últimos 30 Incrementais

Para configurações de equipamentos de rede, o corpus total é tipicamente inferior a 10 MB por dispositivo, tornando backups Full diários insignificantes em termos de armazenamento. Para shares NAS grandes ou repositórios SFTP em nuvem, habilite compressão LZ4 (tipicamente 30–60% de redução para arquivos de texto e documentos) e configure janelas de retenção adequadas no Pool.

9.3 Planejamento de largura de banda de rede

O plugin transmite dados de arquivos diretamente do servidor SFTP para o Bacula Storage. Os requisitos de largura de banda dependem de:

  • Tamanho do backup Full — o Full inicial estabelece a carga de rede base
  • Taxa de mudança diária — o tamanho Incremental determina a largura de banda diária contínua
  • Janela de transferência — os backups devem concluir antes do próximo agendamento

Para ambientes com restrições (links WAN, conexões tarifadas), agende backups Full em horários de menor movimento e use Incremental para execuções diárias. O parâmetro timeout= deve ser definido para pelo menos 2× o tempo esperado para transferir o maior arquivo individual com a largura de banda disponível.

9.4 Impacto no catálogo

Cada arquivo copiado gera um registro no catálogo. Para FileSets com centenas de milhares de arquivos pequenos (ex.: /var/www de servidores web), o crescimento do catálogo pode ser significativo. Aplique filtros exclude de forma agressiva para pular arquivos efêmeros (*.log, *.tmp, *.cache, node_modules) que não precisam de backup e que de outra forma inflacionariam o catálogo.

10. Considerações de desempenho

10.1 Overhead de conexão SSH

Cada invocação do plugin (uma por linha Plugin = no FileSet) estabelece uma conexão SSH pelo tempo de duração do job. Troca de chaves e autenticação tipicamente completam em menos de 200 ms em uma LAN. Para alvos WAN, o parâmetro timeout= controla o tempo máximo de espera para a conexão inicial; operações subsequentes no nível de arquivo usam timeouts por operação herdados da libssh2.

10.2 Velocidade de percurso de diretórios

O backend realiza um percurso recursivo de diretório SFTP usando sftp_readdir da libssh2. Em uma LAN típica, o percurso processa aproximadamente 1.000–5.000 entradas por segundo dependendo da profundidade do diretório e latência de rede. Para FileSets com árvores de diretório profundas, habilite padrões exclude para podar subárvores cedo (ex.: exclude=node_modules,.git,__pycache__).

10.3 Throughput de transferência de arquivos

Os dados de arquivos são transferidos em blocos de 64 KB pelo canal SFTP. O throughput efetivo é limitado pelo overhead de criptografia SSH e pela largura de banda de rede disponível. Em condições de LAN (1 Gbps), espere 50–200 MB/s dependendo da velocidade da CPU e do tamanho dos arquivos. Para arquivos pequenos (arquivos de configuração abaixo de 1 KB), o throughput é limitado por IOPS em vez de largura de banda; use filtros include para limitar transferências apenas aos arquivos necessários.

10.4 Múltiplos servidores em paralelo

Múltiplas linhas Plugin = em um único FileSet são processadas sequencialmente dentro de um único job do Bacula. Para fazer backup de múltiplos servidores grandes em paralelo, crie Jobs Bacula separados cada um com seu próprio FileSet e agende-os para executar concorrentemente. As diretivas Maximum Concurrent Jobs e Priority do Bacula controlam o paralelismo.

11. Matriz de compatibilidade

11.1 Host do Bacula File Daemon (onde o plugin executa)

Plataforma Arquitetura Status
RHEL / Rocky / Oracle Linux 8–9 x86_64, aarch64 Testado
Debian 12 (Bookworm) x86_64, aarch64 Testado
Ubuntu 22.04 / 24.04 LTS x86_64, aarch64 Esperado
SUSE / openSUSE 15 x86_64 Esperado
Arch Linux x86_64 PKGBUILD disponível
FreeBSD 13+ amd64 Não testado (gmake necessário)

11.2 Alvos SFTP remotos (o que pode ser copiado)

Categoria Exemplos Notas
Servidores Linux Qualquer distribuição com OpenSSH Acesso completo ao sistema de arquivos
Servidores Windows Windows 10/11, Server 2019+ OpenSSH Server nativo necessário
macOS macOS 10.15+ Habilitar Login Remoto nas Preferências
BSD FreeBSD, OpenBSD, NetBSD OpenSSH nativo
Appliances NAS Synology DSM, QNAP QTS, TrueNAS Habilitar SFTP/SSH nas configurações do NAS
Cisco Catalyst 9000 (IOS-XE), Nexus (NX-OS), ISR/ASR SSH/SFTP deve estar habilitado
Juniper EX, QFX, SRX, MX (Junos) SSH/SFTP nativo no Junos
MikroTik Todos os dispositivos RouterOS SFTP nativo
Arista 7000, 7500 (EOS) SSH/SFTP nativo
Fortinet FortiGate (FortiOS) SFTP deve ser habilitado na interface de gerenciamento
Palo Alto Série PA (PAN-OS) SSH/SFTP via plano de gerenciamento
HPE Aruba Switches CX, Instant AP SSH nativo
Ubiquiti UniFi, EdgeRouter SSH nativo
VyOS / OPNsense / pfSense Firewalls comunitários/open source SSH nativo
AWS Transfer Family Endpoints SFTP gerenciados Somente autenticação por chave
Azure Blob SFTP Acesso SFTP ao Azure Storage Autenticação por chave; funcionalidade preview/GA
Hetzner Storage Box SFTP nativo (porta 23) port= personalizado necessário
Raspberry Pi / IoT OpenWrt, DietPi, Raspberry Pi OS Leve; use timeout=15
Unix legado AIX, HP-UX, Solaris Qualquer versão com OpenSSH

11.3 Versão mínima do Bacula

Bacula Community 13.0.0+ é necessário para o framework Metaplugin sobre o qual o plugin é construído. Versões anteriores não são suportadas. O plugin foi testado contra Bacula 13.x e 15.x.

12. Segurança

12.1 Melhores práticas de autenticação

Prática Descrição
Use chaves SSH, nunca senhas Senhas na configuração do Bacula são armazenadas em texto plano; chaves SSH nunca são transmitidas
Use chaves ed25519 Algoritmo moderno; tamanho pequeno; resistente a ataques de canal lateral
Par de chaves de backup dedicado Gerar uma chave exclusivamente para o Bacula; nunca reutilizar chaves pessoais ou de admin
Restringir permissões de chave chmod 640 no arquivo de chave privada; pertencendo a root:bacula
Usuário SSH dedicado no remoto Criar um usuário backup com apenas acesso de leitura aos caminhos de backup
ACLs somente leitura O usuário de backup não deve ter acesso de escrita — violação do servidor Bacula não pode modificar dados remotos
Habilitar verify_host=yes Sempre verificar host keys em produção; pré-popular known_hosts antes do primeiro backup
Arquivo known_hosts separado Usar /etc/bacula/.ssh/known_hosts em vez do known_hosts pessoal do root
Firewall apenas para porta 22 Permitir apenas TCP 22 entre o host FD e os alvos SFTP; bloquear todas as outras portas

12.2 Fluxo de verificação de host key

verify_host=yes (PADRÃO — RECOMENDADO para produção)
  ├── Carregar arquivo known_hosts (se configurado)
  ├── Se host key NÃO está em known_hosts → ERRO: conexão recusada
  └── Se host key está em known_hosts → comparar fingerprint → OK ou ERRO

verify_host=no (SOMENTE para laboratório / testes)
  ├── AutoAddPolicy — aceita qualquer host key na primeira conexão
  └── ATENÇÃO: Vulnerável a ataques Man-in-the-Middle

12.3 Armazenamento de credenciais

Arquivos de chave privada SSH referenciados por keyfile= permanecem no sistema de arquivos do host Bacula FD e nunca são transmitidos para servidores remotos — apenas a chave pública é usada para autenticação. A chave privada deve ser armazenada em um diretório legível apenas pelo processo Bacula FD (tipicamente root ou o usuário bacula). Se o arquivo de configuração do Bacula Director for legível por todos, use chaves SSH em vez do parâmetro password=, que armazena credenciais em texto plano na configuração do Director.

12.4 Segurança de transporte

Toda transferência de dados ocorre pelo canal SSH criptografado. O protocolo SSH (via libssh2) negocia a cipher suite durante a troca de chaves; padrões modernos do OpenSSH usam ChaCha20-Poly1305 ou AES-256-GCM. Para criptografia adicional em repouso no Bacula Storage, habilite criptografia AES no bloco Options do FileSet — isso é independente e adicional à criptografia de transporte SSH.

13. Monitoramento

13.1 Monitoramento padrão de jobs Bacula

O plugin integra completamente com a infraestrutura de monitoramento embutida do Bacula. Todos os resultados de jobs aparecem no log de Mensagens do Bacula e são entregues ao recurso Messages configurado (e-mail, syslog, arquivo):

* list jobs
* show job=SFTP-Documentos-Backup
* messages

13.2 Verificação por listagem de arquivos

Após um backup concluído, verifique se os arquivos esperados foram catalogados:

* list files jobid=42
+----------------------------------------------------------+
| filename                                                 |
+----------------------------------------------------------+
| @sftp/fileserver.local:22/dados/                         |
| @sftp/fileserver.local:22/dados/relatorio.pdf            |
| @sftp/fileserver.local:22/dados/planilha.xlsx            |
+----------------------------------------------------------+

13.3 Resumo dos métodos de listagem de arquivos

Método Quando Comando Requer backup?
Estimate pré-backup Antes do backup — percurso SFTP ao vivo estimate job=... level=Full listing Não
Catálogo pós-backup Após o backup — consulta ao catálogo list files jobid=X Sim
Árvore interativa de restauração Durante restauração — navegar pelo catálogo restore → cd/ls Sim

13.4 Habilitando log de debug

# RHEL / Oracle Linux — adicionar em /etc/sysconfig/bacula-fd
PODHEITOR_DEBUG=1

# Debian / Ubuntu — adicionar em /etc/default/bacula-fd
PODHEITOR_DEBUG=1

# Então reiniciar FD
sudo systemctl restart bacula-fd

Os logs do backend (stderr) são capturados pelo FD e aparecem diretamente nas mensagens do job Bacula. Cada operação SFTP, decisão de comparação mtime e resultado de filtro include/exclude são registrados quando PODHEITOR_DEBUG=1 está definido.

14. Guia de resolução de problemas

14.1 Problemas comuns e soluções

Sintoma Causa provável Solução
Command plugin not found .so não está no Plugin Directory Verificar se /opt/bacula/plugins/podheitor-sftp-fd.so existe; reiniciar FD
Unable to use backend Binário backend ausente ou não executável Verificar /opt/bacula/bin/podheitor-sftp-backend com chmod +x
SSH auth failed Chave SSH inválida ou usuário errado Testar: sudo ssh -i /caminho/chave usuario@host
Permission denied em arquivos Usuário SSH sem acesso de leitura setfacl -R -m u:backup:rX /dados no servidor remoto
Backend trava / timeout Problema de rede ou firewall Testar: nc -zv host 22; aumentar timeout=60
libssh2 not found Biblioteca de runtime ausente apt install libssh2-1 ou dnf install libssh2
Host key verification failed Host key não está em known_hosts Executar ssh-keyscan host >> /etc/bacula/.ssh/known_hosts
Job executa mas 0 arquivos copiados path incorreto ou diretório vazio Verificar caminho remoto: sftp usuario@host; ls /dados
0 arquivos com include definido Padrão include muito restritivo Verificar padrões: include=*.pdf corresponde apenas a arquivos .pdf
Incrementais copiando todos os arquivos Timestamps mtime incorretos no remoto Verificar sincronização de clock (NTP) no host remoto; considerar agendamento Full

14.2 Sequência de teste manual de conectividade

# 1. Alcançabilidade TCP
nc -zv servidor.local 22

# 2. Teste de autenticação SSH (executar como root — mesmo que o FD)
sudo ssh -i /etc/bacula/.ssh/id_ed25519 -o BatchMode=yes backup@servidor.local echo OK

# 3. Teste de listagem de diretório SFTP
sudo sftp -i /etc/bacula/.ssh/id_ed25519 backup@servidor.local <<< "ls /dados"

# 4. Teste de host key (confirmar entrada em known_hosts)
ssh-keygen -F servidor.local -f /etc/bacula/.ssh/known_hosts

14.3 Verificando carregamento do plugin

sudo systemctl restart bacula-fd
echo "status client" | bconsole | grep -i podheitor
# Linha esperada: Plugin: podheitor-sftp-fd.so

14.4 Locais de logs

Componente Local do log
Bacula Director /opt/bacula/log/bacula.log
Bacula FD /opt/bacula/log/bacula.log
Saída de debug do backend Stderr capturado pelo FD, aparece nas mensagens do job
Journal FD do systemd journalctl -u bacula-fd

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

15.1 Backup de infraestrutura de rede empresarial

Uma instituição financeira opera 120 dispositivos de rede em três data centers: switches core Cisco Catalyst 9300, firewalls Juniper SRX, roteadores de borda MikroTik e firewalls de perímetro Fortinet FortiGate. A equipe de rede historicamente executava transferências TFTP/SCP ad-hoc para uma pasta compartilhada — sem versionamento, sem retenção, sem processo de restauração.

Com o PodHeitor SFTP Plugin, toda a frota de dispositivos de rede é integrada à infraestrutura Bacula existente. Cada tipo de dispositivo mapeia para um FileSet com padrões include apropriados (*.conf, *.backup, *.rsc). Backups Full diários executam às 02:00 com um pool de retenção de 30 dias. A equipe de operações pode restaurar qualquer configuração de dispositivo para qualquer ponto dos últimos 30 dias via comandos restore padrão do bconsole. Corpus total de backup: menos de 50 MB por execução diária em todos os 120 dispositivos.

15.2 Backup de consolidação NAS

Uma empresa de manufatura opera quatro appliances NAS — duas unidades Synology DiskStation e dois dispositivos QNAP — distribuídas pelo chão de fábrica e escritórios. Cada NAS armazena arquivos CAD, relatórios de produção e arquivos de digitalização. Instalar FDs do Bacula nesses appliances não é suportado pelo fabricante.

O PodHeitor SFTP Plugin faz backup de todos os quatro volumes NAS a partir de um único host Bacula FD localizado na sala de servidores. Backups Incrementais executam diariamente; backups Full executam todo domingo. O filtro exclude=*.tmp,*.part elimina uploads incompletos. A restauração de arquivos individuais é realizada via navegação interativa em árvore no bconsole, que mapeia diretamente para o namespace @sftp/nashost:22/volume1/caminho.

15.3 Backup agentless de VMs em nuvem

Um provedor SaaS executa 40 VMs de aplicação entre AWS EC2 e GCP Compute Engine. Instalar e gerenciar pacotes FD do Bacula nessa frota, com rotação de chaves IAM, regras de security group e cadência de atualização de agente, representava uma carga operacional significativa.

O PodHeitor SFTP Plugin elimina o agente por VM. O diretório de dados de aplicação de cada VM é copiado via um único par de chaves SSH compartilhado pela frota. Backups Incrementais executam a cada 6 horas, capturando apenas o estado de aplicação modificado. O par de chaves AWS é armazenado em /etc/bacula/.ssh/aws_key com permissões 640. Infraestrutura Bacula total: um host FD com o plugin, um Storage Daemon, um Director.

15.4 Integração de sistemas legados

Um prestador de saúde executa software crítico de agendamento de pacientes em um servidor Solaris 10 e um servidor AIX 7.2 que precedem o empacotamento atual do FD do Bacula. O risco de tocar esses sistemas com novas instalações de software é considerado inaceitável pela equipe de conformidade.

O PodHeitor SFTP Plugin faz backup de ambos os servidores sem nenhuma instalação: o plugin se conecta via seus servidores OpenSSH existentes, faz backup de /export/home e /var/lib/app respectivamente, e integra com o restante da infraestrutura Bacula da organização. Os servidores legados permanecem intocados. A restauração é realizada em um ambiente de staging para verificação antes da recuperação de produção.

15.5 Gerenciamento de configuração IoT

Uma empresa de energia implanta 200 gateways Raspberry Pi em subestações elétricas. Cada gateway executa software de monitoramento customizado cujos arquivos de configuração representam meses de calibração em campo. A perda de configuração requer recalibração manual em cada site.

O PodHeitor SFTP Plugin faz backup de /etc e /opt/monitor/config de cada gateway diariamente. O parâmetro timeout=15 acomoda respostas SSH mais lentas dos gateways. Filtros include limitam o escopo do backup apenas a arquivos de configuração, mantendo o backup de cada gateway abaixo de 5 MB. Toda a frota de 200 gateways é copiada em menos de 30 minutos a partir de um único host Bacula FD pela WAN MPLS da empresa.

16. Comparação com outras abordagens

16.1 PodHeitor SFTP Plugin vs rsync + cron

Capacidade PodHeitor SFTP Plugin rsync + cron
Integração com catálogo Bacula Sim — registro completo no catálogo Não — ferramenta externa
Restauração pontual Sim — qualquer job no catálogo Não — apenas último rsync
Backup Incremental Sim — mtime via níveis Bacula Parcial — rsync –link-dest
Políticas de retenção Sim — retenção de Pool Bacula Não — limpeza manual
Múltiplos alvos de storage Sim — Bacula Storage Daemon Não — apenas disco local
Storage em fita / nuvem Sim — via Storage Daemon Não
Monitoramento e alertas Sim — Bacula Messages Manual (e-mail do cron)
Árvore interativa de restauração Sim — restore no bconsole Não — navegação manual no FS
Múltiplos servidores em um job Sim — N linhas Plugin= Não — N scripts separados
Integridade SHA256 Sim — Options do Bacula Não
Criptografia em repouso Sim — AES via Bacula Não — arquivos em texto plano

16.2 PodHeitor SFTP Plugin vs pontos de montagem SSHFS

Aspecto PodHeitor SFTP Plugin Montagem SSHFS
Risco de montagem obsoleta Não — conexão nova por job Sim — montagens ficam obsoletas e falham silenciosamente
Dependência de kernel Não — userspace puro (libssh2) Sim — módulo kernel FUSE necessário
Risco de FD travado Não — timeout SFTP por operação Sim — chamadas stat travadas bloqueiam o daemon
Suporte a equipamentos de rede Sim — SSH nativo em switches/roteadores Não — não é possível montar FS de OS de rede
Superfície de segurança Mínima — limitada ao path= apenas Maior — montagem completa expõe FS ao host FD
Complexidade de firewall Porta única 22 Porta 22 mais overhead FUSE/NFS
Gerenciamento de credenciais Na configuração Bacula (cifrada em repouso) Em /etc/fstab ou arquivos de montagem systemd

16.3 PodHeitor SFTP Plugin vs Veeam / Commvault / NetBackup

Aspecto PodHeitor SFTP Plugin + Bacula Plataformas comerciais
Backup de equipamentos de rede Sim — SSH/SFTP nativo Sem suporte nativo; soluções de contorno com scripts
Backup NAS sem agente Sim — somente SSH Limitado; conectores específicos por fabricante
Unix legado (AIX, Solaris) Sim — somente SSH Agente necessário; versões antigas de agente
Serviços SFTP em nuvem Sim — conexão SFTP direta Não suportado nativamente
Custo de licenciamento Fração do custo comercial Precificação por socket ou por TB
Infraestrutura aberta Sim — Bacula Community Lock-in de fornecedor

17. Roadmap

As seguintes capacidades estão planejadas ou sob investigação para versões futuras:

  • Hooks pré/pós-backup. Executar comandos arbitrários no host remoto via SSH antes e após o percurso SFTP (ex.: liberar buffers de escrita de aplicação, rotacionar arquivos de log).
  • Parâmetro de throttle de largura de banda. Limitar a taxa de transferência SFTP (KB/s) para evitar saturar links WAN durante o horário comercial — consistente com o suporte a throttle em outros plugins PodHeitor.
  • Percursos de diretório paralelos. Percorrer múltiplos subdiretórios de nível superior concorrentemente dentro de uma única invocação de plugin, reduzindo o tempo total de percurso para árvores de diretório profundas.
  • Endpoint de métricas Prometheus. Expor bytes transferidos por job, contagens de arquivos, latência de conexão e contagens de erros em um endpoint HTTP configurável — alinhado com a integração de monitoramento disponível em outros plugins PodHeitor.
  • Pacote DEB no repositório upstream. Pacotes DEB pré-compilados para Debian 12 e Ubuntu 22.04/24.04 distribuídos via repositório APT PodHeitor.
  • Melhorias para alvos Windows. Tratamento aprimorado de metadados NTFS do Windows (ACLs, alternate data streams) ao fazer backup de alvos Windows OpenSSH Server.

18. Conclusão

O PodHeitor SFTP Backup Plugin for Bacula entrega o que nenhuma plataforma de backup open source padrão havia oferecido antes: uma solução de backup agentless, integrada ao catálogo e de nível de produção para qualquer dispositivo acessível via SSH. De switches de rede empresariais a serviços SFTP em nuvem, de servidores AIX legados a gateways IoT, de appliances NAS a ambientes de hospedagem web — se o dispositivo fala SSH, agora ele pode fazer parte da mesma infraestrutura Bacula que protege o restante da organização.

A implementação nativa em Rust do plugin, a separação limpa cdylib/backend, a eliminação da dependência Python (v2.0.0+) e a integração completa com as funcionalidades nativas do Bacula (agendamento, retenção, catálogo, compressão, criptografia, monitoramento) fazem dele a integração de backup SSH/SFTP agentless mais completa disponível para o Bacula Community Edition. A comparação com scripts rsync, montagens SSHFS e plataformas comerciais deixa claro que o plugin preenche uma lacuna real e anteriormente não endereçada no ecossistema de backup open source.

Para organizações que já executam o Bacula Community, o caminho de migração é uma única instalação RPM ou DEB e três linhas de configuração no FileSet. Para organizações avaliando plataformas de backup, a combinação de Bacula Community e plugins PodHeitor oferece cobertura de nível empresarial a uma fração do custo das alternativas comerciais — sem lock-in de fornecedor e com controle total sobre dados e infraestrutura.

19. Informações de contato

Canal Detalhes
Website https://podheitor.com
E-mail heitor@opentechs.lat
WhatsApp / Telefone +1 786 726-1749 | +55 61 98268-4220
GitHub https://github.com/podheitor
LinkedIn https://linkedin.com/company/podheitor

Para consultas de licenciamento, contratos de suporte empresarial ou solicitações de desenvolvimento customizado, contate heitor@opentechs.lat diretamente. Uma proposta escrita comparando a stack PodHeitor + Bacula com sua renovação atual de plataforma comercial de backup pode ser fornecida mediante solicitação — com meta de pelo menos 50% de redução de custo.

20. Legal / direitos autorais

PodHeitor SFTP Backup Plugin for Bacula — Versão 2.0.0

Copyright (C) 2025–2026 PodHeitor International / Heitor Faria. Todos os direitos reservados.

Ambos os artefatos distribuídos — podheitor-sftp-fd.so (Rust cdylib construída sobre o framework in-house metaplugin-rs) e podheitor-sftp-backend (binário Rust usando o crate ssh2 / libssh2) — são software proprietário distribuído sob LicenseRef-PodHeitor-Proprietary.

Nenhum código licenciado sob AGPL está estaticamente vinculado em nenhum dos artefatos. Dependências Rust transitivas (ssh2, libssh2-sys, libc, parking_lot, openssl-sys, entre outras) são todas licenciadas de forma permissiva (MIT / Apache-2.0) e são compatíveis com redistribuição proprietária.

Uso, redistribuição, modificação, engenharia reversa ou exploração comercial de qualquer artefato requer um contrato de licença escrito separado com o detentor dos direitos autorais. Contato: heitor@opentechs.lat.

Bacula é marca registrada da Bacula Systems SA. Todos os outros nomes de produtos são marcas comerciais ou registradas de seus respectivos proprietários. PodHeitor International não é afiliada à Bacula Systems SA.

Este whitepaper é fornecido para fins informativos. As especificações estão sujeitas a alterações sem aviso prévio.

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

Deixe um comentário