Cuando una infraestructura crece hasta tener varios clústeres de Proxmox VE y algunos nodos independientes, resulta tentador crear un datastore de Proxmox Backup Server (PBS) para cada uno. Es sencillo de entender y proporciona cierta separación, pero también divide el dominio de deduplicación. Los backup namespaces permiten plantear otra arquitectura: mantener las copias organizadas por clúster dentro de un mismo datastore y compartir el almacén de chunks sobre el que trabaja la deduplicación.

Las claves de PBS con varios clústeres en 20 segundos

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

Esta arquitectura resulta especialmente interesante en organizaciones donde producción, preproducción, desarrollo y otros clústeres ejecutan sistemas operativos, plantillas o aplicaciones similares. Proxmox define precisamente los namespaces como una forma de reutilizar un único dominio de deduplicación para diferentes fuentes, evitando al mismo tiempo conflictos de nombres y permitiendo controles de acceso más detallados.

Por qué varios datastores pueden reducir la deduplicación

Para entender la diferencia primero hay que mirar cómo almacena realmente los datos Proxmox Backup Server.

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

PBS divide la información respaldada en bloques y los identifica mediante su contenido. Los chunks utilizan SHA-256, de forma que un contenido idéntico genera el mismo identificador. Los índices de diferentes snapshots pueden referenciar posteriormente esos mismos chunks.

La documentación técnica de Proxmox describe el almacén mediante una estructura similar a:

<datastore-root>/
├── .chunks/
├── vm/
├── ct/
└── host/

Los chunks se encuentran dentro de .chunks, mientras que los snapshots mantienen las referencias necesarias para reconstruir cada backup.

Esto explica una característica importante de PBS: las copias se envían de forma incremental y se deduplican en el servidor, pero cada snapshot continúa representando un backup completo. No es necesario restaurar una cadena tradicional de full más varios incrementales para obtener el estado correspondiente a una copia.

Supóngase una infraestructura con esta 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

Una parte considerable de esas máquinas puede contener exactamente los mismos kernels, librerías, paquetes y archivos del sistema operativo.

Si cada entorno utiliza un datastore independiente:

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

cada datastore mantiene su propio almacén de chunks.

Si se utiliza:

datastore-fleet

y dentro se organizan las fuentes mediante namespaces:

prod
dev
pre
edge

los backups permanecen separados desde el punto de vista lógico, pero forman parte del mismo dominio de deduplicación.

Esto no significa que el ahorro vaya a ser enorme en cualquier infraestructura. Dependerá de cuánto contenido idéntico exista realmente entre las cargas. Bases de datos, archivos cifrados, datos comprimidos o máquinas con contenidos muy diferentes pueden ofrecer bastante menos reutilización que un parque de servidores creado a partir de imágenes comunes.

Qué son los namespaces de Proxmox Backup Server

Los namespaces aparecieron precisamente para organizar múltiples fuentes dentro de un datastore.

Pueden entenderse como una jerarquía lógica para backups, aunque técnicamente no deben confundirse con datastores independientes.

Por ejemplo:

datastore: empresa

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

Que diferentes clústeres tengan una VM 100 deja de provocar problemas porque cada backup pertenece a un namespace diferente.

PBS admite además namespaces anidados hasta ocho niveles de profundidad, contando el namespace raíz como primer nivel. Cada nivel puede contener backups de máquinas virtuales, contenedores, hosts y otros namespaces.

Eso permitiría estructuras bastante detalladas:

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

o:

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

Que PBS permita ocho niveles no significa que resulte recomendable utilizarlos todos. En una infraestructura administrada por un mismo equipo suele ser preferible una jerarquía corta y fácilmente identificable.

Conectar cada clúster de Proxmox VE con su namespace

La siguiente parte consiste en configurar cada entorno Proxmox VE para enviar sus backups al namespace correspondiente.

Conceptualmente quedaría así:

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

                     │
                     ▼

               almacén de chunks
                 compartido

Desde Proxmox VE puede añadirse PBS como almacenamiento y especificarse el namespace que debe utilizar esa conexión.

Un ejemplo sería:

pvesm add pbs backup-pbs \
    --server pbs.example.net \
    --datastore empresa \
    --namespace produccion \
    --username backup@pbs!cluster-prod \
    --password '<TOKEN>' \
    --fingerprint '<FINGERPRINT>'

En otro clúster se podría configurar el mismo servidor y datastore cambiando el namespace:

pvesm add pbs backup-pbs \
    --server pbs.example.net \
    --datastore empresa \
    --namespace desarrollo \
    --username backup@pbs!cluster-dev \
    --password '<TOKEN>' \
    --fingerprint '<FINGERPRINT>'

Desde ese momento los trabajos de backup de ambos clústeres terminan en espacios lógicos diferentes dentro del mismo datastore.

Conviene además no reutilizar alegremente una única credencial con acceso completo simplemente porque todos los sistemas pertenezcan a la misma empresa. PBS permite aplicar permisos sobre namespaces concretos, por lo que separar tokens y privilegios reduce las consecuencias de una credencial comprometida. La documentación contempla explícitamente permisos a nivel de namespace.

Retención diferente sin crear datastores diferentes

Compartir datastore tampoco obliga a conservar todos los backups durante el mismo tiempo.

Los trabajos de pruning de PBS pueden especificar un namespace mediante el parámetro ns, además de limitar la profundidad sobre la que actúan.

Producción podría mantener:

14 diarios
8 semanales
12 mensuales

mientras desarrollo utiliza:

2 últimos
3 diarios

Por ejemplo:

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

y:

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

Aquí conviene distinguir pruning y garbage collection (GC).

El pruning elimina snapshots de acuerdo con las reglas de retención. Sin embargo, un chunk no puede desaparecer físicamente mientras siga siendo necesario para otro snapshot. La garbage collection se encarga posteriormente de identificar los chunks que ya no están referenciados y recuperar el espacio correspondiente.

En una arquitectura consolidada esta característica resulta especialmente importante: un bloque utilizado por producción no puede eliminarse simplemente porque haya desaparecido el backup de desarrollo que también lo utilizaba.

Un datastore simplifica operaciones, pero aumenta el dominio de fallo

La consolidación tiene otra ventaja operativa: reduce el número de datastores que deben administrarse.

Aspecto	Datastore por clúster	Datastore compartido + namespaces
Organización por clúster	Sí	Sí
Dominio de deduplicación compartido	No	Sí
Retención diferenciada	Sí	Sí
ACL por entorno	Sí	Sí, mediante namespaces
GC	Independiente	Compartida por datastore
Supervisión	Varios datastores	Un datastore principal
Dominio de fallo	Más separado	Más concentrado

La última fila es probablemente la más importante.

Deduplicar mejor no debe convertirse en el único criterio de diseño de una plataforma de backup.

Si cuatro clústeres dependen del mismo datastore y ese almacenamiento deja de estar disponible, los cuatro pierden temporalmente acceso a ese repositorio de backup. Un problema grave del almacenamiento tiene igualmente un alcance mayor.

Por eso existen escenarios donde mantener datastores separados continúa teniendo sentido.

Un entorno con requisitos regulatorios específicos puede exigir separación. También puede haber clústeres que necesiten diferentes tecnologías o niveles de rendimiento del almacenamiento. Y una infraestructura especialmente importante puede merecer un dominio de fallo independiente aunque se renuncie a parte de la deduplicación.

Hay además una cuestión de escala. La documentación de PBS señala que un datastore puede alojar muchos backups siempre que el almacenamiento subyacente tenga capacidad y rendimiento suficientes. Consolidar no elimina los requisitos de IOPS, ancho de banda, CPU, memoria o ventanas disponibles para mantenimiento.

Una arquitectura híbrida suele ser más razonable

No existe obligación de escoger entre los dos extremos.

Una empresa podría utilizar:

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

De esta forma los sistemas similares comparten deduplicación mientras las cargas con requisitos diferentes permanecen separadas.

Y todavía falta una pieza: un datastore de PBS no debería confundirse con una estrategia completa de protección de datos.

Proxmox Backup Server permite configurar servidores remotos y Sync Jobs para sincronizar contenido entre PBS. También soporta cifrado en el lado cliente; Proxmox recuerda que este cifrado adicional no está activado de forma predeterminada.

Una arquitectura más completa podría ser:

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

La deduplicación ayuda a utilizar mejor el almacenamiento. Los namespaces ayudan a organizarlo. Los trabajos de verificación permiten comprobar integridad y la sincronización hacia otro PBS puede añadir una segunda ubicación. Son problemas relacionados, pero no equivalentes.

Cuándo utilizar un único datastore con namespaces

Esta arquitectura encaja especialmente bien 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.

Separar datastores continúa siendo preferible cuando:

• se necesita aislamiento físico o administrativo;
• existen requisitos diferentes de almacenamiento o rendimiento;
• una normativa obliga a separar determinados datos;
• un entorno crítico necesita reducir su dependencia respecto al resto;
• el tamaño de una carga condicionaría excesivamente las tareas de mantenimiento del datastore compartido.

La decisión correcta no consiste, por tanto, en crear automáticamente un datastore por cada clúster ni en concentrarlo todo en uno.

PBS proporciona precisamente las herramientas para diseñar el punto intermedio: datastores como dominios de almacenamiento y deduplicación, namespaces para organizar las fuentes y permisos, y políticas de retención adaptadas a cada parte de la infraestructura.

Preguntas frecuentes

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

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

¿Cada namespace puede tener una retención diferente?

Sí. Los prune jobs permiten indicar un namespace y establecer reglas como keep-last, keep-daily, keep-weekly, keep-monthly o keep-yearly.

¿Es mejor utilizar siempre un solo datastore?

No. Compartirlo mejora las posibilidades de deduplicación y puede simplificar la administración, pero también concentra el dominio de fallo. Separar datastores puede ser adecuado por rendimiento, aislamiento, almacenamiento o cumplimiento normativo.

¿Los backups de PBS son incrementales?

Los datos se envían incrementalmente y PBS realiza deduplicación en el servidor, pero cada snapshot referencia todos los chunks necesarios para representar un backup completo.