Hoe een enkele Proxmox Backup Server te gebruiken voor meerdere clusters zonder de orde te verliezen

Cuando una infraestructura crece hasta incluir múltiples clústeres de Proxmox VE y algunos nodos independientes, resulta tentador crear un datastore de Proxmox Backup Server (PBS) para cada uno. Aunque es una solución sencilla y proporciona cierta separación, también fragmenta el dominio de deduplicación. Los namespaces de backup permiten diseñar otra arquitectura: mantener las copias organizadas por clúster dentro de un mismo datastore y compartir el almacén de chunks sobre el que actúa la deduplicación.

Resumen rápido de las claves de PBS con múltiples clústeres en 20 segundos

• Un datastore puede recibir copias de varios clústeres de Proxmox VE.
• Los namespaces separan lógicamente los backups sin necesidad de crear almacenes de chunks independientes.
• La deduplicación puede reutilizar chunks idénticos entre backups alojados en un mismo datastore.
• Las políticas de retención pueden configurarse por namespace.
• Centralizar todo también aumenta el dominio de fallo, por lo que no siempre es recomendable utilizar un único datastore.

Esta arquitectura resulta especialmente útil en organizaciones donde producción, preproducción, desarrollo y otros clústeres corren sistemas operativos, plantillas o aplicaciones similares. Proxmox define los namespaces justamente como una forma de reutilizar un único dominio de deduplicación para diferentes fuentes, evitando conflictos de nombres y facilitando controles de acceso más específicos.

¿Por qué tener varios datastores puede reducir la deduplicación?

Para entender esto, primero es importante comprender cómo almacena Proxmox Backup Server los datos realmente.

Un datastore no es simplemente una carpeta con archivos completos de cada máquina virtual. Es la unidad lógica donde se almacenan los snapshots, índices y los chunks que contienen los datos.

PBS fragmenta la información respaldada en bloques identificándolos por su contenido. Los chunks usan SHA-256, por lo que un contenido idéntico genera el mismo identificador. Los índices de diferentes snapshots pueden referenciar esos mismos chunks, promoviendo así la reutilización.

La estructura técnica de un datastore normalmente es similar a:

/
├── .chunks/
├── vm/
├── ct/
└── host/

Los chunks se encuentran en la carpeta .chunks, mientras que los snapshots contienen referencias necesarias para reconstruir cada backup.

Esto explica una característica clave: los backups se envían de manera incremental y se deduplican en el servidor, pero cada snapshot representa un backup completo. No es necesario restaurar una cadena tradicional de un full más múltiples incrementales para recuperar una copia específica.

Supongamos una infraestructura con la siguiente distribución:

Cluster Producción
 ├── 25 VM Debian
 └── 10 VM Ubuntu

Cluster Desarrollo
 ├── 15 VM Debian
 └── 5 VM Ubuntu

Cluster Preproducción
 └── 12 VM Debian

Nodo PVE independiente
 └── 4 VM Debian

Muchas de esas máquinas pueden tener exactamente los mismos kernels, librerías, paquetes y archivos del sistema operativo.

Si cada entorno usa un datastore distinto:

datastore-prod
datastore-dev
datastore-pre
datastore-edge

cada uno mantiene su propio almacén de chunks.

En cambio, si se opta por:

datastore-fleet

y dentro de este se organizan los backups mediante namespaces:

prod
dev
pre
edge

los backups permanecen separados lógicamente, pero comparten el mismo dominio de deduplicación.

Este método no garantiza un ahorro extremo en todas las infraestructuras. La eficiencia dependerá de cuánto contenido realmente sea idéntico entre cargas de trabajo. Bases de datos, archivos cifrados, datos comprimidos o sistemas con contenidos dispares ofrecen menos reutilización comparado con cargas homogéneas basadas en imágenes similares.

¿Qué son los namespaces en Proxmox Backup Server?

Los namespaces fueron creados precisamente para organizar múltiples fuentes dentro de un mismo datastore.

Pueden interpretarse como una jerarquía lógica para los backups, aunque técnicamente no equivalen a datastores independientes.

Ejemplo:

datastore: empresa

├── produccion
│   ├── vm/100
│   ├── vm/101
│   └── vm/102
│
├── desarrollo
│   ├── vm/100
│   └── vm/103
│
├── preproduccion
│   └── vm/100
│
└── delegacion-madrid
    └── vm/200

Que distintas instancias tengan una VM 100 en diferentes clústeres ya no causa problema, pues cada backup pertenece a un namespace diferente.

PBS soporta además namespaces anidados, con hasta ocho niveles de profundidad, contando desde el namespace raíz como primer nivel. Cada nivel puede incluir backups de máquinas virtuales, contenedores, hosts u otros namespaces.

Esto permite estructuras jerárquicas muy detalladas, como:

empresa
└── madrid
    ├── produccion
    └── desarrollo

O ejemplos más complejos:

infraestructura
├── cluster-pve-01
├── cluster-pve-02
├── cluster-pve-03
├── nodo-edge-01
└── nodo-edge-02

Aunque PBS permite hasta ocho niveles, en la práctica suele ser recomendable mantener una jerarquía sencilla y fácilmente identificable, especialmente si es gestionada por un mismo equipo.

Configurar cada clúster de Proxmox VE para enviar backups a su namespace correspondiente

El siguiente paso consiste en configurar cada entorno Proxmox VE para que envíe sus backups al namespace adecuado.

La conceptualización sería así:

                 ┌── Clúster Producción ──> namespace: prod
                 │
                 ├── Clúster Desarrollo ──> namespace: dev
                 │
PBS datastore ───┼── Clúster Testing ─────> namespace: test
                 │
                 └── Nodo independiente ──> namespace: edge

                     │
                     ▼

               almacén de chunks
                 compartido

Desde Proxmox VE, se puede añadir PBS como almacenamiento y seleccionar el namespace correspondiente en cada configuración.

Ejemplo de configuración:

pvesm add pbs backup-pbs \
    --server pbs.ejemplo.net \
    --datastore empresa \
    --namespace produccion \
    --username backup@pbs!cluster-prod \
    --password '' \
    --fingerprint ''

En otro clúster, simplemente cambiarías el namespace, manteniendo el mismo servidor y datastore:

pvesm add pbs backup-pbs \
    --server pbs.ejemplo.net \
    --datastore empresa \
    --namespace desarrollo \
    --username backup@pbs!cluster-dev \
    --password '' \
    --fingerprint ''

De esta manera, los backups de diferentes clústeres se almacenan en espacios lógicos distintos dentro del mismo datastore, facilitando la gestión y manteniendo la separación necesaria.

Recomendación: evitar reutilizar credenciales completas en todos los sistemas, aunque pertenezcan a la misma organización. PBS permite definir permisos específicos a nivel de namespace, por lo que usar tokens separados con privilegios controlados reduce riesgos en caso de compromiso.

Retención personalizada sin crear múltiples datastores

Compartir un datastore no implica que todos los backups deban tener la misma duración de retención.

Los trabajos de pruning en PBS pueden especificar el namespace y establecer políticas diferenciadas usando el parámetro ns o limitando la profundidad de los efectos de limpieza.

Por ejemplo, para producción:

proxmox-backup-manager prune-job create prod-prune \
    --store empresa \
    --ns produccion \
    --keep-daily 14 \
    --keep-weekly 8 \
    --keep-monthly 12 \
    --schedule "daily"

Y para desarrollo:

proxmox-backup-manager prune-job create dev-prune \
    --store empresa \
    --ns desarrollo \
    --keep-last 2 \
    --keep-daily 3 \
    --schedule "daily"

Es importante distinguir entre pruning y garbage collection (GC).

El pruning elimina snapshots según las políticas, pero un chunk no puede borrarse físicamente si todavía es necesario para otro snapshot. La garbage collection se encarga después de identificar y eliminar chunks no referenciados, liberando espacio.

En entornos consolidados, esta diferenciación es crucial: un bloque usado en producción no debe eliminarse solo porque desaparezca un backup de desarrollo que también lo usaba.

Un datastore facilita operaciones, pero aumenta el riesgo de fallo

Consolidar múltiples backups en un único datastore reduce la complejidad de gestión, pero también concentra el riesgo de fallo.

El aspecto más importante es la fiabilidad: si varios clústeres dependen del mismo datastore, una caída puede afectar a todos, aumentando el impacto.

Por ello, en ciertos casos sigue siendo recomendable mantener datastores separados para garantizar mayor aislamiento, cumplimiento normativo, rendimiento o requisitos específicos de recuperación.

La documentación de PBS indica que un datastore puede albergar numerosos backups siempre que el hardware sea capaz de soportarlo en términos de capacidad y rendimiento. Consolidar no elimina los requisitos de IOPS, ancho de banda, CPU, memoria o ventanas de mantenimiento.

¿Por qué una arquitectura híbrida suele ser más sensata?

No hay obligación de elegir entre extremos. Una organización puede optar por una mezcla, por ejemplo:

PBS
├── datastore-general
│   ├── namespace: desarrollo
│   ├── namespace: testing
│   ├── namespace: servicios-internos
│   └── namespace: edge
│
└── datastore-critico
    └── namespace: produccion

De esta forma, cargas similares comparten deduplicación, mientras que cargas con requisitos específicos permanecen en entornos separados.

Por último, no hay que olvidar que un datastore de PBS no equivale a una estrategia completa de protección de datos.

PBS permite configurar servidores remotos y Sync Jobs para sincronizar contenido entre múltiples PBS. Además, soporta cifrado en cliente; cabe recordar que esta función adicional no está activa por defecto.

Una arquitectura más avanzada podría incluir:

Proxmox VE Cluster 1 ─┐
Proxmox VE Cluster 2 ─┼──> PBS principal ───> PBS remoto
Proxmox VE Cluster 3 ─┤       │
Nodo independiente ───┘       │
                               ├─ namespaces
                               ├─ deduplicación
                               ├─ pruning
                               ├─ verificación
                               └─ garbage collection

Aquí, la deduplicación optimiza el uso del almacenamiento, los namespaces contribuyen a organizarlo, y las tareas de verificación garantizan la integridad. La sincronización a otros PBS añade una capa adicional de protección geográfica. Ambos procesos son complementarios, aunque diferentes.

¿Cuándo usar un solo datastore con namespaces?

Esta opción suele ser recomendable cuando varios clústeres pertenecen a la misma organización, utilizan sistemas operativos y plantillas similares, y pueden compartir razonablemente el mismo dominio de almacenamiento.

Por el contrario, conviene mantener datastores separados cuando:

• Se requiere aislamiento físico o administrativo,
• Hay requisitos de rendimiento o almacenamiento distintos,
• La normativa exige separar ciertos datos,
• Un entorno crítico necesita reducir su dependencia del resto,
• El tamaño de la carga dificulta la gestión del datastore compartido.

La decisión adecuada no es crear automáticamente un datastore por cada clúster ni concentrarlo todo en uno solo. PBS ofrece herramientas para diseñar un esquema híbrido: datastores como dominios de almacenamiento y deduplicación, namespaces para organizar fuentes y permisos, y políticas de retención ajustadas a las necesidades de cada segmento.

Preguntas frecuentes

¿PBS deduplica backups de diferentes clústeres de Proxmox?

Puede reutilizar chunks idénticos cuando los backups se almacenan en el mismo datastore. Los namespaces permiten separar las fuentes sin crear dominios de deduplicación independientes.

¿Cada namespace puede tener su propia política de retención?

Sí. Los trabajos de pruning pueden configurarse para un namespace específico y definir reglas como keep-last, keep-daily, keep-weekly, keep-monthly o keep-yearly.

¿Es recomendable usar siempre un único datastore?

No necesariamente. Compartir un datastore facilita la deduplicación y simplifica la gestión, pero también concentra el riesgo. Mantener datastores separados puede ser preferible por motivos de rendimiento, aislamiento, cumplimiento o requisitos específicos de recuperación.

¿Los backups en PBS son incrementales?

Los datos se envían de forma incremental y PBS realiza deduplicación en el servidor, pero cada snapshot referencia todos los chunks necesarios para representar un backup completo. Esto permite restaurar en cualquier momento una copia completa sin depender de cadenas de incremental y full.