¿De verdad necesito PBS si Proxmox VE ya hace backups?
Yo también pensé que “con los backups e instantáneas de Proxmox VE voy servido”. Esa idea aguanta… hasta que creces: varias VMs pesadas, contenedores con bases de datos, entornos de pruebas y retenciones largas. Ahí PBS cambia las reglas. La primera vez que lo probé me pasó algo muy claro: el primer backup pesa, pero los siguientes apenas ocupan porque solo se guardan los cambios.
Y cuando te toca restaurar, no tienes que levantar una VM completa para rescatar un par de archivos: la restauración granular te ahorra tiempo, dolores de cabeza y ventanas de caída innecesarias. En resumen: PBS no es “otro servidor más”, es la pieza que convierte las copias de seguridad en una estrategia de continuidad de negocio de verdad.
Requisitos y opciones de despliegue (bare-metal vs VM, ISO y ZFS)
Montar PBS es flexible. Puedes instalarlo en bare-metal (rendimiento y acceso directo a discos) o como VM (comodidad y snapshots del propio servidor de backup, con ciertas precauciones):
- CPU/RAM: con 4 vCPU y 8–16 GB de RAM puedes empezar holgado para decenas de VMs. Si hay compresión agresiva y muchas tareas concurrentes, sube vCPU.
- Discos: separa sistema y datastore. Para el datastore, ZFS en espejado o RAIDZ ofrece integridad y snapshots del propio almacén. SSD/NVMe como cache acelera índices y lectura de chunks.
- Red: si puedes, red dedicada de 10 GbE para tráfico de backup; al menos segmenta por VLAN. Abre solo lo necesario (web/API) y filtra acceso por firewall.
- ZFS: buen encaje en PBS por verificación de integridad, compresión y snapshots. Si usas ZFS, ajusta
ashiftsegún el disco y habilita compresión (ZSTD o LZ4).
Hardware recomendado y sizing inicial
- Pequeño/mediano: 1×CPU 8c/16t, 32 GB RAM, 2×SSD en espejo para sistema, 4–8×HDD para datastore (RAIDZ2), 1×NVMe para metadatos/cache.
- Grande: 2×CPU, 64–128 GB RAM, pool ZFS con mezcla HDD+SSD (SLOG/cache), 10 GbE o 25 GbE.
Redes y puertos clave (H3)
- Web/API de PBS (puerto por defecto): restringe por ACL y lista blanca.
- Tráfico de backup: prioriza QoS, limita ventanas concurrentes y programa tareas fuera de horas pico.
Instalación paso a paso de PBS
Instalar PBS con la ISO oficial es directo:
- Instalación
- Arranca con la ISO y sigue el asistente (disco del sistema, red, usuario
rootcon contraseña o SSH key). - Selecciona ZFS si quieres integridad end-to-end para el sistema (el datastore lo crearás luego).
- Repositorios y actualizaciones (H3)
Tras el primer arranque:
apt update && apt full-upgrade -y
Si usas repos “no-subscription”, asegúrate de habilitarlos correctamente y entiende que son para entornos sin suscripción; en producción, valora la suscripción estable.
- Primer login, fingerprint y hardening básico (H3)
- Accede a la web de PBS (https). Verifica el fingerprint TLS la primera vez y guarda ese hash.
- Crea un usuario de servicio con API Token para enlazar PVE↔PBS.
- Activa 2FA para el acceso administrativo y limita IPs en el firewall.
- Ajusta backups de configuración del propio PBS (sí, respáldalo también).
Crear el Datastore y conectar Proxmox VE
Inicializar discos y crear Datastore (H3)
- En PBS, añade un Directory apuntando al pool/disco que usarás para copias. Dale un nombre claro (p. ej.,
datastore-prod). - Habilita compresión (ZSTD suele dar buen ratio sin penalizar demasiado CPU) y verifica que el path tiene espacio y permisos adecuados.
Registrar PBS en PVE (API token, fingerprint) (H3)
En el Datacenter de Proxmox VE → Storage → Add → Proxmox Backup Server:
- Host: FQDN/IP del PBS.
- Fingerprint: pega el fingerprint que verificaste.
- Token: utiliza el API Token del usuario de servicio (mejor que root).
- Storage: selecciona el
datastore-prod. - Marca Content:
VZDump backup file(ysnippetssi quieres subir scripts).
Primera tarea de backup en modo Snapshot (H3)
- En PVE, crea un Backup Job para un nodo o VM/CT específicos.
- Modo Snapshot es lo común; programa fuera de horas punta.
- Activa Compress (ZSTD), ionice/nice si buscas no impactar producción.
Cuando hice mi primer job de un montón de VMs de laboratorio, noté que el primer pase tardó y ocupó bastante —normal—, pero desde la segunda noche el crecimiento fue mínimo. Esa “serenidad” de ver el datastore estable es adictiva.
Cómo funciona la deduplicación en PBS (y por qué cambia el juego)
La magia está en los chunks: PBS divide los datos en bloques, los identifica por su hash y sólo guarda los que no existen aún. En el primer backup se crean la mayoría; en los incrementales, si el bloque ya está, no se guarda. Resultado: ahorro brutal de espacio y velocidad en backups y restores.
Chunks, incremental y compresión (ZSTD/LZ4) (H3)
- Incremental auténtico: no hay “full sintéticos” complicados; el historial se compone de referencias a chunks existentes.
- Compresión: ZSTD ofrece buen equilibrio entre ratio y CPU. LZ4 es más ligera si vas justo de CPU.
- VMs similares (plantillas, clónicos) deduplican de maravilla; bases de datos comprimidas internamente deduplican menos.
Ahorro real de almacenamiento (H3)
En mi caso, el primer backup “dolió” (varios cientos de GB), pero de ahí en adelante, los siguientes apenas ocupaban. Para visualizarlo, crea informes semanales del datastore y compara crecimiento vs. número de puntos de restauración. Señal de salud: muchos puntos, poco crecimiento.
Restauración que ahorra tiempo: granular, completa y en vivo
Cuando te piden “dos archivos de la VM contable de hace tres días”, no quieres restaurar 200 GB. Con PBS puedes montar el backup y extraer sólo lo necesario.
File restore sin levantar la VM/CT (H3)
- Desde PBS o PVE, lanza File Restore sobre un volumen del backup.
- Monta temporalmente el sistema de archivos del backup y descarga los ficheros puntuales.
- Útil para “ups, borré una carpeta” sin interrumpir producción.
Restore en vivo para recortar ventanas (H3)
- Arranca la VM directamente desde el backup (streaming) y migra en caliente a producción cuando todo esté OK.
- Yo lo uso para probar restauraciones periódicamente sin reservar tanto almacenamiento provisional.
Pruebas de recuperación periódicas (verify + logs) (H3)
- Programa Verify semanal para comprobar integridad.
- Revisa logs y activa alertas; si algo falla, mejor enterarte el lunes a las 8:05 que descubrirlo el día del desastre.
Políticas de retención y mantenimiento (pruning, verify, GC)
Una buena política te da muchos puntos de restauración sin ahogarte de espacio.
Ejemplo de políticas de retención (H3)
- 7-4-12: 7 diarios, 4 semanales, 12 mensuales.
- 14-8-6: 14 diarios, 8 semanales, 6 mensuales (más granular al principio).
- 3-3-3-3: 3 diarios, 3 semanales, 3 mensuales, 3 anuales (entornos que requieren histórico largo).
Ajusta según RPO/RTO y tamaño de tus VMs. Si manejas BD grandes, considera un job diario corto (logs) y otro semanal completo.
Programar verify y garbage collection (H3)
- Verify: garantía de que lees lo que escribiste.
- GC (Garbage Collection): limpia chunks huérfanos tras el prune.
- Agenda: verify semanal, prune y GC tras ventanas de backup.
Métricas y alertas que importan (H3)
- Crecimiento neto del datastore vs nº de snapshots.
- Tiempos de backup/restore y tasa de dedupe.
- Errores por VM/CT y saturación de red/CPU.
Seguridad y cifrado: buenas prácticas operativas
PBS soporta cifrado de backups y control fino por usuarios/tokens.
Gestión de claves y copias fuera de banda (H3)
- Guarda las claves de cifrado fuera de la infraestructura principal (password manager con MFA, caja fuerte digital).
- Documenta el proceso de recuperación de claves: sin ellas, no hay restore.
Fingerprint, TLS y control de acceso por tokens (H3)
- Verifica el fingerprint cuando añades PBS a PVE.
- Usa API Tokens con permisos mínimos en lugar de usuarios admin generales.
- Registra auditoría de accesos y descargas.
Escalar con PBS: múltiples nodos, datastores y copias off-site
A medida que creces, PBS te acompaña.
Recomendaciones de arquitectura (H3)
- Divide por dominios de fallo: producción, preproducción, clientes.
- Varios datastores: por criticidad o por tipo de carga (BD, VDI, etc.).
- Paraleliza jobs con ventanas escalonadas para evitar picos.
Tape y escenarios híbridos (H3)
- Aún hay requisitos de cinta en algunas industrias. PBS permite orquestar librerías para “long-term”.
- Off-site: replica a un segundo PBS en otra ubicación o a almacenamiento externo, cifrado extremo a extremo.
Problemas comunes y soluciones rápidas
Repositorios mal configurados / errores de actualización (H3)
- Comprueba el
sources.listy claves. Asegúrate de usar el repo que corresponde a tu política (enterprise vs no-subscription). - Si una actualización rompe algo, ten snapshot/backup del propio PBS.
“No se ve el Datastore en PVE” (huella/API token) (H3)
- Revisa el fingerprint copiado y la validez del token y permisos.
- Confirma conectividad (DNS, firewall, hora/NTP).
Rendimiento bajo en primeras copias (H3)
- Normal: el primer pase construye el universo de chunks.
- Aumenta concurrencia con cabeza, usa ZSTD, prioriza red estable y discos con buen throughput.
- Evalúa un NVMe para metadatos/índices si el datastore es grande.
Proxmox backup server como núcleo de tu continuidad de negocio
Para pocos nodos y retenciones cortas, el backup básico de PVE “funciona”. Pero en cuanto creces, deduplicación, restore granular y verificación hacen que PBS sea la diferencia entre “tener copias” y dormir tranquilo. En mi experiencia, pasar a PBS me permitió mantener retenciones generosas sin disparar almacenamiento y resolver incidencias con restauraciones puntuales en minutos, no horas. Si tu infraestructura está en expansión, PBS no es un extra: es la base.
FAQs sobre Proxmox Backup Server
¿PBS sustituye a las snapshots de PVE?
No. Las snapshots son útiles para cambios rápidos; PBS es tu histórico consistente y verificable.
¿Puedo instalar PBS en VM?
Sí. Si lo haces, reserva CPU/RAM/IO y evita circularidad (no respaldes PBS en el mismo datastore que protege).
¿Qué compresión elijo?
ZSTD como predeterminado; LZ4 si vas justo de CPU.
¿Cómo calculo retenciones sin reventar el almacenamiento?
Empieza con 7-4-12 y mide crecimiento semanal. Ajusta según RPO/RTO y tasa real de dedupe.
¿Cómo pruebo que “mis backups valen”?
Programa Verify y ensaya restore granular mensual: el día crítico, ya lo tendrás dominado.
Opinión Personal
Proxmox Backup Server no es “otro servidor de copias”: es el punto en el que dejas de rezar para que el backup funcione y empiezas a operar con confianza. Yo también pensé que con las snapshots y los backups básicos de Proxmox VE iba sobrado… hasta que crecí. Cuando gestionas varias VMs pesadas, entornos de prueba y retenciones largas, la deduplicación real de PBS cambia el juego: el primer backup pesa, los siguientes apenas ocupan. Eso te permite ser generoso con la retención sin estar mirando el espacio cada dos días.
Pero lo que más me convence es el cómo recuperas. Con PBS no restauro una VM entera para rescatar dos archivos: monto el backup, bajo lo necesario y sigo con mi vida. Y si necesito reducir al mínimo la ventana, tiro de restauración en vivo. Además, las verificaciones programadas me han ahorrado sustos: prefiero saber el lunes por la mañana que algo falló, no el día del desastre.
¿Requiere disciplina? Sí: planificar retenciones, programar verify/GC y cuidar claves y tokens. ¿Merece la pena? Absolutamente. Si tu infraestructura está creciendo o simplemente quieres dormir mejor, PBS es la decisión adulta.
Ahora te leo a ti: ¿qué te frena para dar el salto a PBS? ¿Qué dudas tienes sobre instalación, retenciones o restores granulares? Déjame tus comentarios y lo debatimos.
