Blog

Plugin + daemon que entrega dos capacidades en un release único: aceleración de Incremental backups (3× medido en Linux, 1.7× en Windows) eliminando el tree-walk del FD, y detección activa de ransomware con 9 acciones configurables (log, webhook, syslog/EventLog, SMB kill, ACL deny, fs snapshot, emergency backup, kill suspect processes).

Documento técnico complementario a la página del plugin PodHeitor Sentinel.

1. Los dos problemas atacados

1.1 Incremental backup hace tree-walk completo

El Bacula File Daemon stock ejecuta lstat() en cada archivo del FileSet en todo Incremental — incluso si solo 1 archivo cambió. En un servidor con 60.000 archivos:

Director → Job runs → FD lstat()'s every file → backup modified ones
          (60.000 stat calls aunque solo 1 archivo cambie)

En file server con 600.000 archivos, el overhead llega a dominar la ventana de Incremental. Por eso muchos sites desactivan Incrementals frecuentes — prefieren Full + Differential semanal.

1.2 Detección de ransomware es off-line, post-mortem

Las soluciones estándar (CrowdStrike, Sentinel One, MS Defender) detectan ransomware en el host comprometido pero no avisan al backup antes de que el trojan termine la cifrado. Resultado típico: el backup nocturno captura los archivos ya cifrados y la restauración depende de un Full anterior + pérdida de ventana.

2. Arquitectura — daemon Rust + FD plugin client

   ┌────────────────────────────────┐    JSON IPC         ┌──────────────────┐
   │  PodHeitor Sentinel Daemon     │◄───────────────────►│  Bacula FD       │
   │  (Rust, tokio, redb)           │  Unix socket (Linux)│  Rust cdylib FD  │
   │                                │  Named Pipe (Win32) │                  │
   │  ┌─────────────────────────┐   │                     │                  │
   │  │ fs watcher              │   │                     │                  │
   │  │  • inotify       Linux  │   │                     │                  │
   │  │  • ReadDirW      Win32  │   │                     │                  │
   │  └────────┬────────────────┘   │                     │                  │
   │           ▼                    │                     │                  │
   │  ┌─────────────────────────┐   │                     │                  │
   │  │ detection engine        │   │                     │                  │
   │  │  • burst_rename         │   │                     │                  │
   │  │  • suspicious_ext       │   │                     │                  │
   │  │  • high_entropy         │   │                     │                  │
   │  │  • altered_ratio        │   │                     │                  │
   │  │  • hysteresis scoring   │   │                     │                  │
   │  └────────┬────────────────┘   │                     │                  │
   │           ▼                    │                     │                  │
   │  ┌─────────────────────────┐   │                     │                  │
   │  │ policy engine (9 actions)   │                     │                  │
   │  └─────────────────────────┘   │                     │                  │
   │  ┌─────────────────────────┐   │                     │                  │
   │  │ accelerator (redb)      │◄──┼─── hot_paths ───────┤                  │
   │  └─────────────────────────┘   │                     │                  │
   │  ┌─────────────────────────┐   │                     │                  │
   │  │ metrics HTTP :9990      │──────► Prometheus       │                  │
   │  └─────────────────────────┘   │                     │                  │
   └────────────────────────────────┘                     └──────────────────┘

El mismo daemon entrega ambas capacidades. El fs watcher (inotify Linux / ReadDirectoryChangesW Win32) alimenta:

• Detection engine: 4 reglas heurísticas + hysteresis scoring → policy engine.
• Accelerator (redb): hot_paths index → consultado por el FD plugin al inicio del job.

3. Incremental Accelerator — antes/después

El FD plugin consulta el daemon antes de iterar el FileSet:

Director → Job runs → plugin asks sentinel for hot paths (live) → FD backup
          (exactamente N stat calls para N archivos modificados)
          + ransomware detection corriendo en paralelo en los mismos eventos
          + automatic VSS/btrfs/zfs snapshot + Close-SmbSession on signature

El ack_backup del FD al daemon limpia el hot-path index, marcando el punto-en-tiempo como backed-up. El próximo Incremental parte de cero.

4. Benchmark — 2026-04-23

Linux, 60K-file corpus, 1.000 modifications, cold cache:

Speedup: 3.00× (saved 66.7%). Escala linealmente: proyectado ~20× en file server de 600K archivos.

Windows Server 2025, mismo workload — 1.71× speedup (Windows tiene costo per-file FD mayor, así que el ahorro de walk es fracción menor del tiempo total).

5. Detection engine — 4 reglas

5.1 Hysteresis scoring

Cada regla contribuye puntos a un score por path/dir. El score acumula con decay temporal (single event << sustained pattern). Threshold de acción:

• Score < 30 → telemetry only
• 30 ≤ score < 60 → actions WARN level (log, webhook)
• 60 ≤ score < 80 → actions ALERT level (syslog/EventLog, alert_cmd)
• score ≥ 80 → actions CRITICAL level (smb_kill_sessions, readonly_remount, fs_snapshot, emergency_backup, kill_suspect_processes)

6. Policy engine — 9 acciones

7. Compatibilidad

Mismo code base; paths platform-specific vía #[cfg] Rust / #ifdef. Windows usa Named Pipes en vez de Unix sockets, Win32 services en vez de systemd, ReadDirectoryChangesW en vez de inotify.

8. Métricas Prometheus

HTTP /metrics en loopback :9990 expone:

• sentinel_events_total{type="rename|create|modify|delete"}
• sentinel_score_current{path} (gauge)
• sentinel_actions_fired_total{action, severity}
• sentinel_accelerator_hot_paths_count (gauge)
• sentinel_accelerator_queries_total, sentinel_accelerator_acks_total
• sentinel_redb_size_bytes, sentinel_daemon_rss_bytes

Alertas Prometheus + dashboard Grafana incluidos en monitoring/.

9. Anti-patterns documentados

• No desactive la action fs_snapshot en score ≥ 80. Los snapshots locales son la red de seguridad contra ransomware que borra shadow copies.
• No setee thresholds muy bajos sin watchlist. Falsos positivos de high_entropy en archivos legítimamente comprimidos (zip, JPEG, mp4) son esperados — excluya extensions conocidas vía watch_exclude_ext.
• No corra kill_suspect_processes sin allowlist. Match incorrecto de PID puede matar servicios críticos. Configure process_allowlist con PIDs/binaries de sistema.
• No confíe en burst_rename aislado. Workflows legítimos (rsync, git, IDE mass-rename refactor) pueden dispararlo. Combine con suspicious_ext o high_entropy vía hysteresis.

10. License posture

El plugin se distribuye bajo LicenseRef-PodHeitor-Proprietary. No vincula estáticamente ningún source AGPLv3 de Bacula. El FD plugin es cdylib Rust que conversa PTCOMM al daemon; el daemon es binario Rust standalone. La integración con Bacula es exclusivamente vía la plugin API pública.

¿Listo para evaluar?

Trial gratuito de 30 días para servidores Bacula Community/Enterprise. Garantizamos al menos 50% de descuento vs Bacula Enterprise (que no tiene detección activa de ransomware), Veeam Threat Protection o Commvault, con aceleración de Incrementals y acciones de remediación incluidas.

Heitor Faria — Fundador, PodHeitor International
✉ [email protected]
☎ +1 (789) 726-1749 · +55 (61) 98268-4220 (WhatsApp)
🔗 Página del plugin PodHeitor Sentinel

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