Casi nadie mira los backups hasta el día en que hacen falta. Ese día llegan todas las preguntas de golpe: ¿existe la copia?, ¿está íntegra?, ¿de cuándo es?, ¿cuánto tarda en restaurar?, ¿está en el mismo sitio que el sistema que acaba de caer? Y la peor de todas: ¿alguien ha probado alguna vez que esto funciona?
En entornos Proxmox VE, Proxmox Backup Server (PBS) responde a esas preguntas mejor que la mayoría de alternativas del ecosistema open source. Ya publicamos una introducción a Proxmox Backup Server y a su encaje con el almacenamiento Archive de Stackscale. Este artículo va un paso más allá y entra en la mecánica: qué hace exactamente la deduplicación, por qué la verificación no es opcional, en qué se diferencian prune y garbage collection, cómo un mismo servidor puede dar servicio a varios clientes sin mezclar nada, cómo recuperar un fichero suelto sin tocar la máquina entera, y cómo se traduce todo eso en decisiones de diseño cuando la infraestructura vive en un cloud privado con almacenamiento en dos zonas de Madrid separadas por más de 10 kilómetros.
PBS no es «otro software de copias»
Proxmox Backup Server es una distribución Linux basada en Debian, escrita en gran parte en Rust y publicada bajo licencia GNU AGPLv3. Está pensada para una sola cosa: guardar y devolver datos de máquinas virtuales, contenedores y servidores físicos. La versión 4.2, publicada en abril de 2026, se apoya en Debian 13.4 «Trixie», kernel Linux 7.0 y ZFS 2.4, e incorpora soporte oficial para backends de objetos compatibles con S3, cifrado en los trabajos de sincronización y procesamiento concurrente de grupos.
La diferencia práctica frente a un volcado tradicional a disco o a un NAS está en tres mecanismos que trabajan juntos: deduplicación (cuánto ocupa), verificación (si sirve) y retención (cuánto tiempo se guarda y cuándo se libera el espacio de verdad). Quien entiende esos tres, dimensiona bien. Quien no, acaba con un repositorio lleno, copias que nadie ha comprobado y una restauración que se convierte en experimento.
Deduplicación: por qué 30 copias no ocupan 30 veces
PBS no guarda ficheros de backup monolíticos. Trocea los datos en bloques —chunks, de unos 4 MiB de media—, calcula el resumen criptográfico SHA-256 de cada uno y lo almacena una única vez dentro del datastore. Si mañana ese mismo bloque vuelve a aparecer, el backup solo anota una referencia.
Tres consecuencias que conviene tener claras antes de dimensionar nada:
- Todos los backups son incrementales, pero se restauran como completos. Después de la primera copia, cada ejecución solo añade los bloques nuevos. Al restaurar no hay cadenas de incrementales que reconstruir: cualquier snapshot se recupera por sí mismo.
- La deduplicación es global dentro del datastore. No se limita a una VM: diez máquinas con el mismo sistema operativo comparten la parte común una sola vez. Y como los namespaces viven dentro del mismo datastore, se pueden separar entornos (producción, preproducción, clientes) sin perder ese ahorro.
- El cálculo «tamaño de la VM × número de copias» no sirve. Es la cuenta que todo el mundo hace en la primera reunión y siempre sale un número desproporcionado. El consumo real es una fracción, porque lo que crece no es el número de copias sino el volumen de datos que cambia entre ellas.
Ese último punto cambia la conversación. La pregunta útil no es «¿cuánto ocupa cada backup?», sino «¿cuántos datos cambian al día en esta plataforma?». Una base de datos transaccional y un servidor de ficheros con documentos que casi no se tocan tienen tamaños parecidos en disco y necesidades de almacenamiento de backup muy distintas.
En la parte del hipervisor hay un detalle que acelera mucho el proceso: Proxmox VE usa los dirty bitmaps de QEMU para saber qué bloques de una VM se han modificado desde la última copia, sin releer el disco entero. Ese mapa vive en memoria, así que se pierde cuando la máquina se apaga o migra; en la siguiente ejecución PBS releerá el disco completo, aunque solo transferirá y almacenará lo que realmente sea nuevo. Un backup ocasionalmente más lento después de un mantenimiento no es un síntoma de avería.
Verificación: descubrir la corrupción cuando todavía no importa
El problema del bit rot es que no avisa. Un bloque puede degradarse en el soporte, un fallo de hardware o de software puede dañar datos que ya estaban escritos, y nada en el panel se pone en rojo. El backup sigue apareciendo en la lista, con su fecha y su tamaño. El día que se necesita, no abre.
PBS resuelve esto con trabajos de verificación programables: releen los bloques almacenados, recalculan sus resúmenes y los comparan con los originales. Lo que consigue no es evitar la corrupción, sino adelantar el momento en que se descubre: de la madrugada de un desastre a un martes cualquiera, cuando todavía existe la copia buena en otro sitio y hay margen para reaccionar.
Dos matices operativos que marcan la diferencia en repositorios grandes:
- La verificación se puede configurar para saltar los snapshots ya verificados en los últimos N días, de forma que cada pasada se centre en lo nuevo en lugar de releer el repositorio entero cada semana.
- Un snapshot que falla la verificación queda marcado. Conviene tener una alerta que llegue a alguien y no solo un registro en la interfaz: un backup marcado como defectuoso y no atendido es exactamente igual de útil que no tenerlo.
Ahora bien, conviene no confundir dos cosas. Verificar demuestra que los bloques están íntegros; no demuestra que el servicio arranque. Que una base de datos levante, que la aplicación conecte y que el negocio pueda operar solo lo demuestra una restauración real. La verificación es la condición necesaria; la prueba de restauración periódica es la suficiente.
Retención y garbage collection: dos cosas distintas que todo el mundo mezcla
Aquí está el malentendido más frecuente con PBS, y el que llena repositorios: el prune no libera espacio.
- Prune aplica la política de retención y decide qué snapshots dejan de ser necesarios. Elimina la referencia al backup, pero no toca los bloques: están deduplicados y muy probablemente los siga usando otra copia.
- Garbage collection (GC) es quien recupera el espacio. Recorre el datastore, marca los bloques que siguen referenciados y elimina los huérfanos. Trabaja con un margen de seguridad temporal para no borrar bloques de un backup que se esté escribiendo en ese momento, así que el espacio liberado no aparece de forma instantánea.
Los dos procesos se programan por separado y los dos deben estar programados. Un entorno con retención configurada y sin GC periódica crece hasta que alguien recibe un aviso de disco lleno, normalmente en fin de semana.
Sobre la política en sí, PBS permite construir una pirámide con varios niveles: últimos N, diarios, semanales, mensuales y anuales. Un punto de partida razonable para una plataforma de producción:
| Nivel | Ejemplo | Para qué sirve |
|---|---|---|
| Últimos | 3 copias | Deshacer un error reciente (un despliegue, un borrado) |
| Diarios | 7 | Volver a cualquier día de la última semana |
| Semanales | 4 | Cubrir el mes con pocos puntos |
| Mensuales | 6-12 | Histórico y requisitos de negocio |
| Anuales | 1-5 | Obligaciones legales o contractuales, cuando existan |
La tentación de guardarlo todo «por si acaso» es comprensible, pero la retención no es una decisión técnica: es una decisión de negocio y, en algunos sectores, también normativa. Merece la pena pactarla por escrito con quien responde de los datos, y no dejarla al criterio de quien configura el trabajo. Lo explicamos con más detalle en este artículo sobre la diferencia entre retención de datos y copias de seguridad.
Cifrado en cliente: la pieza que hace viable la copia remota
PBS cifra en el lado del cliente, en el propio nodo Proxmox, antes de que los datos salgan por la red, con AES-256-GCM. El servidor de backup guarda información que no puede leer. Esto tiene dos lecturas prácticas:
- Permite enviar copias a una ubicación remota o a un backend de objetos sin que el destino sea un punto de confianza. El dato viaja cifrado y se queda cifrado.
- Quien pierde la clave, pierde los backups. No hay recuperación posible. La clave hay que custodiarla como un activo crítico: copia fuera del entorno que protege, versión impresa en un sitio seguro y un procedimiento escrito de quién puede acceder a ella.
Un detalle técnico que suele sorprender: la deduplicación sigue funcionando con cifrado activo, pero entre backups que comparten la misma clave. Usar una clave distinta por cliente o por entorno es una decisión legítima de aislamiento; simplemente hay que saber que reduce el ahorro de espacio, porque ya no se comparten bloques entre esos conjuntos.
Desde la versión 4.2, además, los trabajos de sincronización también manejan cifrado: los push cifran antes de enviar y los pull pueden descifrar datos remotos, con la gestión de claves centralizada junto a la de cinta.
Llevar la copia lejos: sync jobs entre ubicaciones
Un repositorio único, por bien verificado que esté, sigue siendo un único punto de fallo. PBS resuelve la distribución con trabajos de sincronización entre servidores o datastores: en modo pull, el destino recoge; en modo push, el origen empuja. En ambos casos solo viajan los bloques que faltan, con lo que una réplica diaria entre ubicaciones es perfectamente asumible incluso con volúmenes grandes. La 4.2 añade procesamiento concurrente de varios grupos, lo que se nota especialmente cuando hay latencia de por medio.
Un solo PBS para varios clientes: para qué sirven los namespaces
Los namespaces son subdivisiones jerárquicas dentro de un mismo datastore, y son la pieza que convierte un servidor de backup en una plataforma multicliente. Con ellos, un único PBS puede dar servicio a varios clientes, a varias unidades de negocio o a varios clústeres sin que nada se mezcle.
- Aislamiento por permisos. Cada namespace tiene sus propias ACL. Un cliente, un partner o un equipo interno solo ve su rama del árbol, y los tokens de API se emiten con ese alcance: no hay forma de listar, restaurar ni borrar lo que hay al lado.
- Políticas propias. Retención, verificación y sincronización se configuran por namespace. Un cliente con siete días de copias y otro con obligación de conservar años conviven en el mismo repositorio sin que uno imponga sus reglas al otro.
- Sin coste extra de espacio. La deduplicación sigue siendo global dentro del datastore, así que separar clientes no multiplica el almacenamiento. Si cada cliente cifra con su propia clave, el aislamiento es mayor pero los bloques ya solo se comparten dentro de cada conjunto: es el precio de esa separación.
- Destino de sincronizaciones. Un sync job puede volcar cada origen remoto en un namespace concreto. Es el patrón habitual cuando se centralizan varios clústeres, varias delegaciones o varios clientes en un único PBS.
Es la arquitectura que usan proveedores gestionados y partners que ofrecen backup como servicio: un repositorio, muchos inquilinos, cuentas separadas. Con dos avisos prácticos. El primero, que no existen cuotas duras por namespace: el crecimiento se controla con la política de retención y con monitorización, no con un límite que frene al cliente que se pase. El segundo, que la recuperación de espacio (GC) es del datastore completo, así que las ventanas de mantenimiento se planifican globalmente y no cliente a cliente.
En la 4.2, además, los grupos y namespaces pueden moverse de ubicación, algo útil cuando la estructura inicial se queda corta —un cliente que crece, un entorno que se separa— y hay que reorganizar sin rehacer backups.
Copias dentro de la máquina: proxmox-backup-client y ficheros sueltos
Hasta aquí hemos hablado de copias de la máquina completa, que es lo que se lanza desde Proxmox VE. Pero PBS no se limita a eso: existe proxmox-backup-client, un cliente que se instala dentro de la propia VM, del contenedor o de un servidor físico Linux, y que copia los directorios que tú le indiques, con su propio calendario, su propio cifrado y su propio namespace.
Eso cambia qué se puede recuperar y con qué rapidez:
- Recuperar un fichero suelto —un adjunto borrado por error, un fichero de configuración, el directorio de datos de una aplicación— sin restaurar la máquina entera ni levantar una copia en paralelo para sacar de ella una carpeta.
- Proteger rutas concretas con otra frecuencia. El directorio de datos de una aplicación puede copiarse cada hora mientras la copia completa de la máquina sigue siendo diaria.
- Cubrir servidores que no están en ese clúster: equipos físicos, sistemas heredados o máquinas alojadas en otro sitio que envían sus datos al mismo repositorio, con el mismo cifrado y la misma retención.
La operativa es sencilla: se instala el cliente, se define el repositorio y se lanza la copia de las rutas elegidas, que viajan en formato pxar, se deduplican y se cifran igual que el resto.
proxmox-backup-client backup datos.pxar:/var/www
--repository backup@pb*@*bs.interno:almacen
--ns cliente-aDespués, esos archivos se pueden listar o montar para extraer solo lo que hace falta, sin descargar el conjunto.
Conviene verlo como un complemento, no como un sustituto. La copia de la máquina completa es la que devuelve el servicio tras un desastre; el cliente instalado dentro es el que resuelve el «me he cargado un fichero» de un martes por la mañana. Para las copias de VM, Proxmox VE también permite recuperación a nivel de fichero desde la propia interfaz y live restore, que arranca la máquina mientras la restauración sigue por detrás; entre las tres vías se cubren casi todos los incidentes reales.
Cómo se aterriza esto en un cloud privado Proxmox en Stackscale
Toda la teoría anterior se traduce en una pregunta muy concreta: dónde viven los bloques. En Stackscale trabajamos el backup de entornos Proxmox sobre almacenamiento Archive, accesible por NFS o por API compatible con S3, y disponible en ubicaciones físicamente separadas: dos zonas en Madrid, a más de 10 kilómetros de distancia entre sí, y una tercera en Ámsterdam.
Esa distancia no es un detalle de folleto. Es lo que separa dos centros de datos de un mismo incidente físico —un incendio, una inundación, un corte de suministro en una zona— manteniendo a la vez latencias metropolitanas, suficientemente bajas como para que una sincronización diaria, o incluso varias al día, no se convierta en un problema. Es la diferencia entre «tenemos una copia en otro rack» y «tenemos una copia en otra zona de riesgo».
Arquitectura de referencia
| Capa | Dónde | Para qué |
|---|---|---|
| Datastore principal | Archive en Madrid, zona A (NFS o S3) | Copia de referencia. Todos los trabajos de backup escriben aquí |
| Réplica | Archive en Madrid, zona B (>10 km) o Ámsterdam | Sync job diario. Supervivencia ante la pérdida completa de una ubicación |
| Capa rápida (opcional) | Almacenamiento en red all-flash | Últimos días de copias, para restauraciones frecuentes y RTO bajo |
| Disco local del PBS | Servidor de backup | Buffer temporal como mucho. Nunca como repositorio único |
El principio de diseño es simple: la copia de referencia vive siempre en Archive, no en el disco del servidor que hace los backups. Un repositorio local depende de la salud de una máquina concreta y no aporta redundancia; si ese servidor se pierde en el mismo incidente que el clúster, se pierde también la capacidad de recuperar. Las capas rápidas son una caché para acelerar restauraciones, no la fuente de verdad.
Con este esquema, la regla 3-2-1 deja de ser un eslogan: tres copias (producción más dos repositorios), en soportes y sistemas distintos, con al menos una fuera de la ubicación primaria. Y todo ello con los datos en centros de datos europeos, un punto que ha dejado de ser una preferencia técnica para convertirse en un requisito contractual en bastantes sectores.
Un calendario operativo que funciona
Más importante que la arquitectura es que alguien la mantenga viva. Este es un calendario de partida razonable para una plataforma de producción:
| Tarea | Frecuencia orientativa | Nota |
|---|---|---|
| Backup de VMs y contenedores | Diario, en ventana de baja carga | Con límites de ancho de banda si comparte red con producción |
| Sync a la segunda ubicación | Diario, tras la ventana de backup | Solo viajan bloques nuevos |
| Verificación | Semanal, saltando lo ya verificado | Con alerta a una persona, no solo al log |
| Prune | Diario | Aplica la política; no libera espacio |
| Garbage collection | Semanal | Es la que recupera espacio de verdad |
| Prueba de restauración | Trimestral, y tras cambios relevantes | Restaurar y arrancar, no solo verificar |
Cinco errores que se repiten
- Dimensionar multiplicando. Calcular el almacenamiento como tamaño por número de copias lleva a presupuestos irreales y a decisiones de retención demasiado cortas.
- Programar prune y olvidar GC. El espacio no vuelve solo.
- Confundir verificación con prueba de restauración. Son controles distintos y ninguno sustituye al otro.
- Guardar la clave de cifrado dentro del entorno que protege. Si el incidente se lleva el clúster, se lleva la clave.
- Diseñar solo para el desastre grande. La mayoría de las restauraciones reales son de un fichero o un directorio, no de un centro de datos entero; sin
proxmox-backup-cliento recuperación a nivel de fichero, cada incidente menor obliga a levantar una VM completa. - Dejar la única copia en el mismo edificio. Una réplica a una segunda ubicación separada por kilómetros es lo que convierte un backup en un plan de recuperación ante desastres.
Preguntas frecuentes
¿Cuánto espacio necesito realmente para 30 días de copias?
Depende del volumen de datos que cambie, no del tamaño total de las máquinas. Como la deduplicación es global dentro del datastore y los backups son incrementales, mantener 30 días no multiplica por 30 el consumo: se acerca mucho más al tamaño de la primera copia más el cambio diario acumulado. Lo prudente es medir el cambio real durante unas semanas antes de cerrar el dimensionamiento.
¿Qué diferencia hay entre prune y garbage collection?
El prune aplica la política de retención y elimina snapshots de la lista, pero no borra bloques porque suelen estar compartidos con otras copias. La garbage collection identifica los bloques que ya no referencia ningún backup y los elimina, que es cuando se recupera espacio. Hay que programar las dos.
Si verifico los backups, ¿hace falta probar restauraciones?
Sí. La verificación comprueba que los bloques almacenados están íntegros; no comprueba que el sistema arranque, que la base de datos sea consistente ni que la aplicación funcione. Una prueba de restauración periódica, con arranque real del servicio, es el único control que valida el conjunto.
¿Es seguro guardar backups en una ubicación remota?
Con cifrado en cliente, sí: los datos se cifran con AES-256-GCM en el nodo Proxmox antes de salir y el destino no puede leerlos. La contrapartida es la custodia de la clave: sin ella no hay restauración posible, así que debe guardarse fuera del entorno que protege.
¿Por qué importa que las dos zonas de Madrid estén a más de 10 km?
Porque separa ambas ubicaciones de un mismo incidente físico —incendio, inundación, corte eléctrico de zona— manteniendo latencias metropolitanas. Permite sincronizar copias a diario, o varias veces al día, sin penalización operativa, y cumplir los requisitos de separación geográfica de un plan de continuidad sin salir de España.
¿Puedo dar servicio a varios clientes con un único Proxmox Backup Server?
Sí, mediante namespaces. Cada cliente trabaja en su propia rama del datastore, con permisos, tokens de API, retención y verificación independientes, mientras la deduplicación sigue siendo global y no se paga espacio por separarlos. Hay que tener en cuenta que no existen cuotas duras por namespace y que la recolección de espacio afecta al datastore completo.
¿Puedo recuperar un fichero suelto sin restaurar toda la máquina?
Sí, por dos vías. Sobre una copia de la VM, Proxmox VE permite recuperación a nivel de fichero desde la interfaz. Y si instalas proxmox-backup-client dentro de la máquina, puedes copiar las rutas que te interesen con su propio calendario y luego listarlas o montarlas para extraer solo lo que necesitas.
En resumen
Proxmox Backup Server hace bien la parte difícil: almacenar poco, detectar la corrupción a tiempo y devolver los datos rápido. Lo que no puede hacer por nosotros es decidir cuánto tiempo se guardan las cosas, dónde vive la segunda copia, quién custodia las claves y cada cuánto se prueba una restauración de verdad. Esas cuatro decisiones son las que separan un backup que tranquiliza de uno que solo lo parece.
En Stackscale diseñamos ese conjunto —clúster Proxmox, PBS y almacenamiento Archive en varias ubicaciones— como una sola pieza. Si estás montando o revisando la estrategia de copias de tu entorno Proxmox, hablamos y la revisamos contigo.
