Proxmox VE se ha consolidado como la alternativa de virtualización preferida de miles de empresas europeas, y con ese crecimiento ha llegado una pregunta inevitable: ¿cómo se protege correctamente un entorno Proxmox? La respuesta nativa se llama Proxmox Backup Server (PBS), una solución de backup empresarial diseñada por el mismo equipo que desarrolla el hipervisor y pensada desde el primer día para máquinas virtuales, contenedores LXC y hosts físicos.
A diferencia del clásico vzdump integrado en Proxmox VE, que genera copias completas en cada ejecución, PBS aplica los principios de las plataformas de backup modernas: deduplicación a nivel de bloque, backups incrementales forever, compresión zstd, cifrado en el cliente y verificación de integridad programada. El resultado es que retener semanas o meses de historial deja de ser un problema de espacio y las ventanas de backup se reducen a minutos.
En esta guía explicamos la arquitectura de PBS, sus políticas de retención y sync jobs, su integración con Proxmox VE, las buenas prácticas para una estrategia 3-2-1 sólida y una breve comparación con Veeam.
Qué es Proxmox Backup Server
Proxmox Backup Server es un producto independiente de Proxmox VE: se instala sobre Debian en su propio hardware (o como appliance dedicado) y expone una interfaz web propia, una API REST y un cliente de línea de comandos (proxmox-backup-client). Su núcleo está escrito en Rust, lo que le aporta rendimiento y seguridad de memoria en las rutas críticas de datos.
Aunque su integración estrella es con Proxmox VE, no se limita a él: el cliente de backup permite proteger también hosts Linux físicos a nivel de ficheros. El software es de código abierto (licencia AGPLv3) y la suscripción de pago da acceso al repositorio enterprise y al soporte oficial, sin recortar funcionalidad.
Arquitectura: Datastores, Chunks y Deduplicación
La unidad de almacenamiento de PBS es el datastore: un directorio sobre un sistema de ficheros local (habitualmente ZFS, ext4 o XFS) donde se guardan los backups. Dentro de cada datastore, los datos no se almacenan como ficheros de imagen monolíticos, sino como chunks: bloques de datos de en torno a 4 MiB identificados por su hash SHA-256.
Ese direccionamiento por contenido es la base de la deduplicación a nivel de bloque: si dos VMs comparten el mismo sistema operativo, sus chunks idénticos se almacenan una sola vez y todos los backups los referencian. En entornos homogéneos, los ratios de deduplicación de 10:1 a 30:1 son habituales. Cada chunk se comprime además con zstd, un algoritmo que ofrece ratios excelentes con un coste de CPU muy bajo, ideal para no penalizar la ventana de backup.
La tercera pieza es el cifrado en el cliente (client-side encryption): los chunks pueden cifrarse con AES-256-GCM antes de salir del host de origen, con una clave que solo posee el cliente. El servidor PBS almacena datos que no puede leer, lo que permite usar con tranquilidad un PBS remoto u hospedado por un tercero: ni el operador del servidor de backup tiene acceso al contenido. Custodiar esa clave (y una copia en papel del paper key) pasa a ser parte del plan de recuperación.
PBS incorpora además los namespaces: subdivisiones lógicas dentro de un mismo datastore para separar clientes, clústeres o entornos sin perder la deduplicación global. Son la pieza clave en escenarios multi-tenant y para proveedores de servicio.
Incrementales Forever y Verify Jobs
PBS implementa el modelo incremental forever: tras el primer backup completo, todas las copias posteriores solo transfieren los bloques que han cambiado. En VMs en ejecución, Proxmox VE utiliza el dirty bitmap de QEMU para saber exactamente qué bloques se han modificado desde el último backup, sin releer el disco completo. El resultado práctico: backups diarios (o cada pocas horas) que tardan minutos y consumen un ancho de banda mínimo.
Como cada snapshot referencia chunks compartidos, no existen las "cadenas" frágiles de incrementales tradicionales: cada backup es autocontenido a efectos de restauración y borrar uno antiguo no invalida los posteriores. El precio a pagar es que la salud de los chunks es crítica, y ahí entran los verify jobs: tareas programadas que releen los chunks, recalculan sus hashes SHA-256 y los comparan con los índices para detectar corrupción silenciosa (bit rot). Un snapshot verificado se marca en verde en la interfaz; uno corrupto se marca como fallido y el siguiente backup vuelve a subir los chunks dañados.
Regla práctica:
Un backup sin verificar es una hipótesis, no una garantía. Programa verify jobs semanales (o tras cada backup en datastores pequeños) y combínalos con re-verificación periódica de snapshots antiguos. La restauración que falla siempre se descubre el peor día posible.
Prune, Garbage Collection y Políticas de Retención
La retención en PBS se gestiona en dos fases. Primero, el prune job decide qué snapshots conservar según reglas keep-* y elimina las referencias del resto. Después, el garbage collection (GC) recorre el datastore y libera físicamente los chunks que ya no referencia ningún snapshot, respetando un periodo de gracia de 24 horas y 5 minutos para no interferir con backups en curso.
Las reglas de retención se combinan entre sí, tipo "abuelo-padre-hijo", y permiten expresar políticas complejas con pocos parámetros:
| Parámetro | Qué conserva | Ejemplo de valor |
|---|---|---|
| keep-last | Los N snapshots más recientes, sin importar la fecha | 3 |
| keep-hourly | El último snapshot de cada una de las N horas más recientes | 12 |
| keep-daily | El último snapshot de cada uno de los N días más recientes | 7 |
| keep-weekly | El último snapshot de cada una de las N semanas más recientes | 4 |
| keep-monthly | El último snapshot de cada uno de los N meses más recientes | 6 |
| keep-yearly | El último snapshot de cada uno de los N años más recientes | 2 |
Una política "3 últimos + 7 diarios + 4 semanales + 6 mensuales" cubre la mayoría de necesidades de una pyme y, gracias a la deduplicación, ocupa una fracción de lo que costaría con copias completas. Recuerda que prune solo marca: hasta que el GC no se ejecuta (conviene programarlo a diario o semanalmente), el espacio no se libera.
Sync Jobs: Replicación a un PBS Remoto y Regla 3-2-1
Un backup que vive en el mismo edificio que la infraestructura que protege no sobrevive a un incendio, una inundación o un ransomware que alcance la red local. PBS resuelve la copia externa con los sync jobs: tareas que replican snapshots entre datastores de dos servidores PBS, en modo pull (el remoto tira del origen, recomendable por seguridad) o push. Solo viajan los chunks que faltan en destino, de modo que replicar el incremental diario de decenas de VMs consume un ancho de banda muy razonable.
Con un PBS secundario en otra ubicación, la clásica regla 3-2-1 (tres copias, dos soportes distintos, una fuera de las instalaciones) se cumple de forma natural: producción + PBS local + PBS remoto. Como alternativa o complemento, los datastores pueden apoyarse en almacenamiento de objetos S3 como capa adicional para el archivo de largo plazo, y para quien necesita air gap físico o retención regulatoria de años, PBS incluye soporte de cinta (tape backup) nativo, con pools de medios, catálogo y cifrado LTO.
En EasyDataHost ofrecemos repositorios PBS hospedados en nuestro datacenter de España y almacenamiento S3 compatible para esa segunda o tercera copia; con el cifrado en cliente activado, tus datos llegan a nuestra infraestructura ya cifrados con tu clave.
Integración con Proxmox VE: Live-Restore y File-Level Restore
La integración con Proxmox VE es donde PBS brilla. El datastore se añade al clúster como un storage de tipo "Proxmox Backup Server" y los jobs de backup de VMs QEMU y contenedores LXC se programan desde la propia interfaz de PVE, con snapshots consistentes (guest agent mediante) y sin apagar las cargas. Las novedades recientes de la plataforma, que repasamos en nuestro artículo sobre las novedades de Proxmox VE 9, han seguido puliendo esta integración.
En restauración, PBS ofrece tres modos que cambian las reglas del juego. La restauración completa clásica recupera la VM o el contenedor a cualquier storage del clúster. El live-restore arranca la VM inmediatamente mientras sus discos se restauran en segundo plano: el servicio vuelve a estar en línea en segundos, aunque con rendimiento reducido hasta completar la copia. Y el file-level restore permite navegar por el contenido de un backup desde la interfaz web y descargar ficheros o directorios sueltos, sin restaurar la máquina entera, incluso sobre imágenes de disco de VMs.
Todo ello funciona igual sobre infraestructura propia que sobre plataformas hospedadas: nuestro cloud privado basado en Proxmox se entrega listo para conectar con un datastore PBS, de modo que la estrategia de backup nace con la plataforma y no como un añadido posterior.
Buenas Prácticas de Despliegue
PBS es sencillo de instalar, pero un despliegue serio exige algunas decisiones de arquitectura:
- check_circle Hardware separado: instala PBS en su propio servidor, nunca como VM dentro del clúster que protege. Si el clúster cae, el backup debe seguir en pie.
- check_circle No uses el mismo clúster como único destino: un datastore sobre el propio Ceph o ZFS del clúster protegido convierte cualquier fallo mayor en pérdida simultánea de datos y copias.
- check_circle Completa la 3-2-1 con copia offsite: sync job hacia un PBS remoto (o almacenamiento S3 para archivo) en otra ubicación física. La copia local acelera la restauración; la remota te salva del desastre.
- check_circle Cifra en cliente y custodia la clave: activa el cifrado para cualquier copia que salga de tu infraestructura y guarda la clave (y el paper key) fuera del propio entorno protegido.
- check_circle Prueba restauraciones: programa simulacros periódicos de restauración completa y de file-level restore. El verify job valida los datos; el simulacro valida el procedimiento.
PBS o Veeam: Cuál Elegir
Es la comparación inevitable, y la respuesta honesta depende del perímetro a proteger. Si tu entorno es 100% Proxmox, PBS es difícil de batir: integración nativa, incrementales vía dirty bitmap, live-restore, coste contenido y toda la cadena (hipervisor + backup) soportada por el mismo fabricante.
Si tu infraestructura es mixta —VMware o Hyper-V conviviendo con Proxmox, servidores físicos Windows y Linux—, Veeam sigue siendo la plataforma más completa: una única consola, un único licenciamiento y funcionalidades avanzadas de DR que PBS no cubre. Además, Veeam ya soporta Proxmox VE como hipervisor, una opción válida también durante migraciones.
En EasyDataHost no te obligamos a elegir por nosotros: ofrecemos ambos caminos, repositorios PBS hospedados para entornos Proxmox y backup offsite con Veeam Cloud Connect para entornos mixtos, siempre sobre infraestructura propia en España con certificación ISO 27001 y conformidad ENS.
Preguntas Frecuentes
¿Puedo instalar PBS en el mismo nodo que Proxmox VE?
Técnicamente sí, pero no es recomendable en producción: si el nodo falla, pierdes las VMs y sus copias a la vez. La buena práctica es hardware separado y, además, un sync job hacia un PBS remoto para cumplir la regla 3-2-1.
¿Cuánto espacio ahorra la deduplicación?
Depende de la homogeneidad de las cargas, pero con muchas VMs del mismo sistema operativo son habituales ratios de 10:1 a 30:1 o superiores. Como cada backup solo almacena chunks nuevos, meses de retención cuestan una fracción del dato original.
¿PBS sustituye a Veeam?
En entornos 100% Proxmox, PBS es la opción nativa más eficiente. En entornos mixtos con VMware, Hyper-V o servidores físicos, Veeam sigue siendo la plataforma más completa. EasyDataHost ofrece ambos caminos, así que puedes combinar lo mejor de cada uno.
Conclusión
Proxmox Backup Server ha convertido el backup de entornos Proxmox en un problema resuelto: tecnología moderna, operación sencilla y coste contenido. Las claves para sacarle todo el partido:
- arrow_right Arquitectura eficiente: chunks deduplicados, compresión zstd y cifrado en cliente reducen el almacenamiento y protegen la confidencialidad, incluso en repositorios de terceros.
- arrow_right Incrementales forever + verify jobs: ventanas de backup de minutos y verificación de integridad programada contra la corrupción silenciosa.
- arrow_right Retención con prune + GC: políticas keep-daily/weekly/monthly expresivas y liberación de espacio controlada.
- arrow_right 3-2-1 con sync jobs: PBS en hardware separado más réplica offsite a un PBS remoto o almacenamiento S3. Nunca el mismo clúster como único destino.
- arrow_right PBS para Proxmox puro, Veeam para entornos mixtos: dos herramientas excelentes con perímetros distintos. Elegir bien evita pagar de más o quedarse corto.
Si quieres montar una estrategia de backup para tu entorno Proxmox —repositorio PBS offsite, cloud privado con backup incluido o una combinación con Veeam—, contacta con nuestro equipo: analizamos tu caso y te proponemos la arquitectura sin compromiso.