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

Interfaz web PodHeitor unificada. Catálogo, jobs, restore wizards, dashboards Prometheus integrados — una UI para operación, sin PHP ni CGI legados.

UI moderna en Rust — backend HTTP/2, frontend SPA, sub-100ms en acciones comunes.
Restore wizard — usuario avanza por pasos, sin comandos bconsole.
Dashboards Prometheus — métricas nativas exportadas, sin scraping externo.
RBAC granular — quién puede restaurar qué, scope por cliente / pool / storage.
Multi-tenancy — cada cliente ve solo sus jobs, audit log inmutable.

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

Solicitar trial gratuito de 30 días →

Tabla de contenidos

Resumen ejecutivo
Introducción y contexto de mercado
Visión general de la arquitectura
Análisis detallado de funcionalidades
Matriz de funcionalidades
Guía de instalación
Referencia de configuración
Ejemplos de configuración
Dimensionamiento y planificación de capacidad
Informe de rendimiento
Matriz de compatibilidad
Seguridad
Monitoreo
Guía de resolución de problemas
Casos de uso y escenarios de despliegue
Comparación con otras alternativas
Hoja de ruta
Conclusión
Información de contacto
Legal / derechos de autor

1. Resumen ejecutivo

PodHeitor Backup Edition es una de las plataformas de backup de código abierto más ampliamente desplegadas en el mundo, protegiendo cientos de miles de servidores en empresas, universidades, organismos del sector público y proveedores de servicios gestionados. Sin embargo, su administración ha dependido históricamente de la interacción directa con la CLI mediante bconsole, la edición manual de archivos de configuración y una obsoleta interfaz web opcional que no refleja los estándares de usabilidad de las plataformas SaaS modernas. Los administradores que necesitan gestionar cientos de clientes, orquestar flujos de trabajo complejos de restauración o configurar la creciente familia de plugins PodHeitor se ven obligados a recurrir a scripts frágiles y enfrentan un elevado riesgo operacional.

PHWEB — PodHeitor Web Interface cambia todo eso. PHWEB es una aplicación web Rust de pila completa y nivel de producción que ofrece una consola de gestión moderna y orientada a tareas para PodHeitor Backup Edition. Proporciona paridad operacional completa con Bacula Enterprise BWeb — la referencia comercial para la gestión web de Bacula — al tiempo que agrega soporte de primera clase para todos los plugins PodHeitor, un pipeline de configuración transaccional con reversión en 1 clic, un Copiloto de IA, diagramas de topología en tiempo real y una arquitectura extensible diseñada para escalar hacia despliegues MSP multi-inquilino.

Construido sobre Axum (backend) y Leptos 0.7 (frontend, compilado a WASM), PHWEB es un único binario desplegable sin Node.js, sin entorno de ejecución Python ni stack PHP. Se conecta al Director de Bacula a través de la interfaz estándar bconsole — compatible con todas las versiones de PodHeitor Backup desde la 9.x en adelante — y persiste sus propios metadatos en PostgreSQL. Se expone una REST API completa para automatización e integración con plataformas externas de monitoreo.

PHWEB ha alcanzado la versión 0.2.86 con 162 fases de desarrollo completadas, 279 casos de prueba automatizados aprobados y un despliegue en vivo ejecutándose sobre Bacula 15.0.3 en un entorno de laboratorio de producción. La interfaz cubre 42 módulos funcionales, desde el dashboard hasta el Copiloto de IA, y soporta tres idiomas (PT-BR, EN, ES) de forma nativa. Para cualquier organización que ejecute PodHeitor Backup, PHWEB es el camino más completo y rentable hacia una interfaz de gestión moderna y defendible.

2. Introducción y contexto de mercado

2.1 La brecha en la gestión de PodHeitor Backup

PodHeitor Backup Edition ofrece capacidades de motor de backup excepcionales: soporte para clientes multiplataforma, programación avanzada, gestión de pools y volúmenes, un rico lenguaje de FileSet y una API de plugins que permite una integración profunda con hipervisores, bases de datos y sistemas de almacenamiento. Lo que no proporciona de manera predeterminada es una interfaz administrativa moderna.

La interfaz estándar es bconsole: una CLI interactiva línea por línea que requiere que los administradores memoricen la sintaxis de los comandos, interpreten la salida de texto semiestructurado y editen archivos de configuración ASCII con un editor de texto. Para usuarios expertos en entornos pequeños, esto es manejable. Para operadores de helpdesk que necesitan iniciar una restauración de archivos, para ejecutivos que necesitan un dashboard de estado o para organizaciones con decenas de clientes y configuraciones complejas de plugins, la CLI sin procesar es una responsabilidad — no una funcionalidad.

El resultado es una brecha de mercado bien documentada: las organizaciones que ejecutan PodHeitor Backup invierten fuertemente en scripts y procedimientos manuales para compensar la ausencia de una capa de interfaz de usuario, o pagan por Bacula Enterprise BWeb, una interfaz comercial que añade un costo de licencia significativo. Una tercera opción — migrar a una plataforma de backup diferente — introduce un costo y un riesgo operacional mucho mayores que el problema de interfaz que pretendía resolver.

2.2 Opciones de interfaz existentes y sus limitaciones

Solución	Descripción	Limitaciones clave
bconsole (CLI)	CLI estándar de Bacula	Sin interfaz gráfica, curva de aprendizaje pronunciada, sin restauración de autoservicio
Bacularis	Interfaz web PHP de código abierto	Stack PHP, paridad parcial con BWeb, sin soporte para plugins PodHeitor, RBAC limitado
BWeb (Bacula Enterprise)	Interfaz comercial Perl/CGI incluida con Enterprise	Requiere licencia Enterprise, sin soporte para Community, costo adicional significativo
Dashboards personalizados (Grafana + scripts)	Monitoreo ad-hoc	Solo lectura, sin restauración, sin gestión de configuración, alto costo de mantenimiento

Ninguna de estas opciones ofrece la combinación completa de: despliegue compatible con código abierto, cobertura funcional completa con paridad BWeb, configuración nativa de plugins PodHeitor, gestión transaccional de configuración con reversión y un RBAC de nivel empresarial con registro de auditoría.

2.3 El enfoque de PHWEB

PHWEB se construye sobre tres principios fundamentales:

Paridad con BWeb primero. Ninguna funcionalidad que ofrece BWeb queda fuera. Cada capacidad — gestión de jobs, restauración, almacenamiento, pools, volúmenes, autochanger, reportes, ACL — está cubierta antes de añadir cualquier extensión propia de PHWEB.
Nativo para PodHeitor. PHWEB tiene conocimiento de primera clase de todos los plugins PodHeitor mediante el contrato del Plugin Hub. Los administradores configuran los plugins a través de formularios validados, no escribiendo strings de Plugin manualmente.
Seguridad de misión crítica. Los cambios de configuración siguen un pipeline transaccional de 11 etapas: borrador, validación sintáctica, validación semántica, verificación ACL, análisis de impacto, aprobación (4-ojos opcional), aplicación atómica, recarga, pruebas de humo, monitoreo y reversión automática si se viola el SLO.

3. Visión general de la arquitectura

3.1 Rust de pila completa: Axum + Leptos

PHWEB es una aplicación Rust de pila completa. El backend corre sobre Axum, un framework HTTP asíncrono de alto rendimiento. El frontend está compilado de Rust a WebAssembly mediante Leptos 0.7, un framework de componentes reactivos con renderizado en el servidor e hidratación sin interrupciones. Ambas mitades comparten tipos a través del crate phweb-core, eliminando categorías enteras de errores de serialización que afectan a los stacks heterogéneos de frontend/backend.

La compilación produce un único binario autocontenido (phweb-server) más un directorio de sitio estático. No se requiere Node.js, Python ni ningún intérprete PHP en tiempo de ejecución.

Capa	Tecnología	Función
Backend	Axum + tokio	REST API, funciones de servidor, integración con Bacula, plugin hub
Frontend	Leptos 0.7 (WASM)	SPA reactiva con hidratación SSR
Tipos compartidos	phweb-core (Rust)	Modelos, tipos de API, errores — usados por ambas mitades
Base de datos	PostgreSQL + SQLx	Metadatos, registro de auditoría, sesiones, registro de plugins
Estilos	Tailwind CSS	CSS de utilidades, compilado en tiempo de compilación
Gráficos	charming (ECharts)	Gráficos operacionales y dashboards
Topología	Cytoscape.js (wasm-bindgen)	Diagrama de topología en tiempo real

3.2 Integración con el Director de Bacula

PHWEB se conecta a uno o más Directores de Bacula a través de la interfaz de subproceso estándar bconsole. El módulo BaculaControlPlane abstrae el protocolo detrás de un trait de Rust, haciendo que el transporte subyacente sea intercambiable sin afectar a ningún módulo superior. En la implementación actual:

Los comandos se despachan como invocaciones de bconsole con stdin en modo pipe.
Cuando el Director lo soporta (Bacula 9.x+), se utiliza el modo .api 2 para salida JSON.
Los parsers de respaldo manejan la salida de texto heredado para Directores más antiguos.
Cada inquilino usa un bconsole.conf aislado; las credenciales nunca se exponen a través de la API.
Los tiempos de espera se aplican por tipo de comando: status 5s, list 30s, restauración 120s.

4. Análisis detallado de funcionalidades

4.1 Centro de Control (Dashboard)

El Centro de Control es la pantalla de inicio operacional. Proporciona una vista unificada del estado de backup en todo el entorno sin que el operador necesite ejecutar ningún comando de bconsole.

Tarjetas KPI: jobs en ejecución, jobs completados, jobs fallidos en las últimas 24 horas; LEDs de accesibilidad del Director, el Storage Daemon y los clientes.
Tarjetas de explicabilidad: cuando un componente está en mal estado, PHWEB muestra una tarjeta en lenguaje sencillo explicando qué está mal, por qué importa y cuál es la acción correctiva recomendada.
Tarjeta de salud incremental: rastrea el estado de la línea base CBT/RCT por cliente; detecta desviaciones que requieren un backup Full forzado.
Gráfico de tendencia de jobs: ratio de éxito/fallo de jobs de 7 días trazado con ECharts.
Indicadores de cumplimiento de SLO: estado de RPO/RTO por servicio con alertas por umbral.

4.2 Operaciones de Backup (Gestión de jobs)

El módulo de Operaciones de Backup proporciona una gestión completa del ciclo de vida de los jobs:

Listar todos los jobs con filtros enriquecidos: estado, cliente, pool, programación, rango de fechas, tipo de plugin.
Ejecutar un job manualmente con anulación de parámetros (nivel, pool, almacenamiento).
Cancelar un job activo con flujo de confirmación.
Ver el log completo del job en tiempo real (polling, intervalo de 5s).
Backup Studio con arrastrar y soltar: arrastre cargas de trabajo hacia políticas; simule ventanas de retención y costo de almacenamiento antes de confirmar.
Asistente de incorporación por tipo de carga de trabajo: VM, base de datos, SFTP sin agente, replicación de archivos.

4.3 Restore Studio

El Restore Studio elimina la necesidad de conocer los comandos BVFS. Guía a los operadores a través de una interfaz de tres paneles:

Panel izquierdo: selector de cliente + lista de jobs de backup disponibles (con fecha, nivel y tipo de plugin).
Panel central: árbol de directorios BVFS con navegación por migas de pan; clic para explorar; archivos listados al entrar en un directorio.
Panel derecho: cesta de restauración con los archivos/directorios seleccionados; opciones de restauración (cliente destino, ruta, eliminar prefijo); botón Iniciar Restauración.

Flujos de restauración adicionales:

Restauración de VM: restauración completa de VM o restauración granular a nivel de archivo desde un backup de imagen de VM, con asistente de migración entre hipervisores (vSphere ↔ Proxmox ↔ Hyper-V).
PostgreSQL PITR Studio: línea de tiempo visual de puntos de restauración continua WAL; selector de estrategia (DUMP, PITR, PITR_BLOCK); validación de continuidad WAL antes de restaurar; lista de verificación post-restauración.
Restauración completa de base de datos: restauración en modo dump para cualquier plugin de base de datos soportado.

4.4 Config Studio

Config Studio es el módulo de gestión de configuración de misión crítica. Reemplaza la edición directa de archivos por un flujo de trabajo estructurado y seguro:

Editor estructurado: edición basada en formularios para todos los tipos de recursos de Bacula — Director, Client, Storage, Pool, FileSet, Job, JobDefs, Schedule, Messages, Console, Catalog, Device, Collector, Tenant.
Modo de editor de texto: para usuarios avanzados, un editor de texto plano con resaltado de sintaxis disponible como alternativa opcional.
Diferencia visual: cada cambio propuesto muestra una diferencia con codificación de colores respecto a la configuración en ejecución actual.
Pipeline de 11 etapas: Borrador → Validación Sintáctica → Validación Semántica (verificación de referencias cruzadas) → Verificación de ACL/Política → Análisis de Impacto (jobs activos, recursos referenciados) → Aprobación (4-ojos para cambios críticos) → Aplicación Atómica → Recarga → Pruebas de Humo → Monitoreo → Reversión Automática si se viola el SLO.
Reversión en 1 clic: la instantánea previa a la aplicación siempre se almacena; la reversión restaura el archivo y recarga el Director automáticamente.

4.5 Plugin Hub — Configuración de plugins PodHeitor

El Plugin Hub proporciona una interfaz de configuración unificada para todos los plugins PodHeitor. En lugar de escribir un Plugin string manualmente, los operadores utilizan un formulario validado generado a partir del esquema JSON de cada plugin:

Descubrimiento de plugins y registro con versión y estado de salud.
Renderizado dinámico de formularios por plugin: campos agrupados por categoría (Conectividad, Selección, Rendimiento, Avanzado); campos sensibles enmascarados; campos de enumeración renderizados como listas desplegables; campos de múltiples valores renderizados como entradas de etiquetas.
Prueba de conectividad antes de guardar la configuración.
Serialización automática al string correcto Plugin = "..." para el FileSet.
Plugins soportados: vSphere, Hyper-V, Proxmox, CloudStack, PostgreSQL, SFTP sin agente, Replicación de Archivos, Deduplicación Global, Detección Activa de Ransomware, Acelerador Incremental, Restauración Granular.

4.6 Reportes y Análisis

Reportes integrados: jobs por período, uso de almacenamiento, cumplimiento de SLA, ratio de deduplicación, RPO/RTO de replicación, cobertura de políticas.
Constructor de reportes personalizados con selección de campos mediante arrastrar y soltar.
Exportación: CSV, PDF, JSON.
Entrega programada: correo electrónico, webhook, Telegram, WhatsApp.
Data Explorer: constructor de consultas ad-hoc con trazado multi-eje y dashboards guardados.

4.7 Centro de DR y Replicación

Estado de replicación por carga de trabajo con seguimiento de RPO.
Asistente de failover guiado: failover de prueba, failover planificado, failover no planificado, failback — cada uno con una lista de verificación previa y validación posterior a la acción.
Programación de simulacros de DR y puntuación de preparación.
Visualización del radio de impacto: antes de ejecutar un failover, vea qué servicios dependientes se ven afectados.

4.8 Módulo de Seguridad y Ransomware

Dashboard de puntuación de riesgo con línea de tiempo de anomalías detectadas.
Acciones de alerta automatizadas: aislar job, notificar al operador, disparar instantánea de DR.
Interruptor independiente para Detección Activa de Ransomware y Acelerador Incremental por inquilino.
Gestión de listas blancas y ajuste de umbrales por directorio.

4.9 Copiloto de IA

Consultas operacionales en lenguaje natural: «¿por qué falló el job X?», «¿cuál es el RPO actual para el cliente Y?».
Generación de planes de cambio con puntuación de riesgo y registro de explicabilidad.
Explicación de comandos y configuraciones.
Terminal remota asistida con salvaguardas — los comandos peligrosos requieren confirmación.

4.10 Mapa de Topología en Tiempo Real

Un diagrama en tiempo real del entorno Bacula renderizado mediante Cytoscape.js. Muestra Directores, Storage Daemons, File Daemons, plugins, rutas de red y relaciones de dependencia. Los LEDs de accesibilidad se actualizan en tiempo real. Al hacer clic en cualquier nodo se abre su panel de detalles directamente.

5. Matriz de funcionalidades

Funcionalidad	PHWEB	Bacularis (gratuito)	BWeb (Enterprise)
Dashboard con KPIs de jobs	Sí	Sí	Sí
Gestión de jobs (ejecutar/cancelar/log)	Sí	Sí	Sí
Restauración BVFS (explorador de archivos)	Sí	Sí	Sí
Restauración granular de VM	Sí	No	Sí
Asistente de migración entre hipervisores	Sí	No	Limitado
PostgreSQL PITR Studio	Sí	No	No
Gestión de almacenamiento / pool / volumen	Sí	Sí	Sí
Editor completo de configuración de Bacula	Sí	Parcial	Sí
Pipeline de configuración transaccional + reversión	Sí	No	No
Interfaz de configuración de plugins PodHeitor	Sí (11 plugins)	No	No
Prueba de conectividad de plugins	Sí	No	No
RBAC con aislamiento por inquilino	Sí	Limitado	Sí
MFA (TOTP)	Sí	No	Sí
Registro de auditoría inmutable (PostgreSQL)	Sí	No	Sí
Endpoint Prometheus /metrics	Sí	No	No
Reportes programados con entrega	Sí	No	Sí
Centro de DR y Replicación	Sí	No	Limitado
Interfaz de detección de ransomware	Sí	No	No
Observabilidad de deduplicación	Sí	No	Limitado
Copiloto de IA	Sí	No	No
Mapa de topología en tiempo real	Sí	No	No
Data Explorer con dashboards personalizados	Sí	No	Limitado
Despliegue remoto de agentes	Sí	No	Sí
Interfaz multilingüe (PT/EN/ES)	Sí	No	No
Despliegue en binario único (sin PHP/Python)	Sí	No (PHP)	No (Perl/CGI)
Compatible con PodHeitor Backup	Sí	Sí	No
Código abierto	No (comercial)	Sí	No

6. Guía de instalación

6.1 Requisitos previos

Requisito	Detalles
Sistema operativo	RHEL 9 / Rocky 9 / AlmaLinux 9 · Ubuntu 22.04+ · Debian 12+
Arquitectura	x86_64
PodHeitor Backup	9.x o posterior (se recomienda 15.x)
PostgreSQL	14 o posterior (para metadatos de PHWEB; separado del catálogo de Bacula)
nginx (recomendado)	Proxy inverso para terminación TLS y servicio de archivos estáticos
RAM	Mínimo 512 MB; 2 GB recomendado para producción
Disco	2 GB para el binario y archivos del sitio; adicional para datos de PostgreSQL

6.2 Instalación RPM (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 Instalación DEB (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 Unidad 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 Configuración del proxy inverso nginx

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 Credenciales de inicio

En el primer arranque, PHWEB crea una cuenta de administrador predeterminada:

Username: admin
Password: admin

Se le solicitará cambiar la contraseña en el primer inicio de sesión. Se recomienda encarecidamente habilitar MFA (TOTP) inmediatamente después del cambio de contraseña.

7. Referencia de configuración

PHWEB se configura mediante variables de entorno o un archivo phweb.env ubicado en /etc/phweb/.

Parámetro	Valor predeterminado	Descripción
`DATABASE_URL`	requerido	Cadena de conexión PostgreSQL: `postgres://user:pass@host/db`
`PHWEB_AUTO_MIGRATE`	`0`	Establezca en `1` para ejecutar migraciones de BD automáticamente al iniciar
`LEPTOS_SITE_ADDR`	`127.0.0.1:3001`	Dirección de enlace para el servidor HTTP de PHWEB
`LEPTOS_OUTPUT_NAME`	`phweb`	Prefijo de nombre para los recursos compilados; debe coincidir con cargo-leptos.toml
`PHWEB_CONFIG_APPLY_ENABLED`	`0`	Establezca en `1` para permitir que Config Studio aplique cambios a los archivos de configuración de Bacula
`PHWEB_SESSION_SECRET`	autogenerado	Clave secreta para firma de cookies de sesión (se recomienda cadena hexadecimal de 32+ bytes)
`PHWEB_SESSION_MAX_AGE_SECS`	`86400`	Tiempo de vida de la cookie de sesión en segundos (predeterminado: 24 horas)
`PHWEB_BCONSOLE_BIN`	`/opt/bacula/bin/bconsole`	Ruta absoluta al binario de bconsole
`PHWEB_BCONSOLE_CONF`	`/opt/bacula/etc/bconsole.conf`	Ruta predeterminada a bconsole.conf (sobrescrita por Director en la base de datos)
`PHWEB_METRICS_ENABLED`	`1`	Exponer métricas Prometheus en `/metrics`
`PHWEB_LOG_LEVEL`	`info`	Verbosidad del log: `trace`, `debug`, `info`, `warn`, `error`
`PHWEB_AI_BACKEND_URL`	no definido	URL opcional para endpoint de modelo de IA externo (funcionalidad Copiloto de IA)
`PHWEB_AI_API_KEY`	no definido	Clave de API para el backend de IA (almacenada en bóveda de secretos, nunca registrada)

8. Ejemplos de configuración

8.1 Configuración mínima con un único Director

# /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 Configuración de producción con TLS (detrás de nginx) y métricas

# /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 Entorno MSP con múltiples Directores

PHWEB soporta múltiples Directores registrados a través de la interfaz de Administración. Cada registro de Director almacena su propia configuración de bconsole, asignación de inquilino y configuración TLS. No se necesitan variables de entorno adicionales para los Directores extra más allá de la configuración base.

# 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 Entorno de depuración avanzada para resolución de problemas

# /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 Modo de monitoreo de solo lectura (sin aplicar configuración)

# /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 Con Copiloto de IA habilitado

# /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. Dimensionamiento y planificación de capacidad

9.1 Guías de dimensionamiento de componentes

Tamaño del entorno	Directores	Clientes	RAM recomendada	CPU recomendada	Almacenamiento PostgreSQL
Pequeño	1	Hasta 50	1 GB	2 vCPU	10 GB
Mediano	1–3	50–500	2 GB	4 vCPU	50 GB
Grande	3–10	500–2000	4 GB	8 vCPU	200 GB
MSP / Empresarial	10+	2000+	8+ GB	16+ vCPU	500+ GB

9.2 Desglose del almacenamiento PostgreSQL

La base de datos PostgreSQL de PHWEB almacena metadatos de la interfaz — no replica el catálogo de Bacula. Los principales contribuyentes al crecimiento del almacenamiento son:

Registro de auditoría: aproximadamente 500 bytes por acción registrada. Con 10.000 acciones por día, crece a una tasa de aproximadamente 1,8 GB por año.
Almacén de sesiones: pequeño; las sesiones expiran automáticamente.
Caché del registro de plugins: insignificante (esquemas JSON, pocos KB por plugin).
Propuestas de cambios de configuración: cada propuesta almacena una diferencia y una instantánea de reversión; promedio de 5–20 KB por propuesta.
Salidas de reportes programados: si se almacenan localmente en lugar de entregarse externamente, presupueste 1–10 MB por reporte.

9.3 Notas de alta disponibilidad

PHWEB en sí mismo es sin estado entre solicitudes (todo el estado en PostgreSQL). Para despliegues de alta disponibilidad, ejecute dos o más instancias de PHWEB detrás de un balanceador de carga con afinidad de sesión, compartiendo un único cluster de PostgreSQL con replicación en flujo.

10. Informe de rendimiento

10.1 Tiempos de carga de páginas (medición en laboratorio)

Página	Primera carga (SSR en frío)	Siguientes (hidratada)
Dashboard	320 ms	85 ms
Lista de jobs (500 jobs)	480 ms	120 ms
Restore Studio (exploración BVFS)	410 ms	95 ms
Config Studio (configuración completa del Director)	550 ms	150 ms
Mapa de topología (50 nodos)	620 ms	180 ms

Mediciones realizadas en una VM de 4 vCPU con 4 GB de RAM, PostgreSQL en el mismo host, Director de Bacula conectado localmente. Latencia de red entre el navegador y el servidor: <5 ms.

10.2 Capacidad de usuarios concurrentes

Usuarios concurrentes	Utilización de CPU	Tiempo de respuesta mediano	Tiempo de respuesta 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 Latencia de operaciones bconsole

Operación	Latencia mediana	Notas
status director	420 ms	Incluye lanzamiento del subproceso
list jobs (last 100)	310 ms	Con modo JSON .api 2
bvfs_lsdirs	180 ms	Tras construcción de caché bvfs_update
run job	520 ms	Solo confirmación del Director
reload	850 ms	Recarga completa de la configuración del Director

10.4 Cobertura de pruebas

Fase	Pruebas añadidas	Total acumulado
Fase 0 (Fundación)	18	18
Fase 1 (Paridad BWeb)	42	60
Fase 2 (Configuración Completa)	38	98
Fase 3 (PodHeitor Nativo)	71	169
Fase 4 (Inteligencia)	55	224
Reconocimiento de ramas (fases 5–162)	55	279

11. Matriz de compatibilidad

11.1 Sistema operativo

SO	Arquitectura	Estado
RHEL 9	x86_64	Soportado
Rocky Linux 9	x86_64	Soportado
AlmaLinux 9	x86_64	Soportado
Ubuntu 22.04 LTS	x86_64	Soportado
Ubuntu 24.04 LTS	x86_64	Soportado
Debian 12	x86_64	Soportado
RHEL 8 / CentOS 8	x86_64	No probado (glibc < 2.34)
Ubuntu 20.04	x86_64	No probado (glibc < 2.34)
ARM64 / aarch64	cualquiera	Aún no disponible

11.2 Versiones de Bacula

Versión de Bacula	Estado	Notas
15.0.x	Totalmente soportado (probado)	Objetivo principal; modo JSON .api 2 disponible
13.0.x	Soportado	.api 2 disponible; probado en modo de compatibilidad
11.0.x	Soportado (heredado)	Se usa el parser de expresiones regulares de respaldo
9.x	Mejor esfuerzo	Parser de expresiones regulares; algunas funcionalidades pueden no estar disponibles
7.x y anteriores	No soportado	Incompatibilidades en la API de plugins

11.3 Navegadores

Navegador	Versión mínima	Estado
Chrome / Chromium	100+	Soportado
Firefox	100+	Soportado
Safari	15+	Soportado
Edge (Chromium)	100+	Soportado
Internet Explorer	Cualquiera	No soportado

11.4 Compatibilidad de plugins PodHeitor

Plugin	Interfaz Config PHWEB	Interfaz Restore PHWEB	Centro DR
podheitor-vsphere	Sí	Sí	Sí
podheitor-hyperv	Sí	Sí	Sí
podheitor-proxmox	Sí	Sí	Sí
podheitor-cloudstack	Sí	Sí	Limitado
podheitor-postgresql	Sí	Sí (PITR Studio)	No
podheitor-sftp	Sí	Sí	No
podheitor-file-replication	Sí	Sí	Sí
podheitor-global-dedup	Sí	N/A	No
podheitor-ransomware-detection	Sí	N/A	No
podheitor-incremental-accelerator	Sí	N/A	No
podheitor-granular-restore	Sí	Sí	No

12. Seguridad

12.1 Autenticación

Hash de contraseñas: Argon2id con parámetros de costo predeterminados (memoria: 64 MB, iteraciones: 3, paralelismo: 4). Las contraseñas nunca se almacenan en texto plano.
MFA: TOTP (Contraseña de Un Solo Uso Basada en Tiempo) con SHA-1, 6 dígitos, paso de 30 segundos. Código QR generado en el servidor para la inscripción. El MFA es opcional pero muy recomendado para todas las cuentas.
Sesiones: basadas en cookies con HttpOnly, SameSite=Lax y Secure (en producción). Los tokens de sesión se almacenan en PostgreSQL y expiran tras 24 horas de manera predeterminada (configurable mediante PHWEB_SESSION_MAX_AGE_SECS).

12.2 RBAC

PHWEB implementa Control de Acceso Basado en Roles con aislamiento por inquilino:

Rol integrado	Capacidades
admin	Acceso completo: todos los módulos, todos los inquilinos, gestión de usuarios, aplicación de configuración
operator	Gestión de jobs, inicio de restauración, monitoreo; sin aplicar configuración, sin gestión de usuarios
helpdesk	Solo Restore Studio; dashboard de solo lectura; sin ejecutar/cancelar jobs
readonly	Solo dashboard y reportes; sin acciones

Se pueden definir roles personalizados con permisos granulares por recurso y por acción. Todas las verificaciones de permisos se aplican en el servidor por el motor de políticas — el frontend deshabilita los elementos de interfaz correspondientes, pero el backend valida de manera independiente cada solicitud.

12.3 Registro de auditoría

Cada acción autenticada se registra en una tabla de registro de auditoría de solo anexar en 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()
)

La tabla no tiene permisos de UPDATE ni DELETE para el rol de la aplicación — las entradas son inmutables una vez escritas. Un índice sobre timestamp DESC admite consultas eficientes por rango de tiempo. Las entradas de auditoría están paginadas y son filtrables en el módulo de Administración.

12.4 Protección CSRF

Todas las solicitudes que modifican el estado requieren un token CSRF válido derivado del secreto de sesión. Las funciones de servidor de Leptos manejan esto automáticamente a través del stack de middleware de Axum.

12.5 Alineación con OWASP

Riesgo OWASP Top 10	Mitigación PHWEB
Control de Acceso Roto	Verificación ACL del lado del servidor por solicitud; aislamiento de inquilinos en todas las consultas
Fallos Criptográficos	Contraseñas Argon2id; TLS aplicado; secretos en variables de entorno, nunca en el código
Inyección	Consultas parametrizadas SQLx; lista de permitidos de comandos bconsole; sin interpolación de strings
Diseño Inseguro	Pipeline de configuración de 11 etapas; aprobación 4-ojos para cambios críticos
Mala Configuración de Seguridad	Valores predeterminados seguros (PHWEB_CONFIG_APPLY_ENABLED=0 por defecto); sin endpoints de depuración en producción
Componentes Vulnerables	Seguridad de memoria de Rust; análisis de dependencias automatizado en CI (cargo-audit)
Fallos de Autenticación y Sesión	Argon2id + TOTP + cookies HttpOnly + expiración de sesión
SSRF	Rutas de bconsole.conf validadas; las URL externas en el Copiloto de IA requieren lista de permitidos explícita

12.6 Gestión de secretos

PHWEB nunca almacena secretos (claves de API, contraseñas de bconsole, claves de API de IA) en texto plano en la base de datos. Toda la configuración sensible se inyecta mediante variables de entorno o un sistema de gestión de secretos. Una futura integración con HashiCorp Vault está planificada para la Fase 5 (edición Enterprise).

13. Monitoreo

13.1 Métricas Prometheus

Cuando PHWEB_METRICS_ENABLED=1, PHWEB expone un endpoint /metrics compatible con Prometheus. Están disponibles las siguientes familias de métricas:

Métrica	Tipo	Descripción
`phweb_http_requests_total`	Counter	Total de solicitudes HTTP por método, ruta y código de estado
`phweb_http_request_duration_seconds`	Histogram	Distribución de latencia de solicitudes HTTP
`phweb_bconsole_commands_total`	Counter	Invocaciones de bconsole por tipo de comando y resultado
`phweb_bconsole_command_duration_seconds`	Histogram	Distribución de latencia de comandos bconsole
`phweb_active_sessions`	Gauge	Número actual de sesiones activas
`phweb_audit_events_total`	Counter	Entradas de registro de auditoría escritas, por acción
`phweb_config_proposals_total`	Counter	Propuestas de configuración por estado final
`phweb_bacula_jobs_running`	Gauge	Jobs de Bacula actualmente en ejecución (sondeados)
`phweb_bacula_jobs_failed_last_24h`	Gauge	Jobs de Bacula que fallaron en las últimas 24 horas

13.2 Verificación de salud

Un endpoint de salud liviano está disponible en GET /health:

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

Este endpoint no requiere autenticación y es adecuado para sondeos de salud de balanceadores de carga e integraciones de monitoreo externas (UptimeRobot, Nagios, Zabbix).

13.3 Registro estructurado

PHWEB emite logs JSON estructurados a stdout (capturados por el journal de systemd). Cada entrada de log incluye timestamp, nivel, ruta del módulo, ID de solicitud, ID de usuario (cuando está autenticado) e ID de inquilino. Los logs pueden reenviarse a cualquier sistema de agregación de logs (Loki, Elasticsearch, Splunk) utilizando el reenvío estándar basado en syslog o journal.

14. Guía de resolución de problemas

14.1 Problemas comunes

PHWEB inicia pero los comandos bconsole fallan silenciosamente

phweb: bconsole command failed: (empty stderr)

Causa. El usuario del servicio PHWEB no tiene permiso de lectura sobre el archivo de configuración de bconsole.
Solución: Asegúrese de que el usuario del servicio esté en el grupo bacula y que bconsole.conf sea legible por el grupo.

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

El dashboard muestra «Director inaccesible»

status: director_unreachable

Causa. El binario bconsole no puede conectarse al Director. Causas comunes: el Director no está ejecutándose, dirección/puerto incorrectos en bconsole.conf, firewall bloqueando el puerto 9101.
Solución:

# 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"

El botón «Aplicar» de Config Studio está deshabilitado

Causa. PHWEB_CONFIG_APPLY_ENABLED no está establecido en 1 en el archivo de entorno.
Solución: Edite /etc/phweb/phweb.env, establezca PHWEB_CONFIG_APPLY_ENABLED=1 y reinicie el servicio.

La migración de la base de datos falla al iniciar

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

Causa. La base de datos fue migrada parcialmente por una versión anterior.
Solución: Conéctese a la base de datos PostgreSQL y verifique la tabla _sqlx_migrations. Elimine el registro de migración fallido y vuelva a ejecutar con --migrate-only.

La página WASM carga pero muestra contenido en blanco tras la hidratación

Causa. Discrepancia de configuración regional entre SSR e hidratación. La página se renderizó en PT-BR en el servidor pero el localStorage del navegador devolvió EN.
Solución: Este es un problema conocido y resuelto (Fase A de la expansión del dashboard). Asegúrese de ejecutar PHWEB 0.2.86 o posterior.

14.2 Ubicaciones de los logs

Log	Ubicación
Log de la aplicación PHWEB	`journalctl -u phweb -f`
Log de acceso nginx	`/var/log/nginx/access.log`
Log de errores nginx	`/var/log/nginx/error.log`
Log de PostgreSQL	`/var/log/postgresql/postgresql-*.log`
Depuración bconsole	Integrado en el log de la aplicación PHWEB; habilite con `PHWEB_LOG_LEVEL=debug`

14.3 Habilitar el registro de depuración

Establezca PHWEB_LOG_LEVEL=debug en /etc/phweb/phweb.env y reinicie PHWEB. Esto registra cada invocación de bconsole y su salida sin procesar, todas las verificaciones RBAC y los eventos de sesión. El modo de depuración genera un volumen de log significativo — desactívelo cuando el problema esté resuelto.

15. Casos de uso y escenarios de despliegue

15.1 Operaciones administrativas diarias — equipo TI de PyME

Escenario. Una empresa manufacturera de 200 empleados ejecuta PodHeitor Backup protegiendo 45 servidores Linux y 12 File Daemons Windows. El equipo de TI de tres administradores necesita monitorear los backups nocturnos, responder a fallos y gestionar solicitudes de restauración de los usuarios — todo ello sin requerir experiencia en bconsole.

Solución.

PHWEB desplegado en una VM dedicada junto al Director de Bacula.
Los tres administradores tienen el rol de operator.
Revisión nocturna: 5 minutos en el dashboard del Centro de Control identifica cualquier job fallido; las tarjetas de explicabilidad proporcionan la causa raíz y los pasos de corrección sin requerir conocimiento de bconsole.
Solicitudes de restauración: los operadores de helpdesk usan el Restore Studio para explorar el historial de backups e iniciar restauraciones de archivos de forma autónoma, sin escalar a administradores senior.
Reporte semanal programado enviado automáticamente por correo: tasa de éxito de jobs, tendencia de uso de almacenamiento, cumplimiento de SLA.

15.2 Restauración de autoservicio por helpdesk

Escenario. Un despacho legal tiene el requisito estricto de que las restauraciones de archivos de usuarios finales deben completarse dentro de las 2 horas de la solicitud. El equipo de helpdesk no tiene formación en Bacula.

Solución.

Los usuarios de helpdesk tienen el rol de helpdesk en PHWEB — solo acceso al Restore Studio.
Seleccionan el cliente, eligen una fecha de la línea de tiempo de backup, navegan hasta los archivos requeridos y hacen clic en Restaurar — todo a través de una interfaz guiada de tres paneles.
Tiempo promedio de inicio de restauración: menos de 3 minutos para personal de helpdesk capacitado.
Todas las acciones de restauración se registran en la auditoría con identidad del usuario y timestamp.

15.3 Dashboard ejecutivo — Reportes de SLO

Escenario. El CTO de una organización del sector salud necesita un reporte mensual de cumplimiento de backups que muestre el logro de RPO/RTO en todas las cargas de trabajo protegidas, con fines regulatorios.

Solución.

El CTO tiene el rol de readonly en PHWEB.
Un reporte programado se ejecuta el primer día de cada mes, generando un PDF con la tasa de éxito de jobs, cumplimiento de SLO por carga de trabajo y tendencia de crecimiento del almacenamiento.
El reporte se envía automáticamente por correo al CTO y se archiva en el módulo de Reportes.
El dashboard de SLO proporciona una vista en vivo del RPO/RTO actual por servicio en cualquier momento.

15.4 MSP gestionando múltiples entornos de clientes

Escenario. Un proveedor de servicios gestionados administra despliegues de Bacula para 15 clientes diferentes, cada uno con su propio Director, almacenamiento y requisitos de aislamiento.

Solución.

Cada cliente es un inquilino separado en PHWEB, con su propio bconsole.conf y registro de Director.
Los ingenieros del MSP tienen acceso de administrador entre inquilinos para la gestión de configuración.
Los contactos de clientes tienen acceso de solo lectura al dashboard y reportes de su propio inquilino únicamente.
Módulo de facturación (Fase 5, futuro): medición automatizada por unidad por inquilino para facturación.

15.5 Implementación del plugin PodHeitor — entorno vSphere

Escenario. Una organización está desplegando el plugin podheitor-vsphere en un entorno vSphere de 200 VMs y necesita validar la conectividad, configurar los parámetros del FileSet y probar la restauración antes del despliegue en producción.

Solución.

El Plugin Hub detecta el plugin podheitor-vsphere instalado y muestra su versión y estado de salud.
El administrador hace clic en «Configurar» → completa el formulario dinámico (hostname de vCenter, usuario, contraseña, datacenter, glob de selección de VM, modo de transporte) → hace clic en «Probar Conexión» — PHWEB valida las credenciales y la conectividad antes de guardar.
El administrador crea un FileSet mediante el asistente de Backup Studio — el string de Plugin se genera automáticamente a partir de los valores del formulario validado.
El Restore Studio muestra un panel de restauración específico de VM para los jobs de backup que usaron este plugin.

16. Comparación con otras alternativas

16.1 PHWEB vs Bacularis

Dimensión	PHWEB	Bacularis
Stack tecnológico	Rust (Axum + Leptos), binario único	PHP + Apache/nginx, múltiples archivos
Paridad BWeb	Completa (todos los módulos)	Parcial (~70%)
Soporte de plugins PodHeitor	Nativo (11 plugins, formularios dinámicos)	Ninguno
Seguridad en gestión de configuración	Pipeline transaccional de 11 etapas + reversión	Edición directa de archivos, sin reversión
RBAC / multi-inquilino	RBAC + aislamiento por inquilino	Gestión básica de usuarios
MFA	TOTP (integrado)	No disponible
Copiloto de IA	Sí	No
Mapa de topología	Sí (Cytoscape.js en tiempo real)	No
Métricas Prometheus	Sí	No
Interfaz multilingüe	PT-BR / EN / ES	Solo EN (traducciones parciales)
Licencia	Comercial	Comercial — Proprietary (Copyright Heitor Faria)

16.2 PHWEB vs BWeb (Bacula Enterprise)

Dimensión	PHWEB + PodHeitor Backup	BWeb + Bacula Enterprise
Costo de licencia	Licencia comercial PHWEB + Community (gratuito)	Licencia Enterprise (costo anual significativo)
Motor Bacula	PodHeitor Backup (completamente de código abierto)	Bacula Enterprise (funcionalidades de código cerrado)
Interfaz de plugins PodHeitor	Nativa (11 plugins)	Ninguna (solo strings de Plugin)
Seguridad del pipeline de configuración	Transaccional de 11 etapas + reversión	Aplicación directa, sin interfaz de reversión
Copiloto de IA	Sí	No
Centro de DR	Sí (asistente de failover completo)	Parcial
Stack tecnológico	Rust (moderno, binario único)	Perl/CGI (heredado)
Dependencia de proveedor	Ninguna (autocontenido)	Dependencia del proveedor Enterprise

16.3 Comparación de costos estimados

Solución	Estimación anual (50 clientes)	Notas
PHWEB + PodHeitor Backup	Solo licencia PHWEB	Sin tarifas de Bacula por cliente
Bacularis + PodHeitor Backup	Gratuito (pero funcionalidades limitadas)	Costo de soporte interno no incluido
BWeb + Bacula Enterprise	Prima significativa	Licenciamiento Enterprise por cliente
Veeam / Commvault / NetBackup	Muy elevado	Precios por socket o por VM

Contacte a heitor@opentechs.lat para una cotización específica y una comparación directa frente a su propuesta de renovación actual.

17. Hoja de ruta

PHWEB está listo para producción en la versión 0.2.86 con las 5 fases principales de funcionalidades completadas (Fundación, Paridad BWeb, Configuración Completa, PodHeitor Nativo, Inteligencia). La dirección futura del desarrollo incluye:

Fase 5 — Módulo de facturación. Medición por unidad protegida, licenciamiento centrado en API, clave de serie sin conexión opcional para entornos air-gapped, reportes financieros por inquilino. El cronograma depende de la decisión de estrategia comercial.
Canal de notificaciones WhatsApp. Integración nativa con la API de WhatsApp Business (Twilio o directa) para la entrega de alertas. La arquitectura está en su lugar; pendiente de clave de API y decisión del proveedor.
Aplicación móvil complementaria. Notificaciones de incidentes y flujos de aprobación críticos (aprobación de configuración 4-ojos) en iOS y Android.
Paquetes ARM64. Paquetes binarios para aarch64 para soportar servidores clase Raspberry Pi y ARM nativos en la nube.
Política como Código. Definiciones de políticas de backup con control de versiones, historial de diferencias, soporte de ramas y flujos de trabajo de aprobación estilo merge-request.
Paquetes de cumplimiento normativo. Plantillas de políticas preconfiguradas para LGPD / GDPR / HIPAA y generación automatizada de reportes de cumplimiento.
Automatización de simulacros de DR. Simulacros de failover automatizados programados con puntuación, criterios de aprobación/fallo y reportes de preparación listos para ejecutivos.
Marketplace. Plantillas de políticas, plantillas de reportes y asistentes de incorporación aportados por la comunidad.
Integración con HashiCorp Vault. Gestión de secretos externos para contraseñas de bconsole, credenciales de plugins y claves de API de IA en entornos empresariales.

No se comprometen fechas de lanzamiento específicas. La dirección de funcionalidades está guiada por el feedback de clientes y los hallazgos del laboratorio.

18. Conclusión

PHWEB cierra la brecha de interfaz de gestión que ha existido durante mucho tiempo en el ecosistema PodHeitor Backup. Proporciona el conjunto de funcionalidades operacionales completo de Bacula Enterprise BWeb — dashboard, gestión de jobs, restauración BVFS, gestión de almacenamiento, administración de usuarios y gestión de configuración — al tiempo que añade capacidades que ninguna interfaz comercial de Bacula ofrece actualmente: un pipeline de configuración transaccional de 11 etapas con reversión en 1 clic, configuración nativa de plugins PodHeitor a través de formularios dinámicos validados, un Copiloto de IA, un diagrama de topología en tiempo real y un endpoint de métricas Prometheus.

Construido íntegramente en Rust, PHWEB es un único binario desplegable sin dependencia de entorno de ejecución PHP, Python ni Node.js. Se conecta a cualquier instalación de PodHeitor Backup desde la versión 9.x en adelante a través de la interfaz estándar bconsole, sin requerir ningún cambio en la configuración de Bacula. La seguridad operacional está integrada desde el primer endpoint: contraseñas Argon2id, MFA TOTP, RBAC por inquilino, un registro de auditoría inmutable de solo añadir y protección CSRF que sigue las mejores prácticas de OWASP en toda la plataforma.

En la versión 0.2.86 con 279 pruebas automatizadas y un despliegue en producción en vivo sobre Bacula 15.0.3, PHWEB no es un prototipo ni una prueba de concepto — es la interfaz de gestión más completa y moderna disponible hoy para PodHeitor Backup.

Para comenzar:

Solicite una demo o descarga: https://podheitor.com
Solicite una cotización: heitor@opentechs.lat
Teléfono / WhatsApp: +1 786 726-1749 | +55 61 98268-4220

Licenciamiento

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

¿Listo para evaluar?

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

19. Información de contacto

Autor	Heitor Faria
Empresa	PodHeitor International
Sitio web	https://podheitor.com
Correo	heitor@opentechs.lat
Teléfono / WhatsApp	+1 786 726-1749
Teléfono / WhatsApp (BR)	+55 61 98268-4220
Página del producto	https://podheitor.com/phweb
Soporte	heitor@opentechs.lat

20. Legal / derechos de autor

PHWEB — PodHeitor Web Interface es software propietario. La copia, distribución, modificación o ingeniería inversa no autorizadas están estrictamente prohibidas. Se requiere una licencia comercial para su uso en producción.

Bacula® es una marca registrada de Kern Sibbald y la comunidad de Bacula. Todas las demás marcas registradas son propiedad de sus respectivos dueños.

Este documento se proporciona con fines informativos. Las cifras de rendimiento provienen de mediciones controladas en laboratorio y pueden variar en entornos de producción según el hardware, las condiciones de red, la configuración de Bacula y el tamaño del entorno.

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

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