Blog

Plugin + daemon que entrega duas capacidades em release única: aceleração de Incremental backups (3× mensurado em Linux, 1.7× em Windows) eliminando o tree-walk do FD, e detecção ativa de ransomware com 9 ações configuráveis (log, webhook, syslog/EventLog, SMB kill, ACL deny, fs snapshot, emergency backup, kill suspect processes).

Documento técnico complementar à página do plugin PodHeitor Sentinel.

1. Os dois problemas atacados

1.1 Incremental backup faz tree-walk full

O Bacula File Daemon stock executa lstat() em cada arquivo do FileSet em todo Incremental — mesmo que apenas 1 arquivo tenha mudado. Em um servidor com 60.000 arquivos:

Director → Job runs → FD lstat()'s every file → backup modified ones
          (60.000 stat calls mesmo que 1 arquivo mude)

Em file server com 600.000 arquivos, o overhead chega a dominar a janela de Incremental. Isso é o motivo de muitos sites desabilitarem Incrementals frequentes — preferem Full + Differential semanal.

1.2 Detecção de ransomware é off-line, post-mortem

Soluções padrão (CrowdStrike, Sentinel One, MS Defender) detectam ransomware no host comprometido, mas não avisam ao backup antes de o trojan terminar a criptografia. Resultado típico: backup noturno captura os arquivos já criptografados e a restauração depende de um Full anterior + perda de janela.

2. Arquitetura — 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       │                  │
   │  └─────────────────────────┘   │                     │                  │
   └────────────────────────────────┘                     └──────────────────┘

Mesmo daemon entrega ambas as capacidades. O fs watcher (inotify Linux / ReadDirectoryChangesW Win32) alimenta:

• Detection engine: 4 regras heurísticas + hysteresis scoring → policy engine.
• Accelerator (redb): hot_paths index → consultado pelo FD plugin no início do job.

3. Incremental Accelerator — antes/depois

O FD plugin consulta o daemon antes de iterar o FileSet:

Director → Job runs → plugin asks sentinel for hot paths (live) → FD backup
          (exatamente N stat calls para N arquivos modificados)
          + ransomware detection rodando em paralelo nos mesmos eventos
          + automatic VSS/btrfs/zfs snapshot + Close-SmbSession on signature

O ack do FD ao daemon (ack_backup) limpa o hot-path index, marcando o ponto-no-tempo como confirmado backup-d. Próximo Incremental parte de zero.

4. Benchmark — 2026-04-23

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

Speedup: 3.00× (saved 66.7%). Escala linearmente: projetado ~20× em file server de 600K arquivos.

Windows Server 2025, mesmo workload — 1.71× speedup (Windows tem custo per-file FD maior, então economia de walk é fração menor do tempo total).

5. Detection engine — 4 regras

5.1 Hysteresis scoring

Cada regra contribui pontos a um score por path/dir. Score acumula com decay temporal (single event << sustained pattern). Threshold de ação:

• 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 actions

7. Compatibilidade

Mesmo code base; paths platform-specific via #[cfg] Rust / #ifdef. Windows usa Named Pipes em vez de Unix sockets, Win32 services em vez de systemd, ReadDirectoryChangesW em vez de inotify.

8. Métricas Prometheus

HTTP /metrics em loopback :9990 expõe:

• 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 inclusos em monitoring/.

9. Anti-patterns documentados

• Não desative fs_snapshot action em score ≥ 80. Snapshots locais são o net contra ransomware que apaga shadow copies.
• Não set thresholds muito baixos sem watchlist. Falsos positivos de high_entropy em arquivos legítimos comprimidos (zip, JPEG, mp4) são esperados — exclua extensions conhecidas via watch_exclude_ext.
• Não rode kill_suspect_processes sem allowlist. Match incorreto de PID pode matar serviços críticos. Configure process_allowlist com PIDs/binaries de sistema.
• Não confie em burst_rename isolado. Workflows legítimos (rsync, git, IDE refactor mass-rename) podem disparar. Pareie com suspicious_ext ou high_entropy via hysteresis.

10. License posture

O plugin distribui sob LicenseRef-PodHeitor-Proprietary. Não vincula estaticamente nenhum source AGPLv3 do Bacula. O FD plugin é cdylib Rust com PTCOMM ao daemon; o daemon é binário Rust standalone. Integração com Bacula é exclusivamente via plugin API pública.

Pronto para avaliar?

Trial gratuito de 30 dias para servidores Bacula Community/Enterprise. Garantimos no mínimo 50% de desconto vs Bacula Enterprise (que não tem detecção ativa de ransomware), Veeam Threat Protection ou Commvault, com aceleração de Incrementals e ações de remediação inclusas.

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

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