Perdí tres meses de trabajo una vez. No en un homelab, en un servidor de producción, pero la lección se me quedó grabada. Desde entonces tengo una regla no negociable: si no hay backup verificado, no existe.
Durante mucho tiempo usé las snapshots de Proxmox como backup. Es cómodo y rápido, pero es una trampa. Las snapshots viven en el mismo almacenamiento que las VMs. Si falla el disco, pierdes las VMs y las snapshots de golpe. Eso no es un backup, es una ilusión de seguridad.
Proxmox Backup Server resuelve esto de forma elegante. Es un servidor de backups dedicado, diseñado específicamente para el ecosistema Proxmox, con deduplicación a nivel de bloque, cifrado opcional y backups incrementales que funcionan de verdad. Y es gratuito, como el propio Proxmox VE en su versión sin soporte comercial.
Por qué PBS y no otras soluciones#
Hay otras opciones para hacer backup de VMs: Veeam, Proxmox VE Backup (el integrado), Bacula, rsync de imágenes de disco. Cada una tiene su sitio.
Las razones por las que me quedé con PBS son concretas. La deduplicación funciona muy bien en el mundo real. Tengo diez VMs que comparten la misma imagen base de Debian. Sin deduplicación, diez backups completos de esas VMs son diez veces los datos. Con PBS, la primera copia guarda todos los bloques únicos y las siguientes solo guardan las diferencias. En mi caso, diez VMs de Debian con aplicaciones diferentes ocupan en PBS lo que ocuparía dos o tres backups completos.
Los backups incrementales son genuinamente incrementales a nivel de bloque, no de archivo. PBS trackea qué bloques de disco han cambiado entre backups usando el dirty bit del guest. Un backup incremental de una VM de 20 GB que solo ha cambiado 500 MB tarda minutos y transfiere exactamente esa diferencia.
La integración con Proxmox VE es nativa. Añades el PBS como almacenamiento en Proxmox, configuras los jobs desde la misma interfaz de PVE que ya usas, y los backups aparecen en el árbol de almacenamiento como si fueran snapshots pero almacenadas de forma remota y deduplicada.
Y el cliente de restauración standalone me da confianza extra. Si pierdo el nodo de Proxmox por completo, puedo restaurar VMs directamente desde PBS sin necesidad del servidor original. Eso es lo que diferencia un backup real de uno que solo funciona en escenarios donde no lo necesitas.
La arquitectura que tengo montada#
No hace falta un servidor dedicado para PBS. Puedes instalarlo como VM dentro de tu propio Proxmox, aunque esto tiene limitaciones obvias: si el host falla, pierdes acceso al PBS también. La recomendación siempre es tener el PBS en hardware separado, pero entiendo que no todo el mundo tiene un servidor extra disponible.
Mi setup tiene PBS instalado en una VM sobre un nodo secundario del cluster. No es ideal pero sí mucho mejor que tenerlo en el mismo nodo que las VMs que quiero proteger. El almacenamiento del PBS apunta a un disco de datos compartido por NFS desde mi NAS, así que los datos físicamente están en un dispositivo diferente a los servidores de Proxmox.
Para un homelab pequeño, esto es razonable. Para producción real, querría PBS en hardware propio con almacenamiento local.
El hardware mínimo para PBS no es exigente. Procesador moderno con extensiones de virtualización (cualquier Intel o AMD de los últimos años sirve), 2 GB de RAM como mínimo (aunque recomiendo 4 GB si vas a manejar muchos datastores), y almacenamiento. El almacenamiento es donde tienes que pensar. PBS gestiona sus datastores en cualquier sistema de ficheros Linux que soporte xattr, pero el rendimiento depende del almacenamiento subyacente.
Instalación paso a paso#
PBS se descarga desde la web oficial de Proxmox como imagen ISO. La instalación es idéntica a la de Proxmox VE: arrancas desde el ISO, sigues el instalador gráfico, configuras red, hostname y contraseña root.
La interfaz web de PBS está en el puerto 8007 por defecto, mientras que Proxmox VE usa el 8006. Esto importa si tienes ambos en la misma red y quieres acceder desde fuera.
Tras instalar, lo primero es crear un datastore. Esto es el almacenamiento donde PBS guardará los backups. Voy a Datastore en el menú lateral, botón “Create Datastore”, le pongo un nombre descriptivo y la ruta al directorio donde quiero que guarde todo. PBS creará ahí su estructura interna con los chunks deduplicados.
Un detalle que me costó: PBS no formatea el directorio donde apunta el datastore, simplemente lo usa como está. Si el directorio está en un filesystem NFS, XFS o ext4 es indiferente. Lo que sí necesitas es que el filesystem soporte xattr para los atributos extendidos que PBS usa para sus metadatos.
La gestión de usuarios en PBS es separada de Proxmox VE. Tienes que crear un usuario específico en PBS para que PVE pueda autenticarse. Voy a Configuration, Users, creo un usuario tipo backup@pbs y le asigno los permisos de Datastore.Backup y Datastore.Read sobre el datastore que acabo de crear.
Conectar Proxmox VE con PBS#
En la interfaz de PVE, voy a Datacenter, Storage, Add, Proxmox Backup Server. Aquí introduzco la IP del PBS, el usuario y contraseña que creé antes, y el nombre del datastore al que quiero conectar. PVE pedirá verificar el fingerprint del certificado del PBS para asegurar que te estás conectando al servidor correcto.
Una vez conectado, el PBS aparece en el árbol de almacenamiento de PVE como un storage más. Ya puedes seleccionarlo como destino de backup.
Para configurar los jobs de backup automáticos voy a Datacenter, Backup, Add. Aquí selecciono el almacenamiento PBS que acabo de añadir, el schedule (yo uso daily a las 03:00), el modo (snapshot es el más rápido y no requiere apagar la VM), y la selección de VMs. Puedes incluir todas las VMs del nodo o seleccionar cuáles quieres incluir.
El modo compresión lo dejo en “zstd” por defecto. Es un buen equilibrio entre velocidad y ratio de compresión. Si tienes CPU de sobra y quieres mejor compresión, “lzo” es más rápido aunque comprime menos. Si tienes tiempo de sobra, “gzip” comprime más pero es lento.
Cifrado: opcional pero lo recomiendo#
PBS soporta cifrado del lado cliente. Esto significa que los datos se cifran en el nodo de PVE antes de enviarse al PBS, con una clave que solo existe en el cliente. El servidor PBS almacena datos cifrados que no puede descifrar por sí solo.
Para homelabs donde el PBS está en la misma red local, el cifrado es opcional. Para homelabs donde el PBS está en una ubicación remota (casa de un familiar, VPS externo) o cuando la seguridad del servidor de backup es una preocupación, el cifrado tiene mucho sentido.
La clave de cifrado se genera en PVE y se almacena localmente. Tienes que hacer copia de ella y guardarla en un lugar seguro externo (contraseña manager, impresa en papel). Si pierdes la clave de cifrado, los backups cifrados son irrecuperables. Esto es intencional pero hay que tenerlo claro.
Prueba de restauración: el paso que nadie hace y debería#
Un backup que nunca has restaurado no es un backup. Es una esperanza.
Cada tres meses hago una prueba de restauración completa de al menos una VM. El proceso en PBS es directo. En PVE selecciono la VM, Backup, la lista de backups disponibles en el PBS, y Restore. Me pide destino, nombre de la VM restaurada y si quiero sobreescribir o crear una nueva. Siempre creo una nueva con un nombre temporal para verificar que funciona antes de tocar nada de producción.
La restauración de una VM de 20 GB tarda 10-15 minutos en mi setup. Tiempo razonable para un escenario de recuperación real.
El verify job del PBS también es valioso. Va a Datastore, Verify Jobs, y programa verificaciones periódicas de integridad de los chunks almacenados. PBS verifica los hash de los bloques y detecta corrupción silenciosa en el almacenamiento. Activo esto mensualmente.
Retención y gestión del espacio#
PBS tiene una política de retención configurable por schedule. Puedo decir “guarda los últimos 7 backups diarios, los últimos 4 semanales y los últimos 3 mensuales”. PBS aplica esta política automáticamente y elimina los backups que caen fuera del rango, liberando espacio.
La deduplicación hace que esto sea más eficiente de lo que parece. Cuando PBS elimina un backup antiguo, no elimina directamente bloques del disco. Los chunks siguen existiendo mientras otro backup los referencie. El proceso de “garbage collection” limpia los chunks que ya no referencia ningún backup. Este proceso lo ejecuto manualmente o automáticamente según el schedule.
En mi datastore con diez VMs y política de retención 7 diarios, ocupo unos 180 GB para lo que serían más de 500 GB de datos sin deduplicación. El ratio varía mucho según qué tan similares sean las VMs entre sí.
Lo que me ha fallado y cómo lo resolví#
El backup de VMs con mucho I/O durante la ventana de backup puede ralentizar el nodo de PVE. PBS usa el dirty tracking del guest para los incrementales, pero la snapshot inicial que se hace al inicio del backup congela brevemente el estado del disco. En VMs de bases de datos con I/O intenso, esto puede causar latencia puntual.
La solución es configurar el throttle de los jobs de backup. En cada job se puede limitar el ancho de banda máximo de transferencia y el número de backups simultáneos. Con dos workers en paralelo y 200 MB/s de throttle, los backups no impactan perceptiblemente el rendimiento de las VMs activas.
El otro problema que tuve fue con la sincronización de tiempo. PBS y PVE necesitan tener el tiempo sincronizado. Si hay diferencia de más de unos segundos, PBS rechaza la autenticación porque los tokens TOTP tienen ventanas de validez estrechas. NTP bien configurado en ambos servidores resuelve esto, pero me costó diagnosticarlo la primera vez.
Monitorización#
PBS tiene métricas de estado accesibles desde la misma interfaz web: espacio usado, espacio libre, tamaño del datastore con y sin deduplicación, jobs recientes y su estado. También expone métricas en formato compatible con Prometheus si tienes Grafana montado.
Para alertas, configuro notificaciones en PBS vía email. En Configuration, Notifications, puedes configurar un servidor SMTP y recibir alertas cuando un job falla o cuando el espacio libre cae por debajo de un umbral.
Con esto tengo cierta tranquilidad operativa. Si un job falla a las 03:00, lo sé por la mañana antes de hacer nada más en el homelab ese día.
Vale la pena el esfuerzo#
La configuración inicial de PBS lleva un par de horas si no lo has tocado antes. La documentación oficial de Proxmox es buena, está bien estructurada y los conceptos de datastore, chunks y deduplicación se entienden con una lectura.
Después de esas dos horas iniciales, el sistema funciona solo. Los jobs corren por la noche, el espacio se gestiona automáticamente con la política de retención, y yo tengo la tranquilidad de saber que si una VM explota mañana tengo una copia de ayer que puedo restaurar en 15 minutos.
El homelab es un entorno donde se experimenta y se rompen cosas a propósito. Eso está bien. Lo que no está bien es perder trabajo real o datos importantes por no tener los backups en orden. PBS quita las excusas.