Blog

Technical Whitepaper — Version 0.1.0 — May 2026

Author: Heitor Faria · Website: https://podheitor.com · Email: heitor@opentechs.lat · Phone / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Special offer. Bring your renewal proposal for any commercial enterprise backup platform — Veeam, Commvault, NetBackup, or others. We will benchmark a head-to-head proposal targeting at least 50% savings with a modern, complete web interface for Bacula. Contact heitor@opentechs.lat for a written quote.

Table of contents

1. Executive summary
2. Introduction & market context
3. Architecture overview
4. Feature deep dive
5. Feature matrix
6. Installation guide
7. Configuration reference
8. Configuration examples
9. Sizing & capacity planning
10. Performance report
11. Compatibility matrix
12. Security
13. Monitoring
14. Troubleshooting guide
15. Use cases & deployment scenarios
16. Comparison with other approaches
17. Roadmap
18. Conclusion
19. Contact information
20. Legal / copyright

---

1. Executive summary

Bacula Community Edition is one of the most widely deployed open-source backup platforms in the world, protecting hundreds of thousands of servers across enterprises, universities, public sector organisations, and managed service providers. Yet its administration has historically depended on direct CLI interaction with bconsole, hand-editing configuration files, and an ageing optional web interface that does not reflect the usability standards of modern SaaS platforms. Administrators who need to manage hundreds of clients, orchestrate complex restore workflows, or configure the growing family of PodHeitor plugins are left with fragile scripts and steep operational risk.

PHWEB — PodHeitor Web Interface changes that. PHWEB is a production-grade, full-stack Rust web application that provides a modern, task-oriented management console for Bacula Community Edition. It delivers complete operational parity with Bacula Enterprise BWeb — the commercial reference for Bacula web management — while adding first-class support for all PodHeitor plugins, a transactional configuration pipeline with 1-click rollback, an AI Copilot, live topology diagrams, and a pluggable architecture designed to grow into multi-tenant MSP deployments.

Built on Axum (backend) and Leptos 0.7 (frontend, compiled to WASM), PHWEB is a single deployable binary with no Node.js, no Python runtime, and no PHP stack. It connects to the Bacula Director via the standard bconsole interface — compatible with every Bacula Community version from 9.x onwards — and persists its own metadata in PostgreSQL. A full REST API is exposed for automation and integration with external monitoring platforms.

PHWEB has reached version 0.2.86 with 162 development phases completed, 279 automated test cases passing, and a live deployment running on Bacula 15.0.3 in a production lab environment. The interface covers 42 functional modules from dashboard to AI Copilot, and supports three languages (PT-BR, EN, ES) natively. For any organisation running Bacula Community, PHWEB is the most complete, most cost-effective path to a defensible, modern management interface.

---

2. Introduction & market context

2.1 The Bacula Community management gap

Bacula Community Edition provides exceptional backup engine capabilities: multi-platform client support, advanced scheduling, pool and volume management, a rich FileSet language, and a plugin API that enables deep integration with hypervisors, databases, and storage systems. What it does not provide out of the box is a modern administrative interface.

The standard interface is bconsole: a line-by-line interactive CLI that requires administrators to memorise command syntax, interpret semi-structured text output, and edit ASCII configuration files with a text editor. For expert users on small environments, this is workable. For helpdesk operators who need to initiate a file restore, for executives who need a status dashboard, or for organisations with dozens of clients and complex plugin configurations, the raw CLI is a liability — not a feature.

The result is a well-documented market gap: organisations running Bacula Community either invest heavily in scripting and manual procedures to compensate for the missing UI layer, or they pay for Bacula Enterprise BWeb, a commercial interface that adds significant licensing cost. A third option — migrating to a different backup platform — introduces far greater cost and operational risk than the UI problem it was meant to solve.

2.2 Existing UI options and their limitations

Solution	Summary	Key limitations
bconsole (CLI)	Standard Bacula CLI	No GUI, steep learning curve, no self-service restore
Bacularis	Open-source PHP web UI	PHP stack, partial BWeb parity, no PodHeitor plugin support, limited RBAC
BWeb (Bacula Enterprise)	Commercial Perl/CGI UI bundled with Enterprise	Requires Enterprise license, no Community support, significant additional cost
Custom dashboards (Grafana + scripts)	Ad-hoc monitoring	Read-only, no restore, no config management, high maintenance burden

None of these options delivers the full combination of: open-source-compatible deployment, complete BWeb-parity feature coverage, native PodHeitor plugin configuration, transactional config management with rollback, and an enterprise-grade RBAC and audit trail.

2.3 The PHWEB approach

PHWEB is built on three core principles:

1. BWeb parity first. No feature that BWeb provides is left behind. Every capability — job management, restore, storage, pools, volumes, autochanger, reporting, ACL — is covered before any PHWEB-specific extension is added.
2. PodHeitor-native. PHWEB has first-class knowledge of all PodHeitor plugins via the Plugin Hub contract. Administrators configure plugins through validated forms, not by typing Plugin strings manually.
3. Mission-critical safety. Configuration changes follow an 11-stage transactional pipeline: draft, syntactic validation, semantic validation, ACL check, impact analysis, approval (4-eyes optional), atomic apply, reload, smoke tests, monitoring, and automatic rollback if SLO is violated.

---

3. Architecture overview

3.1 Full-stack Rust: Axum + Leptos

PHWEB is a full-stack Rust application. The backend runs on Axum, a high-performance async HTTP framework. The frontend is compiled from Rust to WebAssembly using Leptos 0.7, a reactive component framework with server-side rendering and seamless hydration. Both halves share types via the phweb-core crate, eliminating entire categories of serialisation bugs that plague heterogeneous frontend/backend stacks.

The build produces a single self-contained binary (phweb-server) plus a static site directory. No Node.js, no Python, no PHP interpreter is required at runtime.

Layer	Technology	Role
Backend	Axum + tokio	REST API, server functions, Bacula integration, plugin hub
Frontend	Leptos 0.7 (WASM)	Reactive SPA with SSR hydration
Shared types	phweb-core (Rust)	Models, API types, errors — used by both halves
Database	PostgreSQL + SQLx	Metadata, audit log, sessions, plugin registry
Styling	Tailwind CSS	Utility-first CSS, compiled at build time
Charts	charming (ECharts)	Operational graphs and dashboards
Topology	Cytoscape.js (wasm-bindgen)	Live topology diagram

3.2 Bacula Director integration

PHWEB connects to one or more Bacula Directors via the standard bconsole subprocess interface. The BaculaControlPlane module abstracts the protocol behind a Rust trait, making the underlying transport swappable without affecting any module above it. In the current implementation:

• Commands are dispatched as bconsole stdin-piped invocations.
• When the Director supports it (Bacula 9.x+), .api 2 mode is used for JSON output.
• Fallback parsers handle legacy text output for older Directors.
• Each tenant uses an isolated bconsole.conf; credentials are never exposed via the API.
• Timeouts are enforced per command type: status 5s, list 30s, restore 120s.

4. Feature deep dive

4.1 Control Center (Dashboard)

The Control Center is the operational home screen. It provides a unified view of backup health across the entire environment without requiring the operator to run a single bconsole command.

• KPI cards: jobs running, jobs completed, jobs failed in the last 24 hours; Director, Storage Daemon, and Client reachability LEDs.
• Explainability cards: when a component is unhealthy, PHWEB renders a plain-language card explaining what is wrong, why it matters, and what the recommended corrective action is.
• Incremental health card: tracks CBT/RCT baseline status per client; surfaces drift requiring a forced Full backup.
• Job trend chart: 7-day job success/failure ratio plotted with ECharts.
• SLO compliance indicators: per-service RPO/RTO status with threshold alerting.

4.2 Backup Operations (Job management)

The Backup Operations module provides complete job lifecycle management:

• List all jobs with rich filters: status, client, pool, schedule, date range, plugin type.
• Run a job manually with parameter override (level, pool, storage).
• Cancel an active job with confirmation workflow.
• View the full job log in real time (polling, 5s interval).
• Backup Studio drag-and-drop: drag workloads onto policies; simulate retention windows and storage cost before committing.
• Onboarding wizard per workload type: VM, database, SFTP agentless, file replication.

4.3 Restore Studio

The Restore Studio eliminates the need to know BVFS commands. It guides operators through a three-panel interface:

1. Left panel: client selector + list of available backup jobs (with date, level, and plugin type).
2. Centre panel: BVFS directory tree with breadcrumb navigation; click to browse; files listed after entering a directory.
3. Right panel: restore basket showing selected files/directories; restore options (target client, path, strip prefix); Start Restore button.

Additional restore flows:

• VM restore: full VM restore or granular file-level restore from a VM image backup, with cross-hypervisor migration wizard (vSphere ↔ Proxmox ↔ Hyper-V).
• PostgreSQL PITR Studio: visual timeline of WAL-continuous restore points; strategy selector (DUMP, PITR, PITR_BLOCK); WAL continuity validation before restore; post-restore checklist.
• Database full restore: dump-mode restore for any supported database plugin.

4.4 Config Studio

Config Studio is the mission-critical configuration management module. It replaces direct file editing with a structured, safe workflow:

• Structured editor: form-based editing for all Bacula resource types — Director, Client, Storage, Pool, FileSet, Job, JobDefs, Schedule, Messages, Console, Catalog, Device, Collector, Tenant.
• Text editor mode: for advanced users, a plain-text editor with syntax highlighting is available as an optional alternative.
• Visual diff: every proposed change shows a colour-coded diff against the current running configuration.
• 11-stage pipeline: Draft → Syntax Validation → Semantic Validation (cross-reference check) → ACL/Policy Check → Impact Analysis (active jobs, referenced resources) → Approval (4-eyes for critical changes) → Atomic Apply → Reload → Smoke Tests → Monitoring → Automatic Rollback if SLO is violated.
• 1-click rollback: the pre-apply snapshot is always stored; rollback restores the file and reloads the Director automatically.

4.5 Plugin Hub — PodHeitor plugin configuration

The Plugin Hub provides a unified configuration interface for all PodHeitor plugins. Instead of typing a Plugin string manually, operators use a validated form generated from each plugin’s JSON Schema:

• Plugin discovery and registry with version and health status.
• Dynamic form rendering per plugin: fields grouped by category (Connectivity, Selection, Performance, Advanced); sensitive fields masked; enum fields rendered as dropdowns; multi-value fields rendered as tag inputs.
• Connectivity test before saving configuration.
• Automatic serialisation to the correct Plugin = "..." string for the FileSet.
• Supported plugins: vSphere, Hyper-V, Proxmox, CloudStack, PostgreSQL, SFTP agentless, File Replication, Global Deduplication, Active Ransomware Detection, Incremental Accelerator, Granular Restore.

4.6 Reports & Analytics

• Built-in reports: jobs by period, storage usage, SLA compliance, deduplication ratio, replication RPO/RTO, policy coverage.
• Custom report builder with drag-and-drop field selection.
• Export: CSV, PDF, JSON.
• Scheduled delivery: email, webhook, Telegram, WhatsApp.
• Data Explorer: ad-hoc query builder with multi-axis plotting and saved dashboards.

4.7 DR & Replication Center

• Replication state per workload with RPO tracking.
• Guided failover wizard: test failover, planned failover, unplanned failover, failback — each with a pre-flight checklist and post-action validation.
• DR drill scheduling and readiness scoring.
• Blast radius visualisation: before executing a failover, see which downstream services are affected.

4.8 Security & Ransomware module

• Risk score dashboard with timeline of detected anomalies.
• Automated alert actions: isolate job, notify operator, trigger DR snapshot.
• Independent toggle for Active Ransomware Detection and Incremental Accelerator per tenant.
• Whitelist management and per-directory threshold tuning.

4.9 AI Copilot

• Natural-language operational queries: “why did job X fail?”, “what is the current RPO for client Y?”.
• Change plan generation with risk score and explainability log.
• Command and configuration explanation.
• Assisted remote terminal with guardrails — dangerous commands require confirmation.

4.10 Topology Live Map

A live diagram of the Bacula environment rendered via Cytoscape.js. Shows Directors, Storage Daemons, File Daemons, plugins, network paths, and dependency relationships. Reachability LEDs update in real time. Clicking any node opens its detail panel inline.

---

5. Feature matrix

Feature	PHWEB	Bacularis (free)	BWeb (Enterprise)
Dashboard with job KPIs	Yes	Yes	Yes
Job management (run/cancel/log)	Yes	Yes	Yes
BVFS restore (file browser)	Yes	Yes	Yes
VM granular restore	Yes	No	Yes
Cross-hypervisor migration wizard	Yes	No	Limited
PostgreSQL PITR Studio	Yes	No	No
Storage / pool / volume management	Yes	Yes	Yes
Full Bacula configuration editor	Yes	Partial	Yes
Transactional config pipeline + rollback	Yes	No	No
PodHeitor plugin configuration UI	Yes (11 plugins)	No	No
Plugin connectivity test	Yes	No	No
RBAC with per-tenant isolation	Yes	Limited	Yes
MFA (TOTP)	Yes	No	Yes
Immutable audit log (PostgreSQL)	Yes	No	Yes
Prometheus /metrics endpoint	Yes	No	No
Scheduled reports with delivery	Yes	No	Yes
DR & Replication Center	Yes	No	Limited
Ransomware detection UI	Yes	No	No
Deduplication observability	Yes	No	Limited
AI Copilot	Yes	No	No
Live topology map	Yes	No	No
Data Explorer with custom dashboards	Yes	No	Limited
Remote agent deployment	Yes	No	Yes
Multi-language UI (PT/EN/ES)	Yes	No	No
Single binary deployment (no PHP/Python)	Yes	No (PHP)	No (Perl/CGI)
Bacula Community compatible	Yes	Yes	No
Open source	No (commercial)	Yes	No

---

6. Installation guide

6.1 Prerequisites

Requirement	Details
Operating system	RHEL 9 / Rocky 9 / AlmaLinux 9 · Ubuntu 22.04+ · Debian 12+
Architecture	x86_64
Bacula Community	9.x or later (15.x recommended)
PostgreSQL	14 or later (for PHWEB metadata; separate from Bacula catalog)
nginx (recommended)	Reverse proxy for TLS termination and static asset serving
RAM	Minimum 512 MB; 2 GB recommended for production
Disk	2 GB for binary and site files; additional for PostgreSQL data

6.2 RPM installation (RHEL / Rocky / AlmaLinux)

# Add the PodHeitor repository
curl -fsSL https://podheitor.com/rpm/podheitor.repo -o /etc/yum.repos.d/podheitor.repo

# Install PHWEB
dnf install -y podheitor-phweb

# Initialise the database
sudo -u postgres createuser phweb
sudo -u postgres createdb -O phweb phweb
export DATABASE_URL="postgres://phweb:CHANGEME@localhost/phweb"
/opt/phweb/bin/phweb-server --migrate-only

# Enable and start the service
systemctl enable --now phweb

6.3 DEB installation (Ubuntu / Debian)

# Add the PodHeitor repository
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

# Initialise the database (same as RPM above)
export DATABASE_URL="postgres://phweb:CHANGEME@localhost/phweb"
/opt/phweb/bin/phweb-server --migrate-only

systemctl enable --now phweb

6.4 systemd unit

[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 nginx reverse proxy configuration

server {
    listen 443 ssl http2;
    server_name phweb.example.com;

    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 Bootstrap credentials

On first startup, PHWEB creates a default administrator account:

Username: admin
Password: admin

You will be required to change the password on first login. It is strongly recommended to enable MFA (TOTP) immediately after the password change.

---

7. Configuration reference

PHWEB is configured via environment variables or a phweb.env file placed in /etc/phweb/.

Parameter	Default	Description
DATABASE_URL	required	PostgreSQL connection string: postgres://user:pass@host/db
PHWEB_AUTO_MIGRATE	0	Set to 1 to run DB migrations automatically on startup
LEPTOS_SITE_ADDR	127.0.0.1:3001	Bind address for the PHWEB HTTP server
LEPTOS_OUTPUT_NAME	phweb	Name prefix for compiled assets; must match cargo-leptos.toml
PHWEB_CONFIG_APPLY_ENABLED	0	Set to 1 to allow Config Studio to apply changes to Bacula configuration files
PHWEB_SESSION_SECRET	auto-generated	Secret key for session cookie signing (32+ byte hex string recommended)
PHWEB_SESSION_MAX_AGE_SECS	86400	Session cookie lifetime in seconds (default: 24 hours)
PHWEB_BCONSOLE_BIN	/opt/bacula/bin/bconsole	Absolute path to the bconsole binary
PHWEB_BCONSOLE_CONF	/opt/bacula/etc/bconsole.conf	Default bconsole.conf path (overridden per Director in the database)
PHWEB_METRICS_ENABLED	1	Expose Prometheus metrics at /metrics
PHWEB_LOG_LEVEL	info	Log verbosity: trace, debug, info, warn, error
PHWEB_AI_BACKEND_URL	unset	Optional URL for external AI model endpoint (AI Copilot feature)
PHWEB_AI_API_KEY	unset	API key for the AI backend (stored in secrets vault, never logged)

---

8. Configuration examples

8.1 Minimal single-Director setup

# /etc/phweb/phweb.env

DATABASE_URL=postgres://phweb:strongpassword@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 Production setup with TLS (behind nginx) and metrics

# /etc/phweb/phweb.env

DATABASE_URL=postgres://phweb:prod_secret@db.internal/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 Multi-Director MSP environment

PHWEB supports multiple Directors registered through the Administration UI. Each Director record stores its own bconsole configuration, tenant assignment, and TLS settings. No environment variables are needed for the additional Directors beyond the base setup.

# Base environment (as in example 8.2)
# Additional directors are added via:
# Administration > Directors > Add Director

# Example Director record (stored in phweb.phweb_directors table):
# name:            "client-acme-dir"
# host:            "192.168.100.10"
# port:            9101
# bconsole_config: "/etc/phweb/bconsole-acme.conf"
# tenant_id:       2
# tls_enabled:     true

8.4 High-debug environment for troubleshooting

# /etc/phweb/phweb.env

DATABASE_URL=postgres://phweb:devpassword@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 Read-only monitoring mode (no config apply)

# /etc/phweb/phweb.env

DATABASE_URL=postgres://phweb_ro:readonly_pass@db.internal/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 With AI Copilot enabled

# /etc/phweb/phweb.env (add to any base config)

PHWEB_AI_BACKEND_URL=https://api.provider.example/v1
PHWEB_AI_API_KEY=sk-prod-xxxxxxxxxxxxxxxxxxx

---

9. Sizing & capacity planning

9.1 Component sizing guidelines

Environment size	Directors	Clients	Recommended RAM	Recommended CPU	PostgreSQL storage
Small	1	Up to 50	1 GB	2 vCPU	10 GB
Medium	1–3	50–500	2 GB	4 vCPU	50 GB
Large	3–10	500–2000	4 GB	8 vCPU	200 GB
MSP / Enterprise	10+	2000+	8+ GB	16+ vCPU	500+ GB

9.2 PostgreSQL storage breakdown

PHWEB’s PostgreSQL database stores interface metadata — it does not replicate the Bacula catalog. The main contributors to storage growth are:

• Audit log: approximately 500 bytes per logged action. At 10,000 actions per day, this grows at roughly 1.8 GB per year.
• Session store: small; sessions expire automatically.
• Plugin registry cache: negligible (JSON schemas, a few KB per plugin).
• Config change proposals: each proposal stores a diff and rollback snapshot; average 5–20 KB per proposal.
• Scheduled report outputs: if stored locally rather than delivered externally, budget 1–10 MB per report.

9.3 High availability notes

PHWEB itself is stateless between requests (all state in PostgreSQL). For high-availability deployments, run two or more PHWEB instances behind a load balancer with session affinity, sharing a single PostgreSQL cluster with streaming replication.

---

10. Performance report

10.1 Page load times (lab measurement)

Page	First load (cold SSR)	Subsequent (hydrated)
Dashboard	320 ms	85 ms
Job list (500 jobs)	480 ms	120 ms
Restore Studio (BVFS browse)	410 ms	95 ms
Config Studio (full Director config)	550 ms	150 ms
Topology map (50 nodes)	620 ms	180 ms

Measurements taken on a 4-vCPU VM with 4 GB RAM, PostgreSQL on the same host, Bacula Director locally connected. Network latency between browser and server: <5 ms.

10.2 Concurrent user capacity

Concurrent users	CPU utilisation	Median response time	P99 response time
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 bconsole operation latency

Operation	Median latency	Notes
status director	420 ms	Includes subprocess spawn
list jobs (last 100)	310 ms	With .api 2 JSON mode
bvfs_lsdirs	180 ms	After bvfs_update cache built
run job	520 ms	Director acknowledgement only
reload	850 ms	Full Director config reload

10.4 Test coverage

Phase	Tests added	Cumulative total
Phase 0 (Foundation)	18	18
Phase 1 (Bweb Parity)	42	60
Phase 2 (Config Full)	38	98
Phase 3 (PodHeitor Native)	71	169
Phase 4 (Intelligence)	55	224
Branch-gap re-scout (phases 5–162)	55	279

---

11. Compatibility matrix

11.1 Operating system

OS	Architecture	Status
RHEL 9	x86_64	Supported
Rocky Linux 9	x86_64	Supported
AlmaLinux 9	x86_64	Supported
Ubuntu 22.04 LTS	x86_64	Supported
Ubuntu 24.04 LTS	x86_64	Supported
Debian 12	x86_64	Supported
RHEL 8 / CentOS 8	x86_64	Not tested (glibc < 2.34)
Ubuntu 20.04	x86_64	Not tested (glibc < 2.34)
ARM64 / aarch64	any	Not yet available

11.2 Bacula versions

Bacula version	Status	Notes
15.0.x	Fully supported (tested)	Primary target; .api 2 JSON mode available
13.0.x	Supported	.api 2 available; tested in compatibility mode
11.0.x	Supported (legacy)	Regex parser fallback used
9.x	Best-effort	Regex parser; some features may not be available
7.x and earlier	Not supported	Plugin API incompatibilities

11.3 Browsers

Browser	Minimum version	Status
Chrome / Chromium	100+	Supported
Firefox	100+	Supported
Safari	15+	Supported
Edge (Chromium)	100+	Supported
Internet Explorer	Any	Not supported

11.4 PodHeitor plugin compatibility

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

---

12. Security

12.1 Authentication

• Password hashing: Argon2id with default cost parameters (memory: 64 MB, iterations: 3, parallelism: 4). Passwords are never stored in plaintext.
• MFA: TOTP (Time-based One-Time Password) with SHA-1, 6 digits, 30-second step. QR code generated server-side for enrollment. MFA is optional but strongly recommended for all accounts.
• Sessions: cookie-based with HttpOnly, SameSite=Lax, and Secure (in production). Session tokens are stored in PostgreSQL and expire after 24 hours by default (configurable via PHWEB_SESSION_MAX_AGE_SECS).

12.2 RBAC

PHWEB implements Role-Based Access Control with per-tenant isolation:

Built-in role	Capabilities
admin	Full access: all modules, all tenants, user management, config apply
operator	Job management, restore initiation, monitoring; no config apply, no user management
helpdesk	Restore Studio only; read-only dashboard; no job run/cancel
readonly	Dashboard and reports only; no actions

Custom roles can be defined with granular per-resource, per-action permissions. All permission checks are enforced server-side by the policy engine — the frontend disables UI elements accordingly but the backend independently validates every request.

12.3 Audit log

Every authenticated action is recorded in an append-only audit log table in PostgreSQL:

audit_log (
  id          BIGSERIAL PRIMARY KEY,
  user_id     UUID NOT NULL,
  action      TEXT NOT NULL,       -- e.g. "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()
)

The table has no UPDATE or DELETE permissions for the application role — entries are immutable once written. An index on timestamp DESC supports efficient time-range queries. Audit entries are paginated and filterable in the Administration module.

12.4 CSRF protection

All state-changing requests require a valid CSRF token derived from the session secret. Leptos server functions handle this automatically via the Axum middleware stack.

12.5 OWASP alignment

OWASP Top 10 risk	PHWEB mitigation
Broken Access Control	Per-request server-side ACL check; tenant isolation on all queries
Cryptographic Failures	Argon2id passwords; TLS enforced; secrets in env vars, never in code
Injection	SQLx parameterised queries; bconsole command allowlist; no string interpolation
Insecure Design	11-stage config pipeline; 4-eyes approval for critical changes
Security Misconfiguration	Secure defaults (PHWEB_CONFIG_APPLY_ENABLED=0 by default); no debug endpoints in prod
Vulnerable Components	Rust memory safety; automated dependency scanning in CI (cargo-audit)
Auth & Session Failures	Argon2id + TOTP + HttpOnly cookies + session expiry
SSRF	bconsole.conf paths validated; external URLs in AI Copilot require explicit allowlist

12.6 Secrets management

PHWEB never stores secrets (API keys, bconsole passwords, AI API keys) in the database in plaintext. All sensitive configuration is injected via environment variables or a secrets management system. A future integration with HashiCorp Vault is planned for Phase 5 (Enterprise edition).

---

13. Monitoring

13.1 Prometheus metrics

When PHWEB_METRICS_ENABLED=1, PHWEB exposes a Prometheus-compatible /metrics endpoint. The following metric families are available:

Metric	Type	Description
phweb_http_requests_total	Counter	Total HTTP requests by method, path, and status code
phweb_http_request_duration_seconds	Histogram	HTTP request latency distribution
phweb_bconsole_commands_total	Counter	bconsole invocations by command type and result
phweb_bconsole_command_duration_seconds	Histogram	bconsole command latency distribution
phweb_active_sessions	Gauge	Current number of active sessions
phweb_audit_events_total	Counter	Audit log entries written, by action
phweb_config_proposals_total	Counter	Configuration proposals by final status
phweb_bacula_jobs_running	Gauge	Bacula jobs currently running (polled)
phweb_bacula_jobs_failed_last_24h	Gauge	Bacula jobs that failed in the last 24 hours

13.2 Health check

A lightweight health endpoint is available at GET /health:

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

This endpoint does not require authentication and is suitable for load balancer health probes and external monitoring integrations (UptimeRobot, Nagios, Zabbix).

13.3 Structured logging

PHWEB emits structured JSON logs to stdout (captured by systemd journal). Each log entry includes timestamp, level, module path, request ID, user ID (when authenticated), and tenant ID. Logs can be forwarded to any log aggregation system (Loki, Elasticsearch, Splunk) using standard syslog or journal-based forwarding.

---

14. Troubleshooting guide

14.1 Common issues

PHWEB starts but bconsole commands fail silently

phweb: bconsole command failed: (empty stderr)

Cause. The PHWEB service user does not have read permission on the bconsole configuration file.
Fix: Ensure the service user is in the bacula group and that bconsole.conf is group-readable.

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

Dashboard shows “Director unreachable”

status: director_unreachable

Cause. The bconsole binary cannot connect to the Director. Common causes: Director is not running, wrong address/port in bconsole.conf, firewall blocking port 9101.
Fix:

# Verify Director is running
systemctl status bacula-dir

# Test bconsole manually as the phweb user
sudo -u phweb /opt/bacula/bin/bconsole -c /opt/bacula/etc/bconsole.conf <<< "status director"

Config Studio “Apply” button is greyed out

Cause. PHWEB_CONFIG_APPLY_ENABLED is not set to 1 in the environment file.
Fix: Edit /etc/phweb/phweb.env, set PHWEB_CONFIG_APPLY_ENABLED=1, and restart the service.

Database migration fails on startup

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

Cause. The database was partially migrated by a previous version.
Fix: Connect to the PostgreSQL database and check the _sqlx_migrations table. Remove the failed migration record and re-run with --migrate-only.

WASM page loads but shows blank content after hydration

Cause. SSR and hydration locale mismatch. The page rendered in PT-BR on the server but the browser localStorage returned EN.
Fix: This is a known resolved issue (Phase A of the dashboard expansion). Ensure you are running PHWEB 0.2.86 or later.

14.2 Log locations

Log	Location
PHWEB application log	journalctl -u phweb -f
nginx access log	/var/log/nginx/access.log
nginx error log	/var/log/nginx/error.log
PostgreSQL log	/var/log/postgresql/postgresql-*.log
bconsole debug	Inline in PHWEB application log; enable with PHWEB_LOG_LEVEL=debug

14.3 Enabling debug logging

Set PHWEB_LOG_LEVEL=debug in /etc/phweb/phweb.env and restart PHWEB. This logs every bconsole invocation and its raw output, all RBAC checks, and session events. Debug mode generates significant log volume — disable it when the issue is resolved.

---

15. Use cases & deployment scenarios

15.1 Daily admin operations — SME IT team

Scenario. A 200-employee manufacturing company runs Bacula Community protecting 45 Linux servers and 12 Windows File Daemons. The IT team of three administrators needs to monitor nightly backups, respond to failures, and handle restore requests from users — all without requiring bconsole expertise.

Solution.

• PHWEB deployed on a dedicated VM alongside the Bacula Director.
• All three administrators have the operator role.
• Nightly review: 5 minutes on the Control Center dashboard identifies any failed jobs; explainability cards provide root cause and fix steps without requiring bconsole knowledge.
• Restore requests: helpdesk operators use the Restore Studio to browse backup history and initiate file restores self-service, with no escalation to senior admins.
• Scheduled weekly report emailed automatically: job success rate, storage usage trend, SLA compliance.

15.2 Helpdesk self-service restore

Scenario. A legal firm has a strict requirement that end-user file restores must be completed within 2 hours of the request. The helpdesk team has no Bacula training.

Solution.

• Helpdesk users are provisioned with the helpdesk role in PHWEB — Restore Studio access only.
• They select the client, choose a date from the backup timeline, browse to the required files, and click Restore — all through a guided three-panel interface.
• Average restore initiation time: under 3 minutes for trained helpdesk staff.
• All restore actions are audit-logged with user identity and timestamp.

15.3 Executive dashboard — SLO reporting

Scenario. The CTO of a healthcare organisation needs a monthly backup compliance report showing RPO/RTO achievement across all protected workloads, for regulatory purposes.

Solution.

• The CTO is provisioned with the readonly role in PHWEB.
• A scheduled report runs on the first day of each month, generating a PDF showing job success rate, SLO compliance per workload, and storage growth trend.
• The report is emailed automatically to the CTO and archived in the Reports module.
• The SLO dashboard provides a live view of current RPO/RTO per service at any time.

15.4 MSP managing multiple customer environments

Scenario. A managed service provider manages Bacula deployments for 15 different customers, each with their own Director, storage, and isolation requirements.

Solution.

• Each customer is a separate tenant in PHWEB, with their own bconsole.conf and Director registration.
• MSP engineers have cross-tenant admin access for configuration management.
• Customer contacts have read-only access to their own tenant’s dashboard and reports only.
• Billing module (Phase 5, future): automated per-unit metering per tenant for invoicing.

15.5 PodHeitor plugin rollout — vSphere environment

Scenario. An organisation is deploying the podheitor-vsphere plugin across a 200-VM vSphere environment and needs to validate connectivity, configure FileSet parameters, and test restore before production rollout.

Solution.

• Plugin Hub detects the installed podheitor-vsphere plugin and shows its version and health status.
• Admin clicks “Configure” → fills the dynamic form (vCenter hostname, username, password, datacenter, VM selection glob, transport mode) → clicks “Test Connection” — PHWEB validates credentials and connectivity before saving.
• Admin creates a FileSet using the Backup Studio wizard — the Plugin string is generated automatically from the validated form values.
• Restore Studio shows a VM-specific restore panel for backup jobs that used this plugin.

---

16. Comparison with other approaches

16.1 PHWEB vs Bacularis

Dimension	PHWEB	Bacularis
Technology stack	Rust (Axum + Leptos), single binary	PHP + Apache/nginx, multi-file
BWeb parity	Complete (all modules)	Partial (~70%)
PodHeitor plugin support	Native (11 plugins, dynamic forms)	None
Config management safety	11-stage transactional pipeline + rollback	Direct file edit, no rollback
RBAC / multi-tenant	RBAC + per-tenant isolation	Basic user management
MFA	TOTP (built-in)	Not available
AI Copilot	Yes	No
Topology map	Yes (live Cytoscape.js)	No
Prometheus metrics	Yes	No
Multilingual UI	PT-BR / EN / ES	EN only (partial translations)
License	Commercial	Comercial — Proprietary (Copyright Heitor Faria)

16.2 PHWEB vs BWeb (Bacula Enterprise)

Dimension	PHWEB + Bacula Community	BWeb + Bacula Enterprise
Licensing cost	PHWEB commercial license + Community (free)	Enterprise license (significant annual cost)
Bacula engine	Bacula Community (fully open source)	Bacula Enterprise (closed source features)
PodHeitor plugin UI	Native (11 plugins)	None (plugin strings only)
Config pipeline safety	11-stage transactional + rollback	Direct apply, no rollback UI
AI Copilot	Yes	No
DR Center	Yes (full failover wizard)	Partial
Tech stack	Rust (modern, single binary)	Perl/CGI (legacy)
Community dependence	None (self-contained)	Enterprise vendor lock-in

16.3 Estimated cost comparison

Solution	Annual estimate (50 clients)	Notes
PHWEB + Bacula Community	PHWEB license only	No per-client Bacula fees
Bacularis + Bacula Community	Free (but limited features)	Internal support cost not included
BWeb + Bacula Enterprise	Significant premium	Per-client Enterprise licensing
Veeam / Commvault / NetBackup	Very high	Per-socket or per-VM pricing

Contact heitor@opentechs.lat for a specific quote and head-to-head comparison against your current renewal proposal.

---

17. Roadmap

PHWEB is production-ready at version 0.2.86 with all 5 major phases of features complete (Foundation, BWeb Parity, Config Full, PodHeitor Native, Intelligence). Future development direction includes:

• Phase 5 — Billing module. Per-protected-unit metering, API-first licensing, optional offline serial key for air-gapped environments, financial reporting per tenant. Timeline depends on commercial strategy decision.
• WhatsApp notification channel. Native integration with WhatsApp Business API (Twilio or direct) for alert delivery. Architecture is in place; awaiting API key and provider decision.
• Mobile companion app. Incident notifications and critical approval flows (4-eyes config approval) on iOS and Android.
• ARM64 packages. Binary packages for aarch64 to support Raspberry Pi-class and cloud-native ARM servers.
• Policy as Code. Version-controlled backup policy definitions with diff history, branch support, and merge-request-style approval workflows.
• Compliance packs. Pre-built LGPD / GDPR / HIPAA policy templates and automated compliance report generation.
• DR drill automation. Scheduled automated failover drills with scoring, pass/fail criteria, and executive-ready readiness reports.
• Marketplace. Community-contributed policy templates, report templates, and onboarding wizards.
• HashiCorp Vault integration. External secrets management for bconsole passwords, plugin credentials, and AI API keys in enterprise environments.

No specific release dates are committed. Feature direction is guided by customer feedback and lab findings.

---

18. Conclusion

PHWEB closes the long-standing management interface gap in the Bacula Community ecosystem. It delivers the complete operational feature set of Bacula Enterprise BWeb — dashboard, job management, BVFS restore, storage management, user administration, and configuration management — while adding capabilities that no commercial Bacula interface currently offers: a 11-stage transactional configuration pipeline with 1-click rollback, native PodHeitor plugin configuration through validated dynamic forms, an AI Copilot, a live topology diagram, and a Prometheus metrics endpoint.

Built entirely in Rust, PHWEB is a single deployable binary with no PHP, Python, or Node.js runtime dependency. It connects to any Bacula Community installation from version 9.x onwards through the standard bconsole interface, requiring no changes to the Bacula configuration. Operational security is built in from the first endpoint: Argon2id passwords, TOTP MFA, per-tenant RBAC, an immutable append-only audit log, and CSRF protection that follows OWASP best practices throughout.

At version 0.2.86 with 279 automated tests and a live production deployment on Bacula 15.0.3, PHWEB is not a prototype or a proof of concept — it is the most complete, most modern management interface available for Bacula Community today.

To get started:

• Request a demo or download: https://podheitor.com
• Request a quote: heitor@opentechs.lat
• Phone / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Licensing

PodHeitor Web Interface (PHWEB) is proprietary software distributed by subscription. For commercial terms, technical demo, or a free 30-minute assessment, reach the team via the channels below.

Ready to evaluate?

• 💬 WhatsApp: +1 (786) 726-1749
• ✉️ Email: heitor@opentechs.lat
• 🩺 Free assessment — 30 min with Heitor Faria

---

19. Contact information

Author	Heitor Faria
Company	PodHeitor International
Website	https://podheitor.com
Email	heitor@opentechs.lat
Phone / WhatsApp	+1 786 726-1749
Phone / WhatsApp (BR)	+55 61 98268-4220
Product page	https://podheitor.com/phweb
Support	heitor@opentechs.lat

---

20. Legal / copyright

© 2026 Heitor Faria — PodHeitor International — all rights reserved.

PHWEB — PodHeitor Web Interface is proprietary software. Unauthorised copying, distribution, modification, or reverse engineering is strictly prohibited. A commercial license is required for production use.

Bacula® is a registered trademark of Kern Sibbald and the Bacula community. All other trademarks are the property of their respective owners.

This document is provided for informational purposes. Performance figures are from controlled lab measurements and may vary in production environments depending on hardware, network conditions, Bacula configuration, and environment size.

Contact for licensing: heitor@opentechs.lat | https://podheitor.com | +1 786 726-1749 | +55 61 98268-4220

---

PHWEB — PodHeitor Web Interface for Bacula — v0.2.86 — © 2026 Heitor Faria — PodHeitor International — all rights reserved — https://podheitor.com

Disponível em: Português (Portuguese (Brazil))EnglishEspañol (Spanish)