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

Respaldo remoto vía SFTP sin agente. Para sistemas restringidos donde instalar agente está prohibido — appliances, switches, hosts air-gapped — captura por SSH/SFTP nativo.

Footprint cero — sin agente, sin puerto extra, usa SSH existente.
Discovery automático — recorre paths configurados vía SFTP, captura permisos y ACLs.
Incremental por mtime + checksum — solo transfiere archivos modificados.
Restore vía SFTP — devuelve al mismo path con permisos preservados.
Throttling adaptativo — no satura enlaces WAN compartidos.

Producción en 30 días, al menos 50% más barato. Trial gratuito, RPMs y DEBs firmados, soporte directo con Heitor Faria. Reemplace su licencia Veeam, Commvault o Bacula Enterprise sin romper la ventana nocturna.

Solicitar trial gratuito de 30 días →

Tabla de contenidos

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

1. Resumen ejecutivo

La infraestructura de TI moderna es heterogénea. Una empresa típica opera servidores Linux junto con switches Cisco, firewalls Juniper, appliances NAS Synology, gateways IoT Raspberry Pi, máquinas legacy AIX o Solaris y decenas de VMs en la nube distribuidas entre AWS, GCP y Azure. Respaldar todos estos activos con una única plataforma ha requerido históricamente instalar un agente de backup en cada dispositivo — imposible en equipos de red y muchos sistemas embebidos — o desplegar una maraña de trabajos cron, scripts rsync y mecanismos de transferencia ad-hoc que no ofrecen catálogo, política de retención ni una ruta de restauración confiable.

El Plugin de Backup SFTP de PodHeitor para Bacula resuelve esta fragmentación. Extiende PodHeitor Backup Edition con capacidades nativas de backup y restauración SSH/SFTP, permitiendo que cualquier dispositivo accesible por SSH — servidor, NAS, switch, router, firewall, gateway IoT o servicio en la nube — quede bajo el mismo paraguas de Bacula que ya protege el resto de la infraestructura. No se requiere instalación de software en el lado remoto. El puerto 22 es el único requisito.

El plugin está construido íntegramente en Rust, siguiendo la arquitectura oficial Metaplugin de Bacula — el mismo framework utilizado por los plugins upstream de Kubernetes y Docker. Cada paquete incluye dos componentes: una plugin FD liviana cargada por bacula-fd y un binario backend en Rust que realiza todo el I/O SSH/SFTP a través de libssh2. La separación plugin FD-backend mantiene el proceso FD estable incluso si un dispositivo de red se comporta de forma inesperada durante la transferencia. Los niveles de backup (Full, Incremental, Differential) se determinan mediante comparación estándar de mtime. Los filtros glob de inclusión/exclusión, FileSets multi-servidor, firmas SHA256, compresión LZ4/GZIP y cifrado AES provienen del conjunto de funcionalidades nativas de Bacula sin costo adicional.

La versión 2.0.0, lanzada en abril de 2026, completó una reescritura total de ambos componentes desde C++/Python heredado a Rust puro, eliminó la dependencia del runtime Python y selló ambos artefactos bajo una licencia propietaria sin dependencias estáticas con licencia AGPL. El resultado es un plugin más liviano, más rápido y completamente propietario que se integra en cualquier instalación existente de PodHeitor Backup sin necesidad de cambios de configuración en el Director.

2. Introducción y contexto de mercado

2.1 El problema del backup sin agente

El modelo de despliegue estándar de PodHeitor Backup requiere un File Daemon (FD) ejecutándose en cada host a respaldar. El FD escucha en el puerto TCP 9102, transfiere datos de archivos al Storage Daemon y mantiene metadatos para el catálogo. Este modelo funciona bien para flotas de servidores Linux o Windows homogéneas donde existen paquetes y el acceso a puertos es controlable.

Falla en cinco clases de entornos cada vez más comunes:

Equipos de red. Cisco IOS-XE, Junos, FortiOS, PAN-OS, RouterOS y sistemas operativos de red similares no admiten paquetes Linux. Estos dispositivos exponen SSH/SFTP como la única interfaz de acceso a archivos por programa. El backup de configuración — el artefacto de DR más crítico para las operaciones de red — queda fuera del alcance de Bacula estándar sin scripting externo.
Appliances NAS. Synology DSM, QNAP QTS, TrueNAS y plataformas similares ejecutan entornos Linux fuertemente personalizados donde instalar daemons de terceros no está soportado o resulta impracticable. Todos tienen SFTP/SSH nativo.
Servidores legacy y multiplataforma. Los sistemas AIX, HP-UX y Solaris pueden no disponer de paquetes actuales de Bacula FD. Servidores CentOS 5/6 aún en producción suelen carecer de un FD compatible. Cualquier sistema donde SSH sea el único mecanismo de acceso remoto viable.
Dispositivos IoT y embebidos. Gateways Raspberry Pi, PLCs industriales y dispositivos similares con almacenamiento y CPU limitados no pueden absorber la sobrecarga de un daemon persistente. El acceso SFTP es liviano y universalmente disponible.
Servicios SFTP en la nube. AWS Transfer Family, Azure Blob SFTP, Hetzner Storage Box y servicios gestionados similares exponen datos exclusivamente a través de SFTP. No se puede instalar ningún agente en el lado del servidor.

2.2 Por qué los enfoques existentes son insuficientes

Herramienta	Enfoque	Limitación
PodHeitor Backup (nativo, sin plugin)	Requiere FD en cada host	Imposible en equipos de red, NAS, servicios SFTP en la nube
Veeam	Basado en agente o sin agente vía hipervisor	Sin ruta SSH/SFTP nativa; sin soporte para dispositivos de red
Commvault	File System iDataAgent	Requiere instalación de agente; sin soporte para OS de red
NetBackup	Agente cliente	Misma limitación; propietario y costoso
rsync + cron	SSH sin agente	Sin catálogo, sin retención, sin restauración a un punto en el tiempo, sin monitoreo
Scripts scp personalizados	Copia de archivos ad-hoc	Sin versiones, sin verificación, inmanejable a escala
Puntos de montaje SSHFS	Montaje FUSE sobre SSH	Montajes obsoletos, requiere módulo kernel FUSE, llamadas stat bloqueadas que detienen el FD

2.3 El enfoque de PodHeitor

El plugin transforma PodHeitor Backup en una verdadera plataforma de backup sin agente para recursos accesibles por SSH. Un solo Bacula File Daemon, con el plugin instalado, puede respaldar un número ilimitado de sistemas remotos. El Director de Bacula, el catálogo, el pool de almacenamiento, las políticas de retención, los schedules y el flujo de restauración se aplican de forma idéntica — el plugin simplemente agrega SSH/SFTP como capa de transporte de datos.

Este enfoque es coherente con la filosofía general de plugins de PodHeitor: nativo en Rust, sin dependencias de runtime más allá de libssh2 y OpenSSL, arquitectura de canal interno otimizado para una separación limpia plugin/backend e integración completa con las funcionalidades nativas de Bacula en lugar de reimplementarlas.

3. Visión general de la arquitectura

3.1 Diseño de dos componentes

El plugin se distribuye con dos binarios en el mismo paquete:

Componente	Archivo	Función
Plugin FD de Bacula (plugin FD)	`/opt/bacula/plugins/podheitor-sftp-fd.so`	Cargado por `bacula-fd` al inicio; implementa la API de plugin de Bacula; define el namespace `@sftp`; lanza y comunica con el backend
Binario backend	`/opt/bacula/bin/podheitor-sftp-backend`	Bifurcado por trabajo (job) desde la plugin FD; realiza todo el I/O SSH/SFTP via libssh2; gestiona el recorrido de directorios, el filtrado por mtime y la transferencia de archivos

Esta separación proporciona tres ventajas clave:

Aislamiento. Todo el I/O de red y la lógica SSH viven en el backend. Un crash, bloqueo o timeout en el backend no puede corromper el proceso FD de Bacula ni afectar otros trabajos concurrentes.
Actualización sencilla. El binario backend puede reemplazarse sin reiniciar bacula-fd, ya que solo la plugin FD toca el ABI del plugin de Bacula.
Facilidad de prueba. El backend puede ejecutarse directamente en pruebas de integración sin involucrar a Bacula en absoluto — el comportamiento SSH, la lógica de inclusión/exclusión y el encuadre canal interno son todos verificables de forma independiente.

3.4 Separación de responsabilidades

podheitor-sftp-fd.so (Rust plugin FD)	podheitor-sftp-backend (Rust binary)
Registro y ciclo de vida del FD	SSH/SFTP via libssh2
Puente canal interno a callbacks del FD	Recorrido recursivo de directorios
Definición del namespace @sftp	Lectura de archivos y fragmentación de datos
Sin lógica SFTP — ~600 LOC	Comparación incremental basada en mtime
Framework framework de plugin PodHeitor	Filtrado glob de inclusión/exclusión
Superficie ABI de Bacula	Protocolo canal interno completo — ~1500 LOC

3.5 Flujo de datos — backup incremental

 FD Plugin (.so)          Backend (Rust)           SFTP Server
     │                         │                        │
  1. │── Hello podheitor ─────▶│                        │
     │◀── Hello Bacula ────────│                        │
     │                         │                        │
  2. │── Level=Incremental ───▶│                        │
     │── Since=<timestamp> ───▶│                        │
     │── EOD ─────────────────▶│                        │
     │                         │                        │
  3. │── host=server ─────────▶│                        │
     │── user=backup ─────────▶│                        │
     │── keyfile=/path/key ───▶│                        │
     │── path=/data ──────────▶│                        │
     │── include=*.pdf ───────▶│                        │
     │── exclude=*.tmp ───────▶│                        │
     │── EOD ─────────────────▶│                        │
     │                         │                        │
  4. │── BackupStart ─────────▶│                        │
     │                         │── SSH Connect ────────▶│
     │                         │◀── Auth OK ────────────│
     │                         │── SFTP Open Channel ──▶│
     │                         │                        │
  5. │                         │── listdir /data ──────▶│
     │                         │◀── [files + mtimes] ───│
     │                         │   (skip mtime < Since) │
     │◀── FNAME/@sftp/.../f2 ─│                        │
     │◀── STAT:F 2048 ...    ─│                        │
     │◀── DATA [chunks] ──────│◀── read file2 ─────────│
     │◀── EOD (end data) ─────│                        │
     │                         │                        │
  6. │◀── EOD (end files) ────│                        │
     │── TERM ────────────────▶│── Close SFTP ─────────▶│

4. Modos de backup en detalle

4.1 Backup Full

Un backup Full transfiere todos los archivos y directorios bajo el path configurado, independientemente de la fecha de modificación. El backend se conecta al servidor SFTP, realiza un recorrido recursivo de directorios y envía cada archivo al plugin FD mediante paquetes canal interno DATA.

Since = 0 (all timestamps included)

/data/
├── report.pdf          ──▶ TRANSFER
├── spreadsheet.xlsx    ──▶ TRANSFER
├── notes.txt           ──▶ TRANSFER
└── archive/
    ├── 2024-q1.pdf     ──▶ TRANSFER
    └── 2024-q2.pdf     ──▶ TRANSFER

Total: ALL files

Un backup Full es autónomo — puede restaurarse sin ningún otro conjunto de backup. Los backups Full son el punto de partida recomendado para todos los schedules y deben ejecutarse como mínimo semanalmente en la mayoría de los entornos.

4.2 Backup Incremental

Un backup Incremental transfiere únicamente los archivos cuyo mtime (marca de tiempo de modificación) es mayor o igual al timestamp del backup más reciente — ya sea un Full, Differential o un Incremental anterior.

Since = <timestamp of last backup>

/data/
├── report.pdf   (mtime: before Since) ──▶ SKIP
├── draft.pdf    (mtime: after Since)  ──▶ TRANSFER
├── notes.txt    (mtime: before Since) ──▶ SKIP
└── archive/                           ──▶ ALWAYS traversed (dirs)
    ├── 2024-q1.pdf (mtime: before)    ──▶ SKIP
    └── 2025-q1.pdf (mtime: after)     ──▶ TRANSFER

Total: only CHANGED files

Los Incrementales son los más pequeños y rápidos. La contrapartida es que una restauración requiere el backup Full más cada Incremental de la cadena. Para la mayoría de los casos de uso SFTP (archivos de configuración, documentos, datos NAS), las tasas de cambio de archivos son bajas y las cadenas Incrementales permanecen cortas.

4.3 Backup Differential

Un backup Differential transfiere todos los archivos modificados desde el último backup Full, ignorando cualquier Incremental intermedio. Cada Differential es por tanto más grande que un Incremental pero más pequeño que un Full.

Restore from Differential:
  Full (Day 1) + Differential (Day 4) = 2 volumes only

Restore from Incremental chain:
  Full (Day 1) + Incr (Day 2) + Incr (Day 3) + Incr (Day 4) = 4 volumes

Los Differentials son especialmente útiles para backups de configuración de equipos de red donde la frecuencia de cambios es baja, pero el corpus total de configuración es pequeño y se prefiere una ruta de restauración más simple.

4.4 Comparación de niveles de backup

Nivel	Qué se transfiere	Restauración requiere	Ideal para
Full	Todos los archivos	Solo este volumen	Ancla semanal; primer backup
Incremental	Archivos modificados desde el último backup (cualquier nivel)	Full + todos los Incrementales	Backups diarios; destinos SFTP de bajo cambio
Differential	Archivos modificados desde el último Full	Full + este Differential	Configuraciones de red; ruta de restauración simple

4.5 Filtrado de inclusión/exclusión

Antes de transferir cualquier archivo, el backend aplica filtros glob de inclusión y exclusión comparados contra el nombre del archivo (no la ruta completa). El orden de evaluación es: exclusión primero, luego inclusión.

Parámetro	Sintaxis	Efecto
`include`	Patrones glob separados por comas	Solo se transfieren los archivos que coincidan con al menos un patrón. Los directorios siempre se recorren.
`exclude`	Patrones glob separados por comas	Los archivos y directorios que coincidan con algún patrón se omiten.

Cuando se especifica include, todos los archivos que no coincidan con ningún patrón de inclusión se omiten silenciosamente. Este es el enfoque recomendado para backups de configuración de equipos de red donde solo importan los archivos *.conf, *.cfg, *.backup o *.rsc.

5. Matriz de funcionalidades

Funcionalidad	Soportado	Notas
Backup sin agente (solo SSH)	Sí	Sin instalación de software en el host remoto
Backup Full	Sí	Todos los archivos bajo el path configurado
Backup Incremental	Sí	Comparación basada en mtime
Backup Differential	Sí	mtime desde el último Full
Autenticación SSH por clave (ed25519)	Sí	Recomendado para producción
Autenticación SSH por clave (RSA, ECDSA)	Sí	Tipos de clave legacy
Autenticación SSH por contraseña	Sí	No recomendado para producción
Reenvío de agente SSH	Sí	Se integra con ssh-agent del sistema
Verificación de clave de host (known_hosts)	Sí	Protección MITM; habilitado por defecto
Puerto SSH personalizado	Sí	Parámetro port=; defecto 22
Timeout de conexión personalizado	Sí	timeout= en segundos; defecto 30
Filtros glob de inclusión	Sí	Glob POSIX; separados por comas
Filtros glob de exclusión	Sí	Glob POSIX; separados por comas
Metadatos preservados (permisos, UID/GID, timestamps)	Sí	Restaurados al FS local
Manejo de enlaces simbólicos	Sí	Symlinks catalogados como tipo S
Múltiples servidores SFTP en un FileSet	Sí	N líneas Plugin= en el bloque Include
Firmas SHA256 de archivos	Sí	Opciones nativas de Bacula
Compresión LZ4 / GZIP	Sí	Opciones nativas de Bacula
Cifrado AES	Sí	Opciones nativas de Bacula
Listado previo de archivos (estimación)	Sí	estimate job=… listing
Consulta de catálogo post-backup	Sí	list files jobid=X
Navegación interactiva del árbol de restauración	Sí	restore → cd/ls/mark
Restauración selectiva de archivos	Sí	marcar archivos individuales en bconsole
Cancelar ante error de archivo	Sí	Parámetro abort_on_error=
Registro de debug	Sí	Variable de entorno PODHEITOR_DEBUG=1
Paquete RPM (RHEL/OL/Rocky 9)	Sí	Instalación con un solo comando
PKGBUILD para Arch Linux	Sí	makepkg -si
Compilación desde fuente	Sí
Objetivo Windows OpenSSH Server	Sí	OpenSSH nativo en Windows 10/11/Server 2019+
Objetivos de equipos de red (Cisco, Juniper, MikroTik, etc.)	Sí	Cualquier dispositivo con SSH/SFTP
Soporte para archivos grandes (> 1 GB)	Sí	Transmisión en bloques de 64 KB; sin límite de tamaño

6. Guía de instalación

6.1 Requisitos previos

PodHeitor Backup o posterior instalado con bacula-fd en ejecución
Plugin Directory configurado en bacula-fd.conf (típicamente /opt/bacula/plugins)
Librerías de runtime: libssh2 y openssl (paquetes del sistema)
Par de claves SSH generado para operaciones de backup (se recomienda ed25519)
Acceso de lectura concedido al usuario SSH en todas las rutas remotas a respaldar

6.2 Instalación RPM (RHEL / Oracle Linux / Rocky Linux 9)

# 1. Install runtime dependencies
sudo dnf install libssh2 openssl-libs

# 2. Install the plugin RPM
sudo rpm -ivh podheitor-sftp-fd-plugin-2.0.0-1.el9.x86_64.rpm

# 3. Verify installed files
ls -l /opt/bacula/plugins/podheitor-sftp-fd.so
ls -l /opt/bacula/bin/podheitor-sftp-backend

# 4. Confirm libssh2 is reachable
ldconfig -p | grep libssh2

# 5. Restart FD to load the plugin
sudo systemctl restart bacula-fd

# 6. Confirm the plugin loaded
echo "status client" | bconsole | grep -i podheitor
# Expected: Plugin: podheitor-sftp-fd.so

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

# 1. Install runtime dependencies
sudo apt install libssh2-1 openssl

# 2. Install the DEB package
sudo dpkg -i podheitor-sftp-fd-plugin_2.0.0-1_amd64.deb

# 3. Verify installed files
ls -l /opt/bacula/plugins/podheitor-sftp-fd.so
ls -l /opt/bacula/bin/podheitor-sftp-backend

# 4. Restart FD
sudo systemctl restart bacula-fd

6.4 Configuración del directorio del plugin en el FD

Asegúrese de que bacula-fd.conf apunte al directorio correcto:

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

6.5 Configuración de clave SSH

# Generate a dedicated ed25519 key for Bacula (no passphrase for automation)
sudo mkdir -p /etc/bacula/.ssh
sudo ssh-keygen -t ed25519 -f /etc/bacula/.ssh/id_ed25519 -N "" -C "bacula-backup"

# Set secure permissions
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

# Copy public key to remote server
sudo ssh-copy-id -i /etc/bacula/.ssh/id_ed25519.pub backup@server.local

# Pre-populate known_hosts for host key verification
sudo ssh-keyscan -H server.local | sudo tee -a /etc/bacula/.ssh/known_hosts

7. Referencia de configuración

7.1 Cadena de parámetros del plugin

Plugin = "podheitor-sftp: <param1>=<value1> <param2>=<value2> ..."

7.2 Referencia de parámetros

Parámetro	Requerido	Defecto	Tipo	Descripción
`host`	Sí	—	string	Nombre de host o dirección IP del servidor SFTP
`port`	No	`22`	int	Número de puerto SSH/SFTP
`user`	Sí	—	string	Nombre de usuario SSH en el servidor remoto
`password`	No	—	string	Contraseña SSH (se prefiere keyfile)
`keyfile`	No	—	string	Ruta al archivo de clave privada SSH
`passphrase`	No	—	string	Frase de paso para clave privada cifrada
`path`	Sí	`/`	string	Directorio base remoto a respaldar
`known_hosts`	No	—	string	Ruta al archivo SSH known_hosts
`verify_host`	No	`yes`	bool	Verificar clave de host SSH (protección MITM)
`timeout`	No	`30`	int	Timeout de conexión en segundos
`include`	No	—	string	Patrones glob de inclusión separados por comas (ej. `.pdf,.docx`)
`exclude`	No	—	string	Patrones glob de exclusión separados por comas (ej. `.tmp,.log`)
`abort_on_error`	No	`no`	bool	Cancelar trabajo ante error de lectura de archivo

7.3 Configuración mínima de FileSet

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

7.4 Configuración completa con todas las opciones

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

Job {
  Name = "SFTP-Documents-Backup"
  Type = Backup
  Level = Incremental
  Client = mybacula-fd
  FileSet = "SFTP-Full"
  Schedule = "SFTP-WeeklyCycle"
  Storage = File1
  Pool = Default
  Messages = Standard
  Priority = 10
}

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

7.5 Trabajo de restauración

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

8. Ejemplos de FileSet

8.1 Backup de carpeta compartida 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 configuración de equipos de red

FileSet {
  Name = "Network-Equipment-Configs"
  Include {
    Options { Signature = SHA256 }
    # Cisco Catalyst — running-config only
    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 — /config directory
    Plugin = "podheitor-sftp: host=10.0.0.2 user=backup keyfile=/etc/bacula/.ssh/net_key path=/config verify_host=no"
    # MikroTik RouterOS — backup and export files
    Plugin = "podheitor-sftp: host=10.0.0.3 user=admin keyfile=/etc/bacula/.ssh/net_key path=/ include=*.backup,*.rsc verify_host=no"
    # FortiGate — config backup
    Plugin = "podheitor-sftp: host=10.0.0.4 user=admin keyfile=/etc/bacula/.ssh/net_key path=/ include=*.conf verify_host=no"
  }
}

Schedule {
  Name = "Network-Daily"
  Run = Full daily at 02:00
}

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

8.3 Múltiples servidores web

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

8.4 Servicios SFTP en la nube

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

8.5 Sistemas IoT y legacy

FileSet {
  Name = "IoT-And-Legacy"
  Include {
    Options { Signature = SHA256 }
    # Raspberry Pi IoT gateway
    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"
    # AIX legacy server
    Plugin = "podheitor-sftp: host=aix-prod.local user=root keyfile=/etc/bacula/.ssh/legacy_key path=/etc"
    # Solaris server
    Plugin = "podheitor-sftp: host=solaris.local user=root keyfile=/etc/bacula/.ssh/legacy_key path=/export/home"
  }
}

9. Dimensionamiento y planificación de capacidad

9.1 Estimación del tamaño del backup

Use estimate en bconsole antes de comprometerse con un schedule:

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

Esto se conecta al servidor SFTP, recorre el árbol de directorios aplicando todos los filtros de inclusión/exclusión e informa el número de archivos y el tamaño estimado — sin transferir ningún dato:

@sftp/fileserver.local:22/data/report.pdf              1,234,567
@sftp/fileserver.local:22/data/spreadsheet.xlsx           456,789
@sftp/fileserver.local:22/data/images/photo1.jpg        2,345,678
...
2,000 files found, estimated size: 1.2 GB

9.2 Requisitos de almacenamiento

Tipo de backup	Tamaño típico relativo al Full	Recomendación de retención
Full	100%	4 semanas (rotación mensual)
Differential	5–40% del Full	Conservar los últimos 7 Differentials
Incremental	0.1–5% del Full por día	Conservar los últimos 30 Incrementales

Para configuraciones de equipos de red, el corpus total es típicamente inferior a 10 MB por dispositivo, lo que hace que los backups Full diarios tengan un costo de almacenamiento despreciable. Para grandes volúmenes NAS o repositorios SFTP en la nube, habilite la compresión LZ4 (típicamente 30–60% de reducción de tamaño para archivos de texto y documentos) y establezca ventanas de retención apropiadas en el Pool.

9.3 Planificación del ancho de banda de red

El plugin transmite los datos de archivos directamente desde el servidor SFTP hacia Bacula Storage. Los requisitos de ancho de banda de red dependen de:

Tamaño del backup Full — el primer Full establece la carga de red de referencia
Tasa de cambio diaria — el tamaño Incremental determina el ancho de banda diario continuo
Ventana de transferencia — los backups deben completarse antes de la próxima ejecución programada

Para entornos con restricciones (enlaces WAN, conexiones con medición de datos), programe los backups Full en horas de baja actividad y use Incrementales para las ejecuciones diarias. El parámetro timeout= debe configurarse en al menos 2× el tiempo esperado para transferir el archivo individual más grande con el ancho de banda disponible.

9.4 Impacto en el catálogo

Cada archivo respaldado genera un registro en el catálogo. Para FileSets con cientos de miles de archivos pequeños (ej., /var/www de un servidor web), el crecimiento del catálogo puede ser significativo. Aplique filtros exclude de forma agresiva para omitir archivos efímeros (*.log, *.tmp, *.cache, node_modules) que no necesitan backup y que de otro modo inflarían el catálogo.

10. Consideraciones de rendimiento

10.1 Sobrecarga de la conexión SSH

Cada invocación del plugin (una por línea Plugin = en el FileSet) establece una conexión SSH durante la duración del trabajo. El intercambio de claves y la autenticación típicamente se completan en menos de 200 ms en una LAN. Para destinos WAN, el parámetro timeout= controla la espera máxima para la conexión inicial; las operaciones subsiguientes a nivel de archivo usan timeouts por operación heredados de libssh2.

10.2 Velocidad de recorrido de directorios

El backend realiza un recorrido recursivo de directorios SFTP utilizando sftp_readdir de libssh2. En una LAN típica, el recorrido procesa aproximadamente 1.000–5.000 entradas por segundo dependiendo de la profundidad del directorio y la latencia de red. Para FileSets con árboles de directorios profundos, habilite patrones exclude para podar subárboles tempranamente (ej., exclude=node_modules,.git,__pycache__).

10.3 throughput de transferencia de archivos

Los datos de archivos se transfieren en bloques de 64 KB sobre el canal SFTP. El throughput efectivo está limitado por la sobrecarga del cifrado SSH y el ancho de banda de red disponible. En condiciones LAN (1 Gbps), espere 50–200 MB/s dependiendo de la velocidad del CPU y el tamaño de los archivos. Para archivos pequeños (archivos de configuración menores a 1 KB), el throughput está limitado por IOPS en lugar de ancho de banda; use filtros include para limitar las transferencias solo a los archivos necesarios.

10.4 Múltiples servidores en paralelo

Las múltiples líneas Plugin = en un único FileSet se procesan secuencialmente dentro de un trabajo de Bacula. Para respaldar múltiples servidores grandes en paralelo, cree trabajos de Bacula separados con su propio FileSet y prográmelos para ejecutarse de forma concurrente. Las directivas Maximum Concurrent Jobs y Priority de Bacula controlan el paralelismo.

11. Matriz de compatibilidad

11.1 Host del Bacula File Daemon (donde se ejecuta el plugin)

Plataforma	Arquitectura	Estado
RHEL / Rocky / Oracle Linux 8–9	x86_64, aarch64	Probado
Debian 12 (Bookworm)	x86_64, aarch64	Probado
Ubuntu 22.04 / 24.04 LTS	x86_64, aarch64	Esperado
SUSE / openSUSE 15	x86_64	Esperado
Arch Linux	x86_64	PKGBUILD disponible
FreeBSD 13+	amd64	Sin prueba (requiere gmake)

11.2 Destinos SFTP remotos (qué puede respaldarse)

Categoría	Ejemplos	Notas
Servidores Linux	Cualquier distribución con OpenSSH	Acceso completo al sistema de archivos
Servidores Windows	Windows 10/11, Server 2019+	Requiere OpenSSH Server nativo
macOS	macOS 10.15+	Habilitar Inicio de Sesión Remoto en Preferencias del Sistema
BSD	FreeBSD, OpenBSD, NetBSD	OpenSSH nativo
Appliances NAS	Synology DSM, QNAP QTS, TrueNAS	Habilitar SFTP/SSH en la configuración del NAS
Cisco	Catalyst 9000 (IOS-XE), Nexus (NX-OS), ISR/ASR	SSH/SFTP debe estar habilitado
Juniper	EX, QFX, SRX, MX (Junos)	SSH/SFTP nativo en Junos
MikroTik	Todos los dispositivos RouterOS	SFTP nativo
Arista	7000, 7500 (EOS)	SSH/SFTP nativo
Fortinet	FortiGate (FortiOS)	SFTP debe habilitarse en la interfaz de gestión
Palo Alto	Serie PA (PAN-OS)	SSH/SFTP vía plano de gestión
HPE Aruba	Switches CX, Instant AP	SSH nativo
Ubiquiti	UniFi, EdgeRouter	SSH nativo
VyOS / OPNsense / pfSense	Firewalls comunitarios/abiertos	SSH nativo
AWS Transfer Family	Endpoints SFTP gestionados	Solo autenticación por clave
Azure Blob SFTP	Acceso SFTP a Azure Storage	Clave requerida; función preview/GA
Hetzner Storage Box	SFTP nativo (puerto 23)	Requiere port= personalizado
Raspberry Pi / IoT	OpenWrt, DietPi, Raspberry Pi OS	Liviano; usar timeout=15
Unix legacy	AIX, HP-UX, Solaris	Cualquier versión con OpenSSH

11.3 Versión mínima de Bacula

Se requiere PodHeitor Backup o superior para el framework Metaplugin sobre el que se construye el plugin. Las versiones anteriores no están soportadas. El plugin ha sido probado con Bacula 13.x y 15.x.

12. Seguridad

12.1 Mejores prácticas de autenticación

Práctica	Descripción
Use claves SSH, nunca contraseñas	Las contraseñas en la configuración de Bacula se almacenan en texto plano; las claves SSH nunca se transmiten
Use claves ed25519	Algoritmo moderno; tamaño de clave pequeño; resistente a ataques de canal lateral
Par de claves exclusivo para backup	Genere una clave exclusivamente para Bacula; nunca reutilice claves personales o de administrador
Restrinja permisos de clave	`chmod 640` en el archivo de clave privada; propiedad de root:bacula
Usuario SSH dedicado en el remoto	Cree un usuario `backup` con acceso de solo lectura a las rutas de backup
ACLs de solo lectura	El usuario de backup no debe tener acceso de escritura — una brecha en el servidor Bacula no puede modificar datos remotos
Habilitar verify_host=yes	Siempre verifique las claves de host en producción; pre-popule known_hosts antes del primer backup
Archivo known_hosts separado	Use `/etc/bacula/.ssh/known_hosts` en lugar del known_hosts personal de root
Firewall solo al puerto 22	Permita únicamente TCP 22 entre el host FD y los destinos SFTP; bloquee todos los demás puertos

12.2 Flujo de verificación de clave de host

verify_host=yes (DEFAULT — RECOMMENDED for production)
  ├── Load known_hosts file (if configured)
  ├── If host key NOT in known_hosts → ERROR: connection refused
  └── If host key in known_hosts → compare fingerprint → OK or ERROR

verify_host=no (LAB / testing ONLY)
  ├── AutoAddPolicy — accepts any host key on first connection
  └── WARNING: Vulnerable to Man-in-the-Middle attacks

12.3 Almacenamiento de credenciales

Los archivos de clave privada SSH referenciados por keyfile= permanecen en el sistema de archivos del host Bacula FD y nunca se transmiten a servidores remotos — solo la clave pública se usa para autenticación. La clave privada debe almacenarse en un directorio legible únicamente por el proceso FD de Bacula (típicamente root o el usuario bacula). Si el archivo de configuración del Director de Bacula es legible por todos, use claves SSH en lugar del parámetro password=, que almacena credenciales en texto plano en la configuración del Director.

12.4 Seguridad del transporte

Toda la transferencia de datos ocurre sobre el canal cifrado SSH. El protocolo SSH (a través de libssh2) negocia el conjunto de cifrado durante el intercambio de claves; los valores predeterminados modernos de OpenSSH usan ChaCha20-Poly1305 o AES-256-GCM. Para cifrado adicional en reposo en Bacula Storage, habilite el cifrado AES en el bloque Options del FileSet — esto es independiente de y adicional al cifrado de transporte SSH.

13. Monitoreo

13.1 Monitoreo estándar de trabajos de Bacula

El plugin se integra completamente con la infraestructura de monitoreo integrada de Bacula. Todos los resultados de trabajos aparecen en el registro de mensajes de Bacula y se entregan al recurso Messages configurado (email, syslog, archivo):

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

13.2 Verificación de listado de archivos

Después de un backup completado, verifique que los archivos esperados fueron catalogados:

* list files jobid=42
+----------------------------------------------------------+
| filename                                                 |
+----------------------------------------------------------+
| @sftp/fileserver.local:22/data/                          |
| @sftp/fileserver.local:22/data/report.pdf                |
| @sftp/fileserver.local:22/data/spreadsheet.xlsx          |
+----------------------------------------------------------+

13.3 Resumen de métodos de listado de archivos

Método	Cuándo	Comando	¿Requiere backup?
Estimación pre-backup	Antes del backup — recorrido SFTP en vivo	`estimate job=... level=Full listing`	No
Catálogo post-backup	Después del backup — consulta del catálogo	`list files jobid=X`	Sí
Árbol de restauración interactivo	Durante la restauración — navegar desde el catálogo	`restore → cd/ls`	Sí

13.4 Habilitación del registro de debug

# RHEL / Oracle Linux — add to /etc/sysconfig/bacula-fd
PODHEITOR_DEBUG=1

# Debian / Ubuntu — add to /etc/default/bacula-fd
PODHEITOR_DEBUG=1

# Then restart FD
sudo systemctl restart bacula-fd

Los registros del backend (stderr) son capturados por el FD y aparecen directamente en los mensajes del trabajo de Bacula. Cada operación SFTP, decisión de comparación mtime y resultado de filtro de inclusión/exclusión se registra cuando PODHEITOR_DEBUG=1 está configurado.

14. Guía de resolución de problemas

14.1 Problemas comunes y soluciones

Síntoma	Causa probable	Solución
`Command plugin not found`	`.so` no está en Plugin Directory	Verifique que `/opt/bacula/plugins/podheitor-sftp-fd.so` existe; reinicie el FD
`Unable to use backend`	Binario backend faltante o sin permiso de ejecución	Verifique `/opt/bacula/bin/podheitor-sftp-backend` con `chmod +x`
`SSH auth failed`	Clave SSH inválida o usuario incorrecto	Pruebe: `sudo ssh -i /path/key user@host`
`Permission denied` en archivos	El usuario SSH carece de acceso de lectura	`setfacl -R -m u:backup:rX /data` en el servidor remoto
Backend bloqueado / timeout	Problema de red o firewall	Pruebe: `nc -zv host 22`; aumente `timeout=60`
`libssh2 not found`	Librería de runtime faltante	`apt install libssh2-1` o `dnf install libssh2`
`Host key verification failed`	Clave de host no está en known_hosts	Ejecute `ssh-keyscan host >> /etc/bacula/.ssh/known_hosts`
El trabajo se ejecuta pero respalda 0 archivos	`path` incorrecto o directorio vacío	Verifique la ruta remota: `sftp user@host; ls /data`
0 archivos con include configurado	Patrón de inclusión demasiado restrictivo	Verifique los patrones: `include=*.pdf` solo coincide con archivos `.pdf` exactamente
Incrementales respaldando todos los archivos	Timestamps mtime incorrectos en el remoto	Verifique sincronización de reloj (NTP) en el host remoto; considere schedule Full

14.2 Secuencia de prueba de conectividad manual

# 1. TCP reachability
nc -zv server.local 22

# 2. SSH authentication test (run as root — same as FD)
sudo ssh -i /etc/bacula/.ssh/id_ed25519 -o BatchMode=yes backup@server.local echo OK

# 3. SFTP directory listing test
sudo sftp -i /etc/bacula/.ssh/id_ed25519 backup@server.local <<< "ls /data"

# 4. Host key test (confirm known_hosts entry)
ssh-keygen -F server.local -f /etc/bacula/.ssh/known_hosts

14.3 Verificación de carga del plugin

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

14.4 Ubicaciones de registros

Componente	Ubicación del registro
Bacula Director	`/opt/bacula/log/bacula.log`
Bacula FD	`/opt/bacula/log/bacula.log`
Salida de debug del backend	Stderr capturado por el FD, aparece en los mensajes del trabajo
Journal systemd del FD	`journalctl -u bacula-fd`

15. Casos de uso y escenarios de despliegue

15.1 Backup de infraestructura de red empresarial

Una institución financiera opera 120 dispositivos de red en tres centros de datos: switches core Cisco Catalyst 9300, firewalls Juniper SRX, routers de borde MikroTik y firewalls perimetrales Fortinet FortiGate. El equipo de red ejecutaba históricamente transferencias TFTP/SCP ad-hoc a una carpeta compartida — sin versiones, sin retención, sin proceso de restauración.

Con el Plugin SFTP de PodHeitor, toda la flota de dispositivos de red se integra en la infraestructura Bacula existente. Cada tipo de dispositivo se mapea a un FileSet específico con patrones de inclusión apropiados (*.conf, *.backup, *.rsc). Los backups Full diarios se ejecutan a las 02:00 con un pool de retención de 30 días. El equipo de operaciones puede restaurar la configuración de cualquier dispositivo a cualquier punto del último mes mediante los comandos estándar restore de bconsole. Corpus total de backup: menos de 50 MB por ejecución diaria entre los 120 dispositivos.

15.2 Backup consolidado de NAS

Una empresa manufacturera opera cuatro appliances NAS — dos unidades Synology DiskStation y dos dispositivos QNAP NAS — distribuidos entre el piso de fábrica y entornos de oficina. Cada NAS almacena archivos CAD, reportes de producción y archivos de escaneo. La instalación de FDs de Bacula en estos appliances no está soportada por el fabricante.

El Plugin SFTP de PodHeitor respalda los cuatro volúmenes NAS desde un único host Bacula FD ubicado en la sala de servidores. Los backups Incrementales se ejecutan nocturnamente; los backups Full se ejecutan cada domingo. El filtro exclude=*.tmp,*.part elimina cargas incompletas. La restauración de archivos individuales se realiza mediante la navegación interactiva del árbol en bconsole, que mapea directamente al namespace @sftp/nashost:22/volume1/path.

15.3 Backup sin agente de VMs en la nube

Un proveedor SaaS ejecuta 40 VMs de aplicaciones en AWS EC2 y GCP Compute Engine. Instalar y gestionar paquetes Bacula FD en toda esta flota, con rotación de claves IAM, reglas de security groups y cadencia de actualización del agente, representaba una carga operacional significativa.

El Plugin SFTP de PodHeitor elimina el agente por VM. El directorio de datos de la aplicación de cada VM se respalda mediante un único par de claves SSH compartido en toda la flota. Los backups Incrementales se ejecutan cada 6 horas, capturando únicamente el estado cambiado de la aplicación. El par de claves AWS se almacena en /etc/bacula/.ssh/aws_key con permisos 640. Infraestructura Bacula total: un host FD con el plugin, un Storage Daemon, un Director.

15.4 Integración de sistemas legacy

Un proveedor de salud ejecuta software crítico de programación de pacientes en un servidor Solaris 10 y un servidor AIX 7.2 que son anteriores a los paquetes actuales de Bacula FD. El riesgo de tocar estos sistemas con nuevas instalaciones de software es considerado inaceptable por el equipo de cumplimiento.

El Plugin SFTP de PodHeitor respalda ambos servidores sin ninguna instalación: el plugin se conecta a través de sus servidores OpenSSH existentes, respalda /export/home y /var/lib/app respectivamente e integra el resto de la infraestructura Bacula de la organización. Los servidores legacy permanecen intactos. La restauración se realiza en un entorno de staging para verificación antes de la recuperación en producción.

15.5 Gestión de configuración IoT

Una empresa energética despliega 200 gateways Raspberry Pi en subestaciones eléctricas. Cada gateway ejecuta software de monitoreo personalizado cuyos archivos de configuración representan meses de trabajo de calibración en campo. La pérdida de configuración requiere recalibración manual en cada sitio.

El Plugin SFTP de PodHeitor respalda /etc y /opt/monitor/config de cada gateway diariamente. El parámetro timeout=15 acomoda respuestas SSH más lentas de los gateways. Los filtros de inclusión limitan el alcance del backup a solo archivos de configuración, manteniendo el backup de cada gateway en menos de 5 MB. Toda la flota de 200 gateways se respalda en menos de 30 minutos desde un único host Bacula FD sobre la WAN MPLS de la empresa.

16. Comparación con otros enfoques

16.1 Plugin SFTP de PodHeitor vs rsync + cron

Capacidad	Plugin SFTP de PodHeitor	rsync + cron
Integración con catálogo Bacula	Sí — registro completo en catálogo	No — herramienta externa
Restauración a punto en el tiempo	Sí — cualquier trabajo en el catálogo	No — solo el último rsync
Backup Incremental	Sí — mtime vía niveles de Bacula	Parcial — rsync –link-dest
Políticas de retención	Sí — retención de Pool en Bacula	No — limpieza manual
Múltiples destinos de almacenamiento	Sí — Bacula Storage Daemon	No — solo disco local
Cinta / almacenamiento en la nube	Sí — vía Storage Daemon	No
Monitoreo y alertas	Sí — Bacula Messages	Manual (email de cron)
Árbol de restauración interactivo	Sí — restore en bconsole	No — navegación manual del FS
Multi-servidor en un trabajo	Sí — N líneas Plugin=	No — N scripts separados
Integridad SHA256 de archivos	Sí — Bacula Options	No
Cifrado en reposo	Sí — AES vía Bacula	No — archivos en texto plano

16.2 Plugin SFTP de PodHeitor vs puntos de montaje SSHFS

Aspecto	Plugin SFTP de PodHeitor	Montaje SSHFS
Riesgo de montaje obsoleto	No — conexión nueva por trabajo	Sí — los montajes se vuelven obsoletos y fallan silenciosamente
Dependencia del kernel	No — espacio de usuario puro (libssh2)	Sí — requiere módulo kernel FUSE
Riesgo de FD bloqueado	No — timeout SFTP por operación	Sí — llamadas stat bloqueadas detienen el daemon
Soporte para equipos de red	Sí — SSH nativo en switches/routers	No — no puede montar sistemas de archivos de OS de red
Superficie de seguridad	Mínima — limitada solo a path=	Mayor — el montaje completo expone el FS al host FD
Complejidad de firewall	Puerto 22 único	Puerto 22 más sobrecarga FUSE/NFS
Gestión de credenciales	En la configuración de Bacula (cifrado en reposo)	En /etc/fstab o archivos de montaje systemd

16.3 Plugin SFTP de PodHeitor vs Veeam / Commvault / NetBackup

Aspecto	Plugin SFTP de PodHeitor + Bacula	Plataformas comerciales
Backup de equipos de red	Sí — SSH/SFTP nativo	Sin soporte nativo; soluciones mediante scripts
Backup NAS sin agente	Sí — solo SSH	Limitado; conectores específicos por fabricante
Unix legacy (AIX, Solaris)	Sí — solo SSH	Requiere agente; versiones antiguas del agente
Servicios SFTP en la nube	Sí — conexión SFTP directa	No soportado de forma nativa
Costo de licenciamiento	Fracción del costo comercial	Precios por socket o por TB
Infraestructura abierta	Sí — PodHeitor Backup	Dependencia del fabricante

17. Hoja de ruta

Las siguientes capacidades están planificadas o en investigación para versiones futuras:

Hooks pre/post-backup. Ejecutar comandos arbitrarios en el host remoto vía SSH antes y después del recorrido SFTP (ej., vaciar buffers de escritura de la aplicación, rotar archivos de log).
Parámetro de throttle de ancho de banda. Limitar la tasa de transferencia SFTP (KB/s) para evitar saturar enlaces WAN durante el horario laboral — coherente con el soporte de throttle disponible en otros plugins de PodHeitor.
Recorridos de directorios paralelos. Recorrer múltiples subdirectorios de nivel superior de forma concurrente dentro de una sola invocación del plugin, reduciendo el tiempo total de recorrido para árboles de directorios profundos.
Endpoint de métricas Prometheus. Exponer por trabajo los bytes transferidos, conteos de archivos, latencia de conexión y conteos de errores en un endpoint HTTP configurable — alineado con la integración de monitoreo disponible en otros plugins de PodHeitor.
Paquete DEB en repositorio upstream. Paquetes DEB precompilados para Debian 12 y Ubuntu 22.04/24.04 distribuidos a través del repositorio APT de PodHeitor.
Mejoras para destino Windows remoto. Manejo mejorado de metadatos NTFS de Windows (ACLs, flujos de datos alternativos) al respaldar destinos Windows OpenSSH Server.

18. Conclusión

El Plugin de Backup SFTP de PodHeitor para Bacula ofrece lo que ninguna plataforma de backup de código abierto estándar ha proporcionado antes: una solución de backup sin agente, de nivel productivo, integrada con catálogo, para cualquier dispositivo accesible por SSH. Desde switches de red empresariales hasta servicios SFTP en la nube, desde servidores AIX legacy hasta gateways IoT, desde appliances NAS hasta entornos de hosting web — si el dispositivo habla SSH, ahora puede ser parte de la misma infraestructura Bacula que protege el resto de la organización.

La implementación nativa en Rust del plugin, la separación limpia plugin/backend, la eliminación de la dependencia Python (v2.0.0+) y la integración completa con las funcionalidades nativas de Bacula (scheduling, retención, catálogo, compresión, cifrado, monitoreo) lo convierten en la integración de backup SSH/SFTP sin agente más completa disponible para PodHeitor Backup Edition. La comparación con scripts rsync, montajes SSHFS y plataformas comerciales deja en claro que el plugin cierra una brecha real y hasta ahora no resuelta en el ecosistema de backup de código abierto.

Para organizaciones que ya ejecutan PodHeitor Backup, la ruta de migración es una única instalación RPM o DEB y tres líneas de configuración en el FileSet. Para organizaciones evaluando plataformas de backup, la combinación de PodHeitor Backup y los plugins de PodHeitor ofrece cobertura de nivel empresarial a una fracción del costo de las alternativas comerciales — sin dependencia de ningún fabricante y con control total sobre los datos y la infraestructura.

Licenciamiento

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

¿Listo para evaluar?

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

19. Información de contacto

Canal	Detalles
Sitio web	https://podheitor.com
Email	heitor@opentechs.lat
WhatsApp / Teléfono	+1 786 726-1749 \| +55 61 98268-4220
LinkedIn	https://linkedin.com/company/podheitor

Para consultas de licenciamiento, acuerdos de soporte empresarial o solicitudes de desarrollo personalizado, contacte directamente a heitor@opentechs.lat. Podemos elaborar una cotización comparativa del stack PodHeitor + Bacula frente a la renovación de su plataforma comercial de backup actual — con el objetivo de lograr al menos 50% de reducción de costos.

20. Legal / derechos de autor

Plugin de Backup SFTP de PodHeitor para Bacula — Versión 2.0.0

Ambos artefactos distribuidos — podheitor-sftp-fd.so (Rust plugin FD construido sobre el framework interno framework de plugin PodHeitor) y podheitor-sftp-backend (binario Rust que usa el crate ssh2 / libssh2) — son software propietario distribuido bajo LicenseRef-PodHeitor-Proprietary.

Ningún código con licencia AGPL está enlazado estáticamente en ninguno de los artefactos. Las dependencias Rust transitivas (ssh2, libssh2-sys, libc, parking_lot, openssl-sys y otras) tienen todas licencias permisivas (MIT / Apache-2.0) y son compatibles con la redistribución propietaria.

El uso, redistribución, modificación, ingeniería inversa o explotación comercial de cualquiera de los artefactos requiere un acuerdo de licencia escrito separado con el titular de los derechos de autor. Contacto: heitor@opentechs.lat.

Bacula es una marca registrada de Bacula Systems SA. Todos los demás nombres de productos son marcas comerciales o marcas registradas de sus respectivos propietarios. PodHeitor International no está afiliada con Bacula Systems SA.

Este whitepaper se proporciona con fines informativos. Las especificaciones están sujetas a cambio sin previo aviso.

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