Whitepaper técnico — PodHeitor Web Interface para Bacula - PodHeitor

Whitepaper Técnico — Versão 0.1.0 — Maio de 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 — Veeam, Commvault, NetBackup ou outras. Vamos elaborar uma proposta comparativa com meta de pelo menos 50% de economia e uma interface web moderna e completa para Bacula. Contate heitor@opentechs.lat para um orçamento por escrito.

Índice

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

1. Resumo executivo

O Bacula Community Edition é uma das plataformas de backup open-source mais utilizadas no mundo, protegendo centenas de milhares de servidores em empresas, universidades, organizações do setor público e provedores de serviços gerenciados. No entanto, sua administração historicamente dependeu da interação direta com o bconsole via CLI, da edição manual de arquivos de configuração e de uma interface web opcional que não reflete os padrões de usabilidade das plataformas SaaS modernas. Administradores que precisam gerenciar centenas de clientes, orquestrar fluxos complexos de restore ou configurar a crescente família de plugins PodHeitor ficam restritos a scripts frágeis e alto risco operacional.

PHWEB — PodHeitor Web Interface muda esse cenário. PHWEB é uma aplicação web full-stack em Rust de nível produção que oferece um console de gerenciamento moderno e orientado por tarefas para o Bacula Community Edition. Entrega paridade operacional completa com o Bacula Enterprise BWeb — a referência comercial para gestão web do Bacula — enquanto adiciona suporte nativo a todos os plugins PodHeitor, um pipeline transacional de configuração com rollback em 1 clique, um AI Copilot, diagramas de topologia ao vivo e uma arquitetura modular projetada para crescer até implantações multi-tenant de MSP.

Construído sobre Axum (backend) e Leptos 0.7 (frontend, compilado para WASM), PHWEB é um único binário implantável sem Node.js, sem runtime Python e sem stack PHP. Ele se conecta ao Bacula Director via a interface padrão bconsole — compatível com todas as versões do Bacula Community a partir da 9.x — e persiste seus metadados próprios no PostgreSQL. Uma REST API completa é exposta para automação e integração com plataformas externas de monitoramento.

PHWEB chegou à versão 0.2.86 com 162 fases de desenvolvimento concluídas, 279 casos de teste automatizados aprovados e uma implantação ao vivo rodando no Bacula 15.0.3 em ambiente de laboratório de produção. A interface cobre 42 módulos funcionais, do dashboard ao AI Copilot, e suporta três idiomas (PT-BR, EN, ES) nativamente. Para qualquer organização que utilize Bacula Community, PHWEB é o caminho mais completo e mais custo-efetivo para uma interface de gerenciamento moderna e defensável.

2. Introdução e contexto de mercado

2.1 O gap de gerenciamento do Bacula Community

O Bacula Community Edition oferece capacidades excepcionais de motor de backup: suporte a clientes multiplataforma, agendamento avançado, gestão de pools e volumes, uma linguagem rica de FileSet e uma API de plugins que permite integração profunda com hipervisores, bancos de dados e sistemas de armazenamento. O que ele não fornece out-of-the-box é uma interface administrativa moderna.

A interface padrão é o bconsole: uma CLI linha a linha que exige que administradores memorizem sintaxe de comandos, interpretem saídas de texto semiestruturadas e editem arquivos de configuração ASCII com um editor de texto. Para usuários experientes em ambientes pequenos, isso é viável. Para operadores de helpdesk que precisam iniciar um restore de arquivo, para executivos que precisam de um dashboard de status ou para organizações com dezenas de clientes e configurações complexas de plugins, a CLI pura é um passivo — não um recurso.

O resultado é um gap de mercado bem documentado: organizações rodando Bacula Community ou investem pesado em scripts e procedimentos manuais para compensar a camada de UI ausente, ou pagam pelo Bacula Enterprise BWeb, uma interface comercial que adiciona custo significativo de licenciamento. Uma terceira opção — migrar para outra plataforma de backup — introduz custo operacional e risco muito maiores do que o problema de UI que deveria resolver.

2.2 Opções de UI existentes e suas limitações

Solução	Resumo	Principais limitações
bconsole (CLI)	CLI padrão do Bacula	Sem GUI, curva de aprendizado íngreme, sem restore self-service
Bacularis	Interface web PHP open-source	Stack PHP, paridade parcial com BWeb, sem suporte a plugins PodHeitor, RBAC limitado
BWeb (Bacula Enterprise)	Interface comercial Perl/CGI bundled com Enterprise	Exige licença Enterprise, sem suporte a Community, custo adicional significativo
Dashboards customizados (Grafana + scripts)	Monitoramento ad-hoc	Somente leitura, sem restore, sem gestão de config, alto custo de manutenção

Nenhuma dessas opções entrega a combinação completa de: implantação compatível com open-source, cobertura completa de paridade com BWeb, configuração nativa de plugins PodHeitor, gestão transacional de configuração com rollback e uma trilha de auditoria e RBAC de nível enterprise.

2.3 A abordagem PHWEB

PHWEB é construído sobre três princípios fundamentais:

Paridade com BWeb em primeiro lugar. Nenhuma funcionalidade que o BWeb oferece é deixada de lado. Cada capacidade — gestão de jobs, restore, armazenamento, pools, volumes, autochanger, relatórios, ACL — é coberta antes de qualquer extensão específica do PHWEB ser adicionada.
Nativo para PodHeitor. PHWEB tem conhecimento nativo de todos os plugins PodHeitor via o contrato do Plugin Hub. Administradores configuram plugins através de formulários validados, sem necessidade de digitar strings Plugin manualmente.
Segurança mission-critical. Mudanças de configuração seguem um pipeline transacional de 11 etapas: rascunho, validação sintática, validação semântica, verificação de ACL, análise de impacto, aprovação (4-eyes opcional), apply atômico, reload, smoke tests, monitoramento e rollback automático se o SLO for violado.

3. Visão geral da arquitetura

3.1 Full-stack Rust: Axum + Leptos

PHWEB é uma aplicação Rust full-stack. O backend roda em Axum, um framework HTTP async de alta performance. O frontend é compilado de Rust para WebAssembly usando Leptos 0.7, um framework de componentes reativos com server-side rendering e hidratação transparente. As duas metades compartilham tipos via o crate phweb-core, eliminando categorias inteiras de bugs de serialização que afetam stacks heterogêneos de frontend/backend.

O build produz um único binário autocontido (phweb-server) mais um diretório de site estático. Nenhum Node.js, Python ou interpretador PHP é necessário em runtime.

Camada	Tecnologia	Papel
Backend	Axum + tokio	REST API, server functions, integração com Bacula, plugin hub
Frontend	Leptos 0.7 (WASM)	SPA reativo com hidratação SSR
Tipos compartilhados	phweb-core (Rust)	Modelos, tipos de API, erros — usados por ambas as metades
Banco de dados	PostgreSQL + SQLx	Metadados, audit log, sessões, registro de plugins
Estilização	Tailwind CSS	CSS utilitário, compilado em tempo de build
Gráficos	charming (ECharts)	Gráficos operacionais e dashboards
Topologia	Cytoscape.js (wasm-bindgen)	Diagrama de topologia ao vivo

3.2 Integração com o Bacula Director

PHWEB se conecta a um ou mais Bacula Directors via a interface padrão de subprocesso bconsole. O módulo BaculaControlPlane abstrai o protocolo, tornando a integração flexível e de fácil manutenção. Na implementação atual:

Comandos são despachados como invocações do bconsole com stdin pipe.
Quando o Director suporta (Bacula 9.x+), o modo .api 2 é usado para saída JSON.
Parsers de fallback tratam saída legada em texto para Directors mais antigos.
Cada tenant usa um bconsole.conf isolado; credenciais nunca são expostas pela API.
Timeouts são impostos por tipo de comando: status 5s, list 30s, restore 120s.

4. Funcionalidades em profundidade

4.1 Control Center (Dashboard)

O Control Center é a tela operacional principal. Fornece uma visão unificada da saúde de backup em todo o ambiente sem exigir que o operador execute um único comando bconsole.

Cards de KPI: jobs em execução, jobs concluídos, jobs com falha nas últimas 24 horas; LEDs de acessibilidade do Director, Storage Daemon e Clients.
Cards de explicabilidade: quando um componente está com problema, PHWEB exibe um card em linguagem simples explicando o que está errado, por que importa e qual é a ação corretiva recomendada.
Card de saúde incremental: rastreia o status do baseline CBT/RCT por client; indica drift que requer um backup Full forçado.
Gráfico de tendência de jobs: taxa de sucesso/falha de jobs em 7 dias plotada com ECharts.
Indicadores de conformidade de SLO: status de RPO/RTO por serviço com alertas de limite.

4.2 Backup Operations (Gestão de jobs)

O módulo Backup Operations oferece gerenciamento completo do ciclo de vida de jobs:

Liste todos os jobs com filtros ricos: status, client, pool, schedule, intervalo de datas, tipo de plugin.
Execute um job manualmente com substituição de parâmetros (level, pool, storage).
Cancele um job ativo com fluxo de confirmação.
Visualize o log completo do job em tempo real (polling, intervalo de 5s).
Backup Studio drag-and-drop: arraste workloads para políticas; simule janelas de retenção e custo de armazenamento antes de confirmar.
Assistente de onboarding por tipo de workload: VM, banco de dados, SFTP agentless, replicação de arquivos.

4.3 Restore Studio

O Restore Studio elimina a necessidade de conhecer comandos BVFS. Guia os operadores por uma interface de três painéis:

Painel esquerdo: seletor de client + lista de jobs de backup disponíveis (com data, nível e tipo de plugin).
Painel central: árvore de diretórios BVFS com navegação por breadcrumb; clique para navegar; arquivos listados ao entrar em um diretório.
Painel direito: cesta de restore com arquivos/diretórios selecionados; opções de restore (client de destino, caminho, remoção de prefixo); botão Iniciar Restore.

Fluxos adicionais de restore:

Restore de VM: restore completo de VM ou restore granular de arquivos a partir de um backup de imagem de VM, com assistente de migração cross-hypervisor (vSphere ↔ Proxmox ↔ Hyper-V).
PostgreSQL PITR Studio: timeline visual de pontos de restore com continuidade WAL; seletor de estratégia (DUMP, PITR, PITR_BLOCK); validação de continuidade de WAL antes do restore; checklist pós-restore.
Restore completo de banco de dados: restore em modo dump para qualquer plugin de banco de dados suportado.

4.4 Config Studio

O Config Studio é o módulo de gestão de configuração mission-critical. Substitui a edição direta de arquivos por um fluxo estruturado e seguro:

Editor estruturado: edição baseada em formulários para todos os tipos de recursos Bacula — Director, Client, Storage, Pool, FileSet, Job, JobDefs, Schedule, Messages, Console, Catalog, Device, Collector, Tenant.
Modo editor de texto: para usuários avançados, um editor de texto simples com realce de sintaxe está disponível como alternativa opcional.
Diff visual: toda mudança proposta mostra um diff com código de cores em relação à configuração em execução atual.
Pipeline de 11 etapas: Rascunho → Validação Sintática → Validação Semântica (verificação de referências cruzadas) → Verificação de ACL/Policy → Análise de Impacto (jobs ativos, recursos referenciados) → Aprovação (4-eyes para mudanças críticas) → Apply Atômico → Reload → Smoke Tests → Monitoramento → Rollback Automático se o SLO for violado.
Rollback em 1 clique: o snapshot pré-apply é sempre armazenado; o rollback restaura o arquivo e recarrega o Director automaticamente.

4.5 Plugin Hub — Configuração de plugins PodHeitor

O Plugin Hub fornece uma interface de configuração unificada para todos os plugins PodHeitor. Em vez de digitar uma string Plugin manualmente, os operadores usam um formulário validado gerado a partir do JSON Schema de cada plugin:

Descoberta e registro de plugins com versão e status de saúde.
Renderização dinâmica de formulário por plugin: campos agrupados por categoria (Conectividade, Seleção, Performance, Avançado); campos sensíveis mascarados; campos enum renderizados como dropdowns; campos multivalorados renderizados como tag inputs.
Teste de conectividade antes de salvar a configuração.
Serialização automática para a string Plugin = "..." correta para o FileSet.
Plugins suportados: vSphere, Hyper-V, Proxmox, CloudStack, PostgreSQL, SFTP agentless, File Replication, Global Deduplication, Active Ransomware Detection, Incremental Accelerator, Granular Restore.

4.6 Relatórios e Analytics

Relatórios prontos: jobs por período, uso de storage, conformidade de SLA, razão de deduplicação, RPO/RTO de replicação, cobertura de políticas.
Construtor de relatórios customizados com seleção de campos drag-and-drop.
Exportação: CSV, PDF, JSON.
Entrega agendada: e-mail, webhook, Telegram, WhatsApp.
Data Explorer: construtor de consultas ad-hoc com plotagem multi-eixo e dashboards salvos.

4.7 DR & Replication Center

Estado de replicação por workload com rastreamento de RPO.
Assistente de failover guiado: failover de teste, failover planejado, failover não planejado, failback — cada um com checklist de pré-voo e validação pós-ação.
Agendamento de DR drills e pontuação de prontidão.
Visualização de blast radius: antes de executar um failover, veja quais serviços downstream são afetados.

4.8 Módulo de Segurança e Ransomware

Dashboard de risk score com timeline de anomalias detectadas.
Ações de alerta automatizadas: isolar job, notificar operador, acionar snapshot de DR.
Toggle independente para Active Ransomware Detection e Incremental Accelerator por tenant.
Gestão de whitelist e ajuste de threshold por diretório.

4.9 AI Copilot

Consultas operacionais em linguagem natural: “por que o job X falhou?”, “qual é o RPO atual do client Y?”.
Geração de plano de mudança com risk score e log de explicabilidade.
Explicação de comandos e configurações.
Terminal remoto assistido com guardrails — comandos perigosos exigem confirmação.

4.10 Mapa de Topologia ao Vivo

Um diagrama ao vivo do ambiente Bacula renderizado via Cytoscape.js. Mostra Directors, Storage Daemons, File Daemons, plugins, caminhos de rede e relacionamentos de dependência. LEDs de acessibilidade são atualizados em tempo real. Clicar em qualquer nó abre seu painel de detalhes inline.

5. Matriz de funcionalidades

Funcionalidade	PHWEB	Bacularis (free)	BWeb (Enterprise)
Dashboard com KPIs de jobs	Sim	Sim	Sim
Gestão de jobs (run/cancel/log)	Sim	Sim	Sim
Restore BVFS (browser de arquivos)	Sim	Sim	Sim
Restore granular de VM	Sim	Não	Sim
Assistente de migração cross-hypervisor	Sim	Não	Limitado
PostgreSQL PITR Studio	Sim	Não	Não
Gestão de storage / pool / volume	Sim	Sim	Sim
Editor completo de configuração Bacula	Sim	Parcial	Sim
Pipeline transacional de config + rollback	Sim	Não	Não
UI de configuração de plugins PodHeitor	Sim (11 plugins)	Não	Não
Teste de conectividade de plugin	Sim	Não	Não
RBAC com isolamento por tenant	Sim	Limitado	Sim
MFA (TOTP)	Sim	Não	Sim
Audit log imutável (PostgreSQL)	Sim	Não	Sim
Endpoint Prometheus /metrics	Sim	Não	Não
Relatórios agendados com entrega	Sim	Não	Sim
DR & Replication Center	Sim	Não	Limitado
UI de detecção de ransomware	Sim	Não	Não
Observabilidade de deduplicação	Sim	Não	Limitado
AI Copilot	Sim	Não	Não
Mapa de topologia ao vivo	Sim	Não	Não
Data Explorer com dashboards customizados	Sim	Não	Limitado
Deploy remoto de agentes	Sim	Não	Sim
UI multilíngue (PT/EN/ES)	Sim	Não	Não
Binário único (sem PHP/Python)	Sim	Não (PHP)	Não (Perl/CGI)
Compatível com Bacula Community	Sim	Sim	Não
Open source	Não (comercial)	Sim	Não

6. Guia de instalação

6.1 Pré-requisitos

Requisito	Detalhes
Sistema operacional	RHEL 9 / Rocky 9 / AlmaLinux 9 · Ubuntu 22.04+ · Debian 12+
Arquitetura	x86_64
Bacula Community	9.x ou superior (15.x recomendado)
PostgreSQL	14 ou superior (para metadados do PHWEB; separado do catálogo Bacula)
nginx (recomendado)	Proxy reverso para terminação TLS e serviço de assets estáticos
RAM	Mínimo 512 MB; 2 GB recomendado para produção
Disco	2 GB para binário e arquivos do site; adicional para dados do PostgreSQL

6.2 Instalação via RPM (RHEL / Rocky / AlmaLinux)

# Adicionar o repositório PodHeitor
curl -fsSL https://podheitor.com/rpm/podheitor.repo -o /etc/yum.repos.d/podheitor.repo

# Instalar PHWEB
dnf install -y podheitor-phweb

# Inicializar o banco de dados
sudo -u postgres createuser phweb
sudo -u postgres createdb -O phweb phweb
export DATABASE_URL="postgres://phweb:TROCAR@localhost/phweb"
/opt/phweb/bin/phweb-server --migrate-only

# Habilitar e iniciar o serviço
systemctl enable --now phweb

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

# Adicionar o repositório PodHeitor
curl -fsSL https://podheitor.com/deb/podheitor.gpg | gpg --dearmor 
  -o /usr/share/keyrings/podheitor.gpg
echo "deb [signed-by=/usr/share/keyrings/podheitor.gpg] 
  https://podheitor.com/deb stable main" 
  > /etc/apt/sources.list.d/podheitor.list
apt-get update
apt-get install -y podheitor-phweb

# Inicializar o banco de dados (igual ao RPM acima)
export DATABASE_URL="postgres://phweb:TROCAR@localhost/phweb"
/opt/phweb/bin/phweb-server --migrate-only

systemctl enable --now phweb

6.4 Unidade systemd

[Unit]
Description=PHWEB — PodHeitor Web Interface for Bacula
After=network.target postgresql.service

[Service]
Type=simple
User=phweb
Group=bacula
EnvironmentFile=/etc/phweb/phweb.env
ExecStart=/opt/phweb/bin/phweb-server
Restart=on-failure
RestartSec=5s
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

6.5 Configuração de proxy reverso nginx

server {
    listen 443 ssl http2;
    server_name phweb.exemplo.com.br;

    ssl_certificate     /etc/ssl/phweb/fullchain.pem;
    ssl_certificate_key /etc/ssl/phweb/privkey.pem;

    location / {
        proxy_pass         http://127.0.0.1:3001;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_read_timeout 120s;
    }

    location /site/ {
        alias /opt/phweb/site/;
        expires 1d;
        add_header Cache-Control "public, no-transform";
    }
}

6.6 Credenciais iniciais

Na primeira inicialização, PHWEB cria uma conta de administrador padrão:

Usuário: admin
Senha: admin

Você será obrigado a alterar a senha no primeiro login. É altamente recomendado habilitar o MFA (TOTP) imediatamente após a troca de senha.

7. Referência de configuração

PHWEB é configurado via variáveis de ambiente ou um arquivo phweb.env em /etc/phweb/.

Parâmetro	Padrão	Descrição
`DATABASE_URL`	obrigatório	String de conexão PostgreSQL: `postgres://user:senha@host/db`
`PHWEB_AUTO_MIGRATE`	`0`	Defina `1` para executar migrações de BD automaticamente na inicialização
`LEPTOS_SITE_ADDR`	`127.0.0.1:3001`	Endereço de bind para o servidor HTTP do PHWEB
`LEPTOS_OUTPUT_NAME`	`phweb`	Prefixo de nome para assets compilados; deve corresponder ao cargo-leptos.toml
`PHWEB_CONFIG_APPLY_ENABLED`	`0`	Defina `1` para permitir que o Config Studio aplique mudanças nos arquivos de configuração do Bacula
`PHWEB_SESSION_SECRET`	auto-gerado	Chave secreta para assinatura de cookie de sessão (string hex de 32+ bytes recomendada)
`PHWEB_SESSION_MAX_AGE_SECS`	`86400`	Duração do cookie de sessão em segundos (padrão: 24 horas)
`PHWEB_BCONSOLE_BIN`	`/opt/bacula/bin/bconsole`	Caminho absoluto para o binário do bconsole
`PHWEB_BCONSOLE_CONF`	`/opt/bacula/etc/bconsole.conf`	Caminho padrão do bconsole.conf (substituído por Director no banco de dados)
`PHWEB_METRICS_ENABLED`	`1`	Expor métricas Prometheus em `/metrics`
`PHWEB_LOG_LEVEL`	`info`	Verbosidade do log: `trace`, `debug`, `info`, `warn`, `error`
`PHWEB_AI_BACKEND_URL`	não definido	URL opcional para endpoint de modelo de AI externo (funcionalidade AI Copilot)
`PHWEB_AI_API_KEY`	não definido	Chave de API para o backend de AI (armazenada em cofre de segredos, nunca registrada em log)

8. Exemplos de configuração

8.1 Setup mínimo com um único Director

# /etc/phweb/phweb.env

DATABASE_URL=postgres://phweb:senhaforte@localhost/phweb
PHWEB_AUTO_MIGRATE=1
LEPTOS_SITE_ADDR=127.0.0.1:3001
LEPTOS_OUTPUT_NAME=phweb
PHWEB_CONFIG_APPLY_ENABLED=1
PHWEB_BCONSOLE_BIN=/opt/bacula/bin/bconsole
PHWEB_BCONSOLE_CONF=/opt/bacula/etc/bconsole.conf
PHWEB_LOG_LEVEL=info

8.2 Setup de produção com TLS (atrás do nginx) e métricas

# /etc/phweb/phweb.env

DATABASE_URL=postgres://phweb:segredo_prod@db.interno/phweb
PHWEB_AUTO_MIGRATE=1
LEPTOS_SITE_ADDR=127.0.0.1:3001
LEPTOS_OUTPUT_NAME=phweb
PHWEB_CONFIG_APPLY_ENABLED=1
PHWEB_SESSION_SECRET=a4f3e7c901b2d8e56f0a3c7d9b1e4f2a
PHWEB_SESSION_MAX_AGE_SECS=28800
PHWEB_METRICS_ENABLED=1
PHWEB_LOG_LEVEL=warn

8.3 Ambiente multi-Director para MSP

PHWEB suporta múltiplos Directors registrados pela interface de Administração. Cada registro de Director armazena sua própria configuração bconsole, atribuição de tenant e configurações TLS. Nenhuma variável de ambiente adicional é necessária para os Directors extras além do setup base.

# Ambiente base (como no exemplo 8.2)
# Directors adicionais são adicionados via:
# Administração > Directors > Adicionar Director

# Exemplo de registro de Director (armazenado na tabela phweb.phweb_directors):
# name:            "cliente-acme-dir"
# host:            "192.168.100.10"
# port:            9101
# bconsole_config: "/etc/phweb/bconsole-acme.conf"
# tenant_id:       2
# tls_enabled:     true

8.4 Ambiente de depuração intensa para troubleshooting

# /etc/phweb/phweb.env

DATABASE_URL=postgres://phweb:senhadev@localhost/phweb
PHWEB_AUTO_MIGRATE=1
LEPTOS_SITE_ADDR=0.0.0.0:3001
LEPTOS_OUTPUT_NAME=phweb
PHWEB_CONFIG_APPLY_ENABLED=0
PHWEB_LOG_LEVEL=debug
PHWEB_METRICS_ENABLED=1

8.5 Modo somente leitura para monitoramento (sem apply de config)

# /etc/phweb/phweb.env

DATABASE_URL=postgres://phweb_ro:senha_readonly@db.interno/phweb
PHWEB_AUTO_MIGRATE=0
LEPTOS_SITE_ADDR=127.0.0.1:3001
LEPTOS_OUTPUT_NAME=phweb
PHWEB_CONFIG_APPLY_ENABLED=0
PHWEB_LOG_LEVEL=info
PHWEB_METRICS_ENABLED=1

8.6 Com AI Copilot habilitado

# /etc/phweb/phweb.env (adicionar a qualquer config base)

PHWEB_AI_BACKEND_URL=https://api.provedor.exemplo/v1
PHWEB_AI_API_KEY=sk-prod-xxxxxxxxxxxxxxxxxxx

9. Dimensionamento e planejamento de capacidade

9.1 Diretrizes de dimensionamento por componente

Tamanho do ambiente	Directors	Clients	RAM recomendada	CPU recomendada	Storage PostgreSQL
Pequeno	1	Até 50	1 GB	2 vCPU	10 GB
Médio	1–3	50–500	2 GB	4 vCPU	50 GB
Grande	3–10	500–2000	4 GB	8 vCPU	200 GB
MSP / Enterprise	10+	2000+	8+ GB	16+ vCPU	500+ GB

9.2 Detalhamento do storage PostgreSQL

O banco de dados PostgreSQL do PHWEB armazena metadados de interface — não replica o catálogo Bacula. Os principais contribuintes para o crescimento de armazenamento são:

Audit log: aproximadamente 500 bytes por ação registrada. Com 10.000 ações por dia, cresce cerca de 1,8 GB por ano.
Session store: pequeno; sessões expiram automaticamente.
Cache do registro de plugins: negligível (JSON schemas, alguns KB por plugin).
Propostas de mudança de config: cada proposta armazena um diff e snapshot de rollback; média de 5–20 KB por proposta.
Saídas de relatórios agendados: se armazenadas localmente em vez de entregues externamente, reserve 1–10 MB por relatório.

9.3 Notas sobre alta disponibilidade

O PHWEB em si é stateless entre requisições (todo estado no PostgreSQL). Para implantações de alta disponibilidade, execute duas ou mais instâncias do PHWEB atrás de um load balancer com afinidade de sessão, compartilhando um único cluster PostgreSQL com replicação streaming.

10. Relatório de desempenho

10.1 Tempos de carregamento de página (medição em laboratório)

Página	Primeiro carregamento (SSR frio)	Subsequente (hidratado)
Dashboard	320 ms	85 ms
Lista de jobs (500 jobs)	480 ms	120 ms
Restore Studio (navegação BVFS)	410 ms	95 ms
Config Studio (config completa do Director)	550 ms	150 ms
Mapa de topologia (50 nós)	620 ms	180 ms

Medições realizadas em VM com 4 vCPU e 4 GB RAM, PostgreSQL no mesmo host, Bacula Director conectado localmente. Latência de rede entre browser e servidor: <5 ms.

10.2 Capacidade de usuários simultâneos

Usuários simultâneos	Utilização de CPU	Tempo de resposta mediano	Tempo de resposta P99
10	8%	45 ms	120 ms
50	22%	65 ms	210 ms
100	45%	95 ms	380 ms
200	78%	160 ms	720 ms

10.3 Latência de operações bconsole

Operação	Latência mediana	Notas
status director	420 ms	Inclui spawn do subprocesso
list jobs (últimos 100)	310 ms	Com modo JSON .api 2
bvfs_lsdirs	180 ms	Após cache bvfs_update construído
run job	520 ms	Somente confirmação do Director
reload	850 ms	Reload completo da config do Director

10.4 Cobertura de testes

Fase	Testes adicionados	Total acumulado
Fase 0 (Foundation)	18	18
Fase 1 (Bweb Parity)	42	60
Fase 2 (Config Full)	38	98
Fase 3 (PodHeitor Native)	71	169
Fase 4 (Intelligence)	55	224
Branch-gap re-scout (fases 5–162)	55	279

11. Matriz de compatibilidade

11.1 Sistema operacional

SO	Arquitetura	Status
RHEL 9	x86_64	Suportado
Rocky Linux 9	x86_64	Suportado
AlmaLinux 9	x86_64	Suportado
Ubuntu 22.04 LTS	x86_64	Suportado
Ubuntu 24.04 LTS	x86_64	Suportado
Debian 12	x86_64	Suportado
RHEL 8 / CentOS 8	x86_64	Não testado (glibc < 2.34)
Ubuntu 20.04	x86_64	Não testado (glibc < 2.34)
ARM64 / aarch64	qualquer	Ainda não disponível

11.2 Versões Bacula

Versão Bacula	Status	Notas
15.0.x	Totalmente suportado (testado)	Alvo primário; modo JSON .api 2 disponível
13.0.x	Suportado	.api 2 disponível; testado em modo de compatibilidade
11.0.x	Suportado (legado)	Parser regex de fallback utilizado
9.x	Melhor esforço	Parser regex; algumas funcionalidades podem não estar disponíveis
7.x e anteriores	Não suportado	Incompatibilidades de API de plugin

11.3 Navegadores

Navegador	Versão mínima	Status
Chrome / Chromium	100+	Suportado
Firefox	100+	Suportado
Safari	15+	Suportado
Edge (Chromium)	100+	Suportado
Internet Explorer	Qualquer	Não suportado

11.4 Compatibilidade de plugins PodHeitor

Plugin	UI de Config PHWEB	UI de Restore PHWEB	DR Center
podheitor-vsphere	Sim	Sim	Sim
podheitor-hyperv	Sim	Sim	Sim
podheitor-proxmox	Sim	Sim	Sim
podheitor-cloudstack	Sim	Sim	Limitado
podheitor-postgresql	Sim	Sim (PITR Studio)	Não
podheitor-sftp	Sim	Sim	Não
podheitor-file-replication	Sim	Sim	Sim
podheitor-global-dedup	Sim	N/A	Não
podheitor-ransomware-detection	Sim	N/A	Não
podheitor-incremental-accelerator	Sim	N/A	Não
podheitor-granular-restore	Sim	Sim	Não

12. Segurança

12.1 Autenticação

Hash de senha: Argon2id com parâmetros de custo padrão (memória: 64 MB, iterações: 3, paralelismo: 4). Senhas nunca são armazenadas em texto simples.
MFA: TOTP (Time-based One-Time Password) com SHA-1, 6 dígitos, intervalo de 30 segundos. QR Code gerado server-side para enrollment. MFA é opcional, mas fortemente recomendado para todas as contas.
Sessões: baseadas em cookie com HttpOnly, SameSite=Lax e Secure (em produção). Tokens de sessão são armazenados no PostgreSQL e expiram após 24 horas por padrão (configurável via PHWEB_SESSION_MAX_AGE_SECS).

12.2 RBAC

PHWEB implementa Role-Based Access Control com isolamento por tenant:

Papel built-in	Capacidades
admin	Acesso total: todos os módulos, todos os tenants, gestão de usuários, apply de config
operator	Gestão de jobs, iniciação de restore, monitoramento; sem apply de config, sem gestão de usuários
helpdesk	Somente Restore Studio; dashboard somente leitura; sem run/cancel de jobs
readonly	Dashboard e relatórios apenas; sem ações

Papéis customizados podem ser definidos com permissões granulares por recurso e por ação. Todas as verificações de permissão são impostas no lado do servidor pelo policy engine — o frontend desabilita elementos de UI de acordo, mas o backend valida de forma independente cada requisição.

12.3 Audit log

Toda ação autenticada é registrada em uma tabela de audit log append-only no PostgreSQL:

audit_log (
  id          BIGSERIAL PRIMARY KEY,
  user_id     UUID NOT NULL,
  action      TEXT NOT NULL,       -- ex: "job.run", "config.apply", "restore.start"
  resource_type TEXT,
  resource_id TEXT,
  payload_json JSONB,
  ip          INET,
  tenant_id   UUID,
  timestamp   TIMESTAMPTZ NOT NULL DEFAULT now()
)

A tabela não tem permissões UPDATE ou DELETE para o papel da aplicação — entradas são imutáveis após serem gravadas. Um índice em timestamp DESC suporta consultas eficientes por intervalo de tempo. Entradas de auditoria são paginadas e filtráveis no módulo de Administração.

12.4 Proteção CSRF

Todas as requisições que alteram estado exigem um token CSRF válido derivado do segredo de sessão. As server functions Leptos tratam isso automaticamente via a pilha de middleware Axum.

12.5 Alinhamento com OWASP

Risco OWASP Top 10	Mitigação PHWEB
Broken Access Control	Verificação de ACL server-side por requisição; isolamento de tenant em todas as queries
Cryptographic Failures	Senhas Argon2id; TLS imposto; segredos em variáveis de ambiente, nunca em código
Injection	Queries parametrizadas SQLx; allowlist de comandos bconsole; sem interpolação de strings
Insecure Design	Pipeline de config de 11 etapas; aprovação 4-eyes para mudanças críticas
Security Misconfiguration	Padrões seguros (PHWEB_CONFIG_APPLY_ENABLED=0 por padrão); sem endpoints de debug em prod
Vulnerable Components	Segurança de memória Rust; scanning automatizado de dependências em CI (cargo-audit)
Auth & Session Failures	Argon2id + TOTP + cookies HttpOnly + expiração de sessão
SSRF	Caminhos bconsole.conf validados; URLs externas no AI Copilot exigem allowlist explícita

12.6 Gestão de segredos

PHWEB nunca armazena segredos (chaves de API, senhas bconsole, chaves de API de AI) no banco de dados em texto simples. Toda configuração sensível é injetada via variáveis de ambiente ou sistema de gestão de segredos. Uma integração futura com HashiCorp Vault está planejada para a Fase 5 (edição Enterprise).

13. Monitoramento

13.1 Métricas Prometheus

Quando PHWEB_METRICS_ENABLED=1, PHWEB expõe um endpoint /metrics compatível com Prometheus. As seguintes famílias de métricas estão disponíveis:

Métrica	Tipo	Descrição
`phweb_http_requests_total`	Counter	Total de requisições HTTP por método, path e código de status
`phweb_http_request_duration_seconds`	Histogram	Distribuição de latência de requisições HTTP
`phweb_bconsole_commands_total`	Counter	Invocações bconsole por tipo de comando e resultado
`phweb_bconsole_command_duration_seconds`	Histogram	Distribuição de latência de comandos bconsole
`phweb_active_sessions`	Gauge	Número atual de sessões ativas
`phweb_audit_events_total`	Counter	Entradas de audit log gravadas, por ação
`phweb_config_proposals_total`	Counter	Propostas de configuração por status final
`phweb_bacula_jobs_running`	Gauge	Jobs Bacula em execução (polled)
`phweb_bacula_jobs_failed_last_24h`	Gauge	Jobs Bacula com falha nas últimas 24 horas

13.2 Health check

Um endpoint de health leve está disponível em GET /health:

{
  "status": "ok",
  "version": "0.2.86",
  "database": "connected",
  "bacula": "connected",
  "uptime_secs": 86400
}

Este endpoint não requer autenticação e é adequado para health probes de load balancer e integrações de monitoramento externo (UptimeRobot, Nagios, Zabbix).

13.3 Logging estruturado

PHWEB emite logs JSON estruturados para stdout (capturado pelo journal do systemd). Cada entrada de log inclui timestamp, nível, caminho do módulo, request ID, ID do usuário (quando autenticado) e ID do tenant. Os logs podem ser encaminhados para qualquer sistema de agregação (Loki, Elasticsearch, Splunk) usando encaminhamento padrão via syslog ou journal.

14. Guia de solução de problemas

14.1 Problemas comuns

PHWEB inicia mas comandos bconsole falham silenciosamente

phweb: bconsole command failed: (empty stderr)

Causa. O usuário de serviço do PHWEB não tem permissão de leitura no arquivo de configuração bconsole.
Solução: Garanta que o usuário de serviço está no grupo bacula e que bconsole.conf é legível pelo grupo.

usermod -aG bacula phweb
chmod 640 /opt/bacula/etc/bconsole.conf
chgrp bacula /opt/bacula/etc/bconsole.conf
systemctl restart phweb

Dashboard mostra “Director inacessível”

status: director_unreachable

Causa. O binário bconsole não consegue se conectar ao Director. Causas comuns: Director não está em execução, endereço/porta incorretos no bconsole.conf, firewall bloqueando a porta 9101.
Solução:

# Verificar se o Director está em execução
systemctl status bacula-dir

# Testar bconsole manualmente como usuário phweb
sudo -u phweb /opt/bacula/bin/bconsole -c /opt/bacula/etc/bconsole.conf &lt;&lt;&lt; "status director"

Botão “Aplicar” do Config Studio está acinzentado

Causa. PHWEB_CONFIG_APPLY_ENABLED não está definido como 1 no arquivo de ambiente.
Solução: Edite /etc/phweb/phweb.env, defina PHWEB_CONFIG_APPLY_ENABLED=1 e reinicie o serviço.

Migração de banco de dados falha na inicialização

error: migration 0003 failed: column "tenant_id" already exists

Causa. O banco de dados foi parcialmente migrado por uma versão anterior.
Solução: Conecte-se ao banco PostgreSQL e verifique a tabela _sqlx_migrations. Remova o registro da migração com falha e reexecute com --migrate-only.

Página WASM carrega mas mostra conteúdo em branco após hidratação

Causa. Incompatibilidade de locale entre SSR e hidratação. A página foi renderizada em PT-BR no servidor mas o localStorage do browser retornou EN.
Solução: Este é um problema conhecido e resolvido (Fase A da expansão do dashboard). Certifique-se de estar rodando PHWEB 0.2.86 ou posterior.

14.2 Locais dos logs

Log	Local
Log de aplicação PHWEB	`journalctl -u phweb -f`
Log de acesso nginx	`/var/log/nginx/access.log`
Log de erro nginx	`/var/log/nginx/error.log`
Log PostgreSQL	`/var/log/postgresql/postgresql-*.log`
Debug bconsole	Inline no log de aplicação PHWEB; habilite com `PHWEB_LOG_LEVEL=debug`

14.3 Habilitando logging de debug

Defina PHWEB_LOG_LEVEL=debug em /etc/phweb/phweb.env e reinicie PHWEB. Isso registra cada invocação bconsole e sua saída bruta, todas as verificações RBAC e eventos de sessão. O modo debug gera volume significativo de logs — desabilite-o quando o problema for resolvido.

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

15.1 Operações diárias do administrador — equipe de TI de PME

Cenário. Uma empresa de manufatura com 200 funcionários roda Bacula Community protegendo 45 servidores Linux e 12 File Daemons Windows. A equipe de TI de três administradores precisa monitorar backups noturnos, responder a falhas e atender solicitações de restore de usuários — tudo sem exigir expertise em bconsole.

Solução.

PHWEB implantado em VM dedicada ao lado do Bacula Director.
Todos os três administradores têm o papel de operator.
Revisão noturna: 5 minutos no Control Center identifica jobs com falha; cards de explicabilidade fornecem causa raiz e etapas de correção sem exigir conhecimento de bconsole.
Solicitações de restore: operadores de helpdesk usam o Restore Studio para navegar pelo histórico de backup e iniciar restores de arquivos self-service, sem escalonamento para administradores sênior.
Relatório semanal agendado enviado automaticamente por e-mail: taxa de sucesso de jobs, tendência de uso de storage, conformidade de SLA.

15.2 Restore self-service pelo helpdesk

Cenário. Um escritório de advocacia tem requisito rígido de que restores de arquivos de usuários finais devem ser concluídos em até 2 horas da solicitação. A equipe de helpdesk não tem treinamento em Bacula.

Solução.

Usuários de helpdesk são provisionados com o papel helpdesk no PHWEB — acesso somente ao Restore Studio.
Eles selecionam o client, escolhem uma data da timeline de backup, navegam até os arquivos necessários e clicam em Restore — tudo por uma interface guiada de três painéis.
Tempo médio de iniciação de restore: menos de 3 minutos para equipe de helpdesk treinada.
Todas as ações de restore são registradas em audit log com identidade do usuário e timestamp.

15.3 Dashboard executivo — relatórios de SLO

Cenário. O CTO de uma organização de saúde precisa de um relatório mensal de conformidade de backup mostrando o cumprimento de RPO/RTO em todos os workloads protegidos, para fins regulatórios.

Solução.

O CTO é provisionado com o papel readonly no PHWEB.
Um relatório agendado é executado no primeiro dia de cada mês, gerando um PDF com taxa de sucesso de jobs, conformidade de SLO por workload e tendência de crescimento de storage.
O relatório é enviado automaticamente por e-mail ao CTO e arquivado no módulo de Relatórios.
O dashboard de SLO fornece uma visão ao vivo do RPO/RTO atual por serviço a qualquer momento.

15.4 MSP gerenciando múltiplos ambientes de clientes

Cenário. Um provedor de serviços gerenciados administra implantações Bacula para 15 clientes diferentes, cada um com seu próprio Director, storage e requisitos de isolamento.

Solução.

Cada cliente é um tenant separado no PHWEB, com seu próprio bconsole.conf e registro de Director.
Engenheiros do MSP têm acesso administrativo cross-tenant para gestão de configuração.
Contatos dos clientes têm acesso somente leitura ao dashboard e relatórios do seu próprio tenant.
Módulo de Billing (Fase 5, futuro): medição automatizada por unidade por tenant para faturamento.

15.5 Rollout de plugin PodHeitor — ambiente vSphere

Cenário. Uma organização está implantando o plugin podheitor-vsphere em um ambiente vSphere de 200 VMs e precisa validar conectividade, configurar parâmetros do FileSet e testar o restore antes do rollout em produção.

Solução.

O Plugin Hub detecta o plugin podheitor-vsphere instalado e mostra sua versão e status de saúde.
O administrador clica em “Configurar” → preenche o formulário dinâmico (hostname do vCenter, usuário, senha, datacenter, glob de seleção de VMs, modo de transporte) → clica em “Testar Conexão” — PHWEB valida credenciais e conectividade antes de salvar.
O administrador cria um FileSet usando o assistente do Backup Studio — a string Plugin é gerada automaticamente a partir dos valores validados do formulário.
O Restore Studio mostra um painel de restore específico para VM para jobs de backup que usaram esse plugin.

16. Comparação com outras abordagens

16.1 PHWEB vs Bacularis

Dimensão	PHWEB	Bacularis
Stack tecnológico	Rust (Axum + Leptos), binário único	PHP + Apache/nginx, múltiplos arquivos
Paridade com BWeb	Completa (todos os módulos)	Parcial (~70%)
Suporte a plugins PodHeitor	Nativo (11 plugins, formulários dinâmicos)	Nenhum
Segurança na gestão de config	Pipeline transacional de 11 etapas + rollback	Edição direta de arquivo, sem rollback
RBAC / multi-tenant	RBAC + isolamento por tenant	Gestão básica de usuários
MFA	TOTP (built-in)	Não disponível
AI Copilot	Sim	Não
Mapa de topologia	Sim (Cytoscape.js ao vivo)	Não
Métricas Prometheus	Sim	Não
UI multilíngue	PT-BR / EN / ES	Somente EN (traduções parciais)
Licença	Comercial	Comercial — Proprietary (Copyright Heitor Faria)

16.2 PHWEB vs BWeb (Bacula Enterprise)

Dimensão	PHWEB + Bacula Community	BWeb + Bacula Enterprise
Custo de licenciamento	Licença comercial PHWEB + Community (gratuito)	Licença Enterprise (custo anual significativo)
Motor Bacula	Bacula Community (totalmente open source)	Bacula Enterprise (funcionalidades closed source)
UI de plugin PodHeitor	Nativa (11 plugins)	Nenhuma (somente strings Plugin)
Segurança do pipeline de config	Transacional de 11 etapas + rollback	Apply direto, sem UI de rollback
AI Copilot	Sim	Não
DR Center	Sim (assistente completo de failover)	Parcial
Stack tecnológico	Rust (moderno, binário único)	Perl/CGI (legado)
Dependência de comunidade	Nenhuma (autocontido)	Lock-in com fornecedor Enterprise

16.3 Comparação estimada de custos

Solução	Estimativa anual (50 clients)	Notas
PHWEB + Bacula Community	Somente licença PHWEB	Sem taxas Bacula por client
Bacularis + Bacula Community	Gratuito (mas funcionalidades limitadas)	Custo de suporte interno não incluído
BWeb + Bacula Enterprise	Premium significativo	Licenciamento Enterprise por client
Veeam / Commvault / NetBackup	Muito alto	Precificação por socket ou por VM

Contate heitor@opentechs.lat para uma cotação específica e comparação head-to-head com sua proposta de renovação atual.

17. Roadmap

PHWEB está pronto para produção na versão 0.2.86 com todas as 5 principais fases de funcionalidades concluídas (Foundation, BWeb Parity, Config Full, PodHeitor Native, Intelligence). A direção de desenvolvimento futuro inclui:

Fase 5 — Módulo de Billing. Medição por unidade protegida, licenciamento API-first, serial key offline opcional para ambientes air-gapped, relatórios financeiros por tenant. Cronograma depende de decisão de estratégia comercial.
Canal de notificação WhatsApp. Integração nativa com WhatsApp Business API (Twilio ou direto) para entrega de alertas. Arquitetura está no lugar; aguardando decisão de API key e provedor.
App mobile companion. Notificações de incidentes e fluxos de aprovação crítica (aprovação 4-eyes de config) em iOS e Android.
Pacotes ARM64. Pacotes binários para aarch64 para suporte a servidores ARM de classe Raspberry Pi e cloud-native.
Policy as Code. Definições de políticas de backup versionadas com histórico de diff, suporte a branches e fluxos de aprovação estilo merge-request.
Compliance packs. Templates de políticas LGPD / GDPR / HIPAA pré-construídos e geração automatizada de relatórios de conformidade.
Automação de DR drills. Drills de failover automatizados e agendados com pontuação, critérios de aprovação/reprovação e relatórios de prontidão para executivos.
Marketplace. Templates de políticas, templates de relatórios e assistentes de onboarding contribuídos pela comunidade.
Integração com HashiCorp Vault. Gestão externa de segredos para senhas bconsole, credenciais de plugins e chaves de API de AI em ambientes enterprise.

Nenhuma data específica de lançamento está comprometida. A direção das funcionalidades é guiada pelo feedback dos clientes e descobertas de laboratório.

18. Conclusão

PHWEB fecha o gap de interface de gerenciamento de longa data no ecossistema Bacula Community. Entrega o conjunto completo de funcionalidades operacionais do Bacula Enterprise BWeb — dashboard, gestão de jobs, restore BVFS, gestão de storage, administração de usuários e gestão de configuração — enquanto adiciona capacidades que nenhuma interface Bacula comercial oferece atualmente: um pipeline transacional de configuração de 11 etapas com rollback em 1 clique, configuração nativa de plugins PodHeitor através de formulários dinâmicos validados, um AI Copilot, um diagrama de topologia ao vivo e um endpoint de métricas Prometheus.

Construído inteiramente em Rust, PHWEB é um único binário implantável sem dependência de runtime PHP, Python ou Node.js. Conecta-se a qualquer instalação do Bacula Community a partir da versão 9.x através da interface padrão bconsole, sem necessidade de alterações na configuração do Bacula. A segurança operacional está incorporada desde o primeiro endpoint: senhas Argon2id, MFA TOTP, RBAC por tenant, audit log imutável append-only e proteção CSRF seguindo as melhores práticas OWASP em toda a aplicação.

Na versão 0.2.86 com 279 testes automatizados e uma implantação em produção ao vivo no Bacula 15.0.3, PHWEB não é um protótipo ou prova de conceito — é a interface de gerenciamento mais completa e mais moderna disponível para o Bacula Community hoje.

Para começar:

Solicite uma demo ou download: https://podheitor.com
Solicite uma cotação: heitor@opentechs.lat
Telefone / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Licenciamento

PodHeitor Web Interface (PHWEB) é software proprietário, distribuído por assinatura. Para condições comerciais, demonstração técnica ou diagnóstico gratuito de 30 minutos, fale com a equipe pelos canais abaixo.

Pronto para avaliar?

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

19. Informações de contato

Autor	Heitor Faria
Empresa	PodHeitor International
Website	https://podheitor.com
E-mail	heitor@opentechs.lat
Telefone / WhatsApp	+1 786 726-1749
Telefone / WhatsApp (BR)	+55 61 98268-4220
Página do produto	https://podheitor.com/phweb
Suporte	heitor@opentechs.lat

20. Legal / direitos autorais

PHWEB — PodHeitor Web Interface é software proprietário. Cópia, distribuição, modificação ou engenharia reversa não autorizada é estritamente proibida. Uma licença comercial é necessária para uso em produção.

Bacula® é marca registrada de Kern Sibbald e da comunidade Bacula. Todas as demais marcas são propriedade de seus respectivos detentores.

Este documento é fornecido para fins informativos. Valores de desempenho são provenientes de medições em laboratório controlado e podem variar em ambientes de produção dependendo de hardware, condições de rede, configuração do Bacula e tamanho do ambiente.

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

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