Cualquiera que haya gestionado copias de seguridad conoce la regla: necesitas al menos una copia fuera de sitio. El problema siempre fue llevar los datos allí sin montar un segundo servidor ni pelearte con scripts de rclone, cron y montajes que se rompen cuando menos lo esperas. Proxmox Backup Server cambió ese cálculo en dos pasos: la 4.0 estrenó el backend S3 nativo como technology preview, y la 4.2 —la versión actual, de abril de 2026— lo ha llevado a soporte oficial y le ha añadido sync jobs en paralelo. Es decir: ya no es una promesa con asteriscos, es una funcionalidad de producción.
Si llevabas tiempo posponiendo el offsite porque “montar el destino” sonaba a fin de semana perdido, este es el artículo que lo desbloquea.
Hasta ahora, sacar las copias de PBS a almacenamiento de objetos significaba intermediarios: montar el bucket con rclone, sincronizar a mano, gestionar credenciales en scripts. PBS habla ahora directamente con cualquier almacén compatible con S3 —MinIO autoalojado, Backblaze B2, Wasabi, AWS S3 o tu propio almacenamiento de objetos— como un tipo de datastore más.
La pieza que hay que entender, porque define el dimensionamiento, es que un datastore S3 requiere una cache local persistente. PBS guarda los contenidos en el objeto S3, pero mantiene en disco local los metadatos y los chunks más usados para no martillear la API del proveedor en cada operación. Durante la creación del datastore se indica una ruta local para esa cache, y Proxmox recomienda reservarle entre 64 y 128 GiB. No es opcional ni un detalle: es lo que hace que un datastore sobre objetos rinda de forma razonable y no se dispare en llamadas (y en coste) al backend.
Esto importa porque el modelo de S3 es de pago por operación además de por almacenamiento. La cache local de PBS está diseñada precisamente para minimizar el número de peticiones al backend reteniendo lo que se reutiliza. Es la diferencia entre un offsite que sale barato y uno que te sorprende en la factura.
La segunda novedad de la 4.2 es la que tiene impacto operativo directo. Los sync jobs de PBS —los trabajos que copian snapshots entre datastores, ya sea en modo pull (traer de un remoto) o push (empujar a un remoto)— pueden ahora procesar varios grupos en paralelo, mediante la nueva propiedad worker-threads.
Antes, un sync iba grupo a grupo, secuencial. Sobre una red de alta latencia hacia un bucket S3 en otra región, esa serialización dejaba la mayor parte del ancho de banda sin usar: cada grupo esperaba a que terminara el anterior. Subiendo worker-threads, varios grupos viajan a la vez y el throughput mejora de forma notable justo donde más duele, en enlaces con latencia alta. Es la clase de mejora que no inventa nada vistoso pero que recorta horas reales de ventana de copia.
La arquitectura encaja bien:
worker-threads ajustado a tu enlace y un horario fuera de horas punta.El resultado es una copia local rápida para restauraciones del día a día y una copia remota en objeto para el peor escenario, sin scripts intermedios y con la deduplicación incremental de PBS trabajando en ambos extremos: tras la primera copia, cada sync mueve solo lo que cambió.
La 4.2 añade otra pieza que en un destino S3 de terceros es más que bienvenida: los push sync jobs pueden cifrar los snapshots al vuelo antes de enviarlos al datastore remoto, y los pull sync jobs pueden descifrar los que llegaron cifrados de un remoto. Traducido: puedes apoyarte en un proveedor S3 externo para el offsite sin entregarle datos en claro. Para quien mueve copias a un bucket que no controla físicamente —que es casi todo el mundo que hace offsite a la nube—, esa garantía es la que hace la diferencia entre “técnicamente posible” y “defendible ante una auditoría”.
Esto no es una funcionalidad aislada: es la pieza que cierra una estrategia 3-2-1 de backup sin hardware adicional. Tres copias, en dos medios distintos, una de ellas fuera de sitio:
Sobre ese esquema, el endurecimiento clásico sigue aplicando: retención con prune y garbage collection, verificación periódica de los chunks, y —donde el proveedor lo soporte— inmutabilidad a nivel de bucket para que un ransomware que comprometa el plano de gestión no pueda borrar el offsite. Es la diferencia entre tener backups y tener backups de los que de verdad puedes depender en un incidente.
Algunas cosas que conviene tener claras antes de apoyarte en esto en producción:
worker-threads a tu enlace, no al máximo. Más hilos ayudan en latencia alta, pero saturar el uplink no da ganancias proporcionales y compite con el resto del tráfico. Sube por pasos y mide.La pregunta es legítima. Nuestra postura honesta:
Para la mayoría de despliegues Proxmox de tamaño medio, PBS 4.2 con destino S3 es hoy el camino más corto entre “tengo backups locales” y “tengo backups locales y una copia offsite cifrada que se mantiene sola”.
¿El backend S3 de PBS ya es estable o sigue en preview? Es soporte oficial desde Proxmox Backup Server 4.2 (abril de 2026). Se introdujo como technology preview en la 4.0; en la 4.2 dejó de serlo.
¿Con qué proveedores de S3 funciona? Con cualquier almacén compatible con la API S3: MinIO autoalojado, Backblaze B2, Wasabi, AWS S3 y similares.
¿Necesito disco local aunque guarde todo en S3? Sí. Un datastore S3 requiere una cache local persistente; Proxmox recomienda 64-128 GiB. Sirve para acelerar y para reducir el número de llamadas (y el coste) al backend.
¿Qué es el sync paralelo de la 4.2?
Los sync jobs pueden procesar varios grupos a la vez con la propiedad worker-threads, lo que mejora mucho el rendimiento en redes de alta latencia frente al modo secuencial anterior.
¿Puedo cifrar las copias que envío a un S3 de terceros? Sí. En la 4.2 los push sync jobs cifran los snapshots al vuelo antes de enviarlos, y los pull sync jobs descifran los que llegan cifrados. Puedes usar un proveedor externo sin entregarle datos en claro.
¿Sustituye esto a la regla 3-2-1? No, la hace más fácil de cumplir: el datastore S3 es tu tercera copia, offsite. Sigue necesitando retención, verificación y, a ser posible, inmutabilidad a nivel de bucket.
Fuentes oficiales: Proxmox Backup Server 4.0 — nota de lanzamiento, Proxmox Backup Server 4.2 — nota de lanzamiento y la documentación de almacenamiento de PBS.
Proxmox VE 9.2 estrena versión oficial para ARM64 (AArch64), la primera fuera de x86-64 en la historia del producto. Misma base de código, mismos repositorios y mismo soporte, con NVIDIA Grace y NVIDIA Vera como plataformas certificadas de salida. Repasamos qué hardware cumple los requisitos, qué funciones se quedan en x86 y qué cambia (poco, de momento) para quien ya tiene un clúster en producción.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.