Estrategia de backup en Proxmox: un plan práctico para 2026

Una buena estrategia de backup para Proxmox en 2026 debería partir de que el clúster, el destino de copias local y una cuenta de administrador pueden fallar todos. Proxmox Backup Server 4.2 te da copias incrementales deduplicadas, verificación, sincronización remota y opciones de almacenamiento en cinta y compatible con S3, pero el diseño solo está completo cuando puedes restaurar dentro de un objetivo de recuperación medido.

Este artículo toma como base la documentación de Proxmox de agosto de 2026 y la versión actual PBS 4.2, en lugar de recetas antiguas de foros. El taller de backup para Proxmox de Heise en 2026 plantea la misma idea práctica: la deduplicación y el cifrado son funciones, mientras que la recuperación ante desastres depende de cómo se implementa y se prueba el sistema.

¿De qué debería protegerte una estrategia de backup en Proxmox?

Una estrategia de backup en Proxmox debería protegerte contra fallos del invitado, del host, del almacenamiento y del sitio, contra errores de los operadores y contra credenciales comprometidas. Si todas las copias dependen del mismo clúster, la misma sala, la misma controladora de almacenamiento o la misma cuenta de administrador, un solo incidente puede llevarse a la vez la producción y la recuperación.

Así que la primera decisión de diseño es el dominio de fallo, y la programación viene después. Una copia nocturna a otro disco dentro del mismo servidor puede ayudar tras un archivo borrado o una VM rota. Sirve de muy poco tras un robo, un incendio, un fallo de la controladora o una cuenta root comprometida que puede llegar a la ruta de las copias.

Para ver de forma más amplia cómo encaja el backup con ZFS, Ceph, NFS y otras opciones de almacenamiento, empieza por la guía de almacenamiento de Mr.PlanB. El sistema de backup tiene que diseñarse en torno al fallo de almacenamiento al que intentas sobrevivir.

¿Deberías usar Proxmox Backup Server en 2026?

Sí, PBS 4.2 es la opción natural por defecto para la mayoría de los entornos Proxmox VE que necesitan proteger VMs y contenedores con regularidad. Está hecho específicamente para cargas de trabajo de Proxmox y admite copias incrementales deduplicadas, verificación de integridad, cifrado, gestión de la retención y sincronización remota.

Proxmox usa fragmentos de tamaño fijo para las imágenes de máquinas virtuales y fragmentos de tamaño variable para los paquetes de archivos. La deduplicación significa que los fragmentos idénticos se guardan una sola vez, lo que puede reducir el uso de almacenamiento y de red cuando muchas copias comparten datos sin cambios.

La deduplicación no es redundancia, porque guardar menos datos no crea otra copia, y un datastore maravillosamente deduplicado en un servidor sigue siendo un datastore en un servidor.

La guía de PBS de Mr.PlanB actual es útil si necesitas la visión a nivel de funciones. El resto de este artículo se centra en la arquitectura alrededor de PBS.

¿Qué significa 3-2-1 en Proxmox?

En Proxmox, 3-2-1 significa mantener varias copias de los datos importantes, usar más de un tipo de almacenamiento y tener al menos una copia en otra ubicación. La propia documentación de Proxmox recomienda la regla 3-2-1 y señala las ubicaciones remotas y los soportes distintos como formas de aplicarla.

Un entorno pequeño y práctico podría mantener la producción en el clúster de Proxmox, un datastore PBS principal en hardware aparte y un segundo PBS o una copia sin conexión en otra ubicación. Un entorno más grande puede añadir cinta, almacenamiento de objetos u otro centro de datos según los requisitos de recuperación.

Lo que más importa es la independencia. Si los dos servidores PBS usan las mismas credenciales, el mismo servicio de directorio, la misma red de gestión y la misma sala eléctrica, el segundo servidor puede parecer separado mientras sigue dentro de varios dominios de fallo compartidos.

Prefiero una sola copia externa más lenta, difícil de dañar para un administrador de producción comprometido, antes que tres copias rápidas controladas por la misma cuenta.

¿Con qué frecuencia deberían ejecutarse las copias en Proxmox?

La frecuencia de las copias debería fijarla la cantidad máxima de datos que el negocio se puede permitir perder. Ese es tu objetivo de punto de recuperación, o RPO.

Si una carga de trabajo puede perder 24 horas de cambios, puede bastar con una copia diaria. Si perder cuatro horas es inaceptable, una programación diaria está mal por muy fiable que sea el servidor de backup. En bases de datos con mucha actividad, la aplicación también puede necesitar su propia protección consciente de las transacciones, porque un punto de recuperación a nivel de VM no te da recuperación a un punto en el tiempo a nivel de aplicación.

Elegir "cada noche" porque suena a lo estándar es un mal motivo. Escribe el RPO junto a cada carga de trabajo y haz que la programación demuestre que cumple ese objetivo.

El mismo principio se aplica a la retención. Siete puntos diarios sin historial más antiguo pueden recuperar el borrado de ayer, pero fallar cuando se descubre una corrupción tres semanas después. La retención debería reflejar cuánto tiempo pueden pasar los problemas sin que nadie los note.

¿Con qué frecuencia deberías verificar y probar restauraciones?

La verificación debería ejecutarse de forma automática, mientras que las pruebas de restauración deberían hacerse con la frecuencia suficiente para que el equipo recuerde el procedimiento y los fallos aparezcan antes de un incidente. PBS puede verificar los datos de las copias con las sumas de comprobación guardadas, pero la verificación y la restauración responden a preguntas distintas.

La verificación pregunta si los fragmentos guardados siguen coincidiendo con los datos esperados. Una prueba de restauración pregunta si puedes convertir la copia en una VM, un contenedor, un conjunto de archivos o una aplicación que funcione en las condiciones que tendrás durante una caída.

En un entorno pequeño, yo automatizaría la verificación y restauraría una carga de trabajo representativa cada mes. En una plataforma crítica para el negocio, probaría las rutas de recuperación críticas con más frecuencia y anotaría el tiempo transcurrido.

"Restauración correcta" por sí solo te dice poco. Anota cuánto tardaste desde que se declaró la recuperación hasta que el servicio fue utilizable, que es el tiempo de recuperación observado que puedes comparar con el objetivo de tiempo de recuperación.

¿Conviene unir el servidor PBS al mismo dominio de confianza?

Mantén la administración del backup tan independiente como te permita tu entorno. El objetivo es reducir la probabilidad de que una credencial de producción comprometida pueda borrar o dañar todos los puntos de recuperación.

Proxmox documenta que los clientes de backup no reescriben los bloques de copia existentes, lo que ayuda a proteger los datos existentes frente a un sistema cliente comprometido. Eso ayuda, pero el acceso administrativo al servidor de backup sigue siendo muy potente y debería tratarse por separado.

Usa permisos acotados, cuentas de servicio distintas, autenticación multifactor donde se admita y una ruta de gestión que no dependa por completo del clúster de producción. Protege la configuración y las credenciales de PBS con tanto cuidado como el propio datastore.

Para los equipos que montan entornos Proxmox nuevos, merece la pena leer la guía de los 10 errores en Proxmox antes de que el backup se convierta en algo que añades cuando el clúster ya está lleno.

¿Dónde encaja el almacenamiento compatible con S3 en PBS 4.2?

PBS 4.2 mejora el soporte del almacenamiento de objetos compatible con S3 como backend de almacenamiento de copias. Esto abre otra opción para el diseño de capacidad y de copias externas, sobre todo donde mantener un segundo servidor de backup físico es difícil.

El almacenamiento de objetos no elimina la necesidad de entender el rendimiento de la recuperación. Las restauraciones grandes pueden verse limitadas por el caudal de red, el comportamiento del proveedor con las peticiones, el diseño de la caché local y la cantidad de datos que hay que rehidratar.

Antes de convertir el almacenamiento de objetos en tu única ruta de copia externa, restaura una VM real de un tamaño significativo y mide el resultado. Una factura mensual de almacenamiento baja puede dar igual si la ruta de recuperación incumple el RTO del negocio por muchas horas.

Revisa también el alcance de las credenciales, ya que un destino externo es más útil cuando las credenciales que usa producción no pueden destruirlo a la ligera.

¿Cómo sería un plan de backup sencillo para Proxmox?

Para un clúster de Proxmox VE de tres nodos, yo empezaría con un servidor PBS dedicado en hardware y almacenamiento aparte. Ejecuta las copias con una frecuencia derivada de los RPO de las cargas de trabajo, mantén la retención suficiente para cubrir los descubrimientos tardíos y verifica el datastore de forma automática.

Después añade una copia externa mediante un segundo servidor PBS, soportes sin conexión, cinta o un diseño de almacenamiento de objetos que hayas probado. Mantén separadas las credenciales de la copia externa. Restaura de forma programada una VM o un contenedor representativos y anota el tiempo.

Documenta el orden de recuperación. La identidad, el DNS, el almacenamiento, las bases de datos y los sistemas de gestión suelen tener dependencias que hacen que un orden de restauración al azar sea más lento de lo esperado.

Por último, prueba la recuperación cuando el clúster principal no está disponible. Restaurar una VM en un clúster de producción sano es útil, pero no demuestra que puedas reconstruir tras perder el propio clúster.

¿Qué elegiría yo para Proxmox en 2026?

Usaría PBS 4.2 como plataforma principal de backup para un entorno Proxmox VE, lo mantendría fuera de los hosts de producción y conservaría al menos una copia de recuperación fuera del dominio de fallo del sitio principal. Dedicaría más esfuerzo a las pruebas de restauración y a la separación de accesos que a exprimir el último porcentaje de la deduplicación.

Para un homelab con cargas de trabajo reemplazables, un único PBS más una copia sin conexión que se vaya rotando puede bastar. Para una empresa donde el tiempo de inactividad tiene un coste medible, añadiría un segundo sitio u otro destino externo independiente y probaría la secuencia de recuperación completa.

Un plan que produce un panel de backup en verde sigue fallando si no puede responder a dos preguntas: ¿cuántos datos vamos a perder y cuánto tardará el servicio en volver?