Tener backups en local está bien. Tener un backup que sobreviva a un fallo serio (NAS fuera, nodo caído, un error humano gordo) es otra historia. Por eso el offsite no es un capricho: es lo que hace que el backup tenga sentido cuando de verdad lo necesitas.
En este artículo monto el camino más directo: Proxmox VE local enviando backups directamente al Proxmox Backup Server de Tuxis. En el siguiente artículo ya iremos a la opción “más pro”: PBS local para restaurar rápido en casa y sincronización hacia Tuxis como copia offsite.
Llevo tiempo usando servicios de Tuxis y, en mi caso, la experiencia ha sido estable. Precisamente por eso me encajaba documentarlo como montaje real, con configuración práctica y con restore test, sin humo.
Regla 3-2-1 explicada
La regla 3-2-1 dice que deberías tener tres copias de los datos, en dos medios distintos, y al menos una copia fuera (offsite). Lo típico en homelab es creer que “con PBS ya está”, pero si ese PBS está en el mismo sitio que tu Proxmox, cuando tienes un problema serio te puede caer todo a la vez.
En este artículo cubro justo el “1 offsite”: la copia fuera de casa. Si además tienes una copia local (NAS o PBS local), ya te acercas a un 3-2-1 real.
Requisitos
Necesitas un Proxmox VE operativo con salida a Internet. En mi caso lo he montado en PVE 9.1.1 y el PBS remoto es Proxmox Backup Server 4.1.6. Con versiones actuales no deberías tener problema.
Necesitas una cuenta en el portal de Tuxis y un PBS creado con su datastore. La cuenta free vale para documentar y probar el flujo.
Conviene que el nodo tenga hora correcta (NTP), porque cuando hay desfase de reloj, TLS y certificados te pueden dar guerra.
Arquitectura
Proxmox VE (local) envía backups directamente a un PBS en Tuxis. No hay PBS local en este artículo, solo destino remoto.
Crear el PBS en el portal de Tuxis
En el portal creas el PBS y el datastore. Lo importante es quedarte con tres datos: hostname del PBS, nombre del datastore y el usuario o credencial con permisos para escribir.
Aquí es donde se suele fallar por cosas tontas. Si copias mal el hostname, o si luego en Proxmox apuntas a otro PBS, el fingerprint no va a cuadrar y te va a bloquear la conexión, como debe ser.
Añadir el PBS de Tuxis como storage en Proxmox
En Proxmox ve a Datacenter, Storage y añade un “Proxmox Backup Server”. Lo que estás haciendo es registrar un storage remoto, para poder apuntar los jobs de backup a ese datastore.
En mi caso el ID del storage lo he dejado como tuxis_PBS. Se ve el server, el usuario, el datastore y el contenido “backup”.
Si Proxmox te pide fingerprint, cópialo tal cual. Si no coincide, no conecta. Mejor así. Si no te lo pide, perfecto, pero no te confíes: cuando algo no cuadra, casi siempre es hostname equivocado o copia/pega del fingerprint.
Si quieres validar conectividad antes de seguir, esto te quita dudas rápidamente:
getent hosts TU_HOSTNAME_PBS
nc -vz TU_HOSTNAME_PBS 8007
Crear el job de backup
Ahora toca lo que importa: el job que realmente genera el backup.
En Datacenter, Backup creas un job apuntando al storage tuxis_PBS. En mi caso está en modo Snapshot, con compresión ZSTD y programado para las 05:00. La selección incluye VMs y contenedores concretos.
Mi consejo aquí es simple: empieza pequeño. Configura el job, deja que ejecute bien, revisa verify, y luego ya amplías. El error típico es meter todo el entorno, que falle algo, y acabar sin saber si el flujo funciona o no.
Tiempos reales en mi lab
El rendimiento depende de tu subida, la latencia, el tamaño real y el cambio entre backups. Sin vender humo: en mi lab, en el dashboard del PBS se ven backups del CT 102 rondando los 23–24 minutos (23m54s, 23m41s, 23m36s, 23m28s). La verificación programada aparece entre 6 y 8 minutos (8m17s, 7m18s, 7m11s, 6m29s).
En esa pantalla puede aparecer un aviso tipo “Forbidden (403) permission check failed” en alguna comprobación del dashboard. En mi caso no me ha afectado al backup ni al restore. Si lo ves, que no te distraiga: lo importante es que los tasks de backup y verify están en verde.
Restore test: restaurar con otro ID (sin romper nada)
Esta parte es obligatoria si quieres dormir tranquilo. No vale con “el backup terminó OK”. Hay que restaurar algo.
Para no pisar producción, restauro el contenedor 102 como 202. Primero saco el snapshot exacto desde el storage tuxis_PBS:
pvesm list tuxis_PBS | grep -E 'ct/102|ct-102'
Y restauro el backup como CT 202 en local-lvm:
pct restore 202 tuxis_PBS:backup/ct/102/2026-04-19T03:03:51Z --storage local-lvm
En mi caso, como el backup está cifrado, Proxmox usa la clave configurada durante el restore. El task termina correctamente.
Ojo con una cosa: si el contenedor original tiene IP fija y arrancas el restaurado en la misma red, te puedes pisar. Para una prueba limpia, arráncalo con la red deshabilitada o cambia IP antes de conectarlo.
Problemas comunes
Si no conecta al PBS, lo primero es red: DNS, salida a Internet y puerto 8007. Antes de tocar Proxmox, valida conectividad.
Si te falla por fingerprint, casi siempre es un copia/pega mal hecho o estar apuntando a otro hostname.
Si te da 401 o permisos, revisa el usuario y que tenga permisos sobre el datastore. En PBS los permisos importan más de lo que parece.
Si el backup va lento o se corta, revisa la subida de tu casa, la concurrencia del job y la ventana. A veces no es el destino remoto: es tu línea.
Checklist final
El PBS está creado en el portal y tengo claros hostname, datastore y credenciales. El storage tuxis_PBS está añadido en Proxmox sin errores. El job ejecuta y genera copias en el datastore remoto. Veo tasks de backup y verify en verde y con tiempos coherentes. He hecho un restore real restaurando el CT 102 como CT 202 y el task termina con “TASK OK”.
Si necesitas sabes como instalar un PBS, aquí te dejo un articulo donde lo explico
Espero que os sirva.