Proxmox Backup Server es el servidor de copias que publica Proxmox como producto aparte de Proxmox VE, y es la pieza sobre la que apoyamos las copias de casi todas las plataformas Proxmox que operamos. Hace copias incrementales deduplicadas de máquinas virtuales, contenedores y servidores físicos, las verifica por su cuenta y las replica a otra ubicación sin herramientas de terceros. Montarlo lleva una tarde; que aguante un año en producción sin sorpresas depende de cuatro o cinco decisiones que casi nadie toma al principio. Aquí está nuestra receta y lo que hemos aprendido operándolo.
Qué es Proxmox Backup Server
Proxmox Backup Server (PBS) es una distribución de código abierto basada en Debian, dedicada exclusivamente a guardar y verificar copias de seguridad. Trocea los datos en bloques, guarda cada bloque una sola vez aunque se repita en veinte máquinas distintas, cifra en el cliente si se lo pides y comprueba de forma periódica que lo almacenado sigue siendo legible.
La confusión más habitual es mezclar dos productos distintos. Proxmox VE es el hipervisor donde corren tus máquinas; PBS es un sistema aparte, en otra máquina, que recibe las copias. Proxmox VE sabe hacer copias con vzdump, pero genera un archivo completo cada vez, así que espacio y tiempo crecen con cada pasada. Con PBS solo viajan los bloques que han cambiado. La versión actual es la serie 4, sobre Debian 13.
Cómo lo montamos
El hardware, que decide todo lo demás
La documentación oficial pide como mínimo un procesador de 64 bits con cuatro núcleos y 4 GiB de RAM para el sistema, más 1 GiB adicional por cada terabyte de almacenamiento cuando se usa ZFS. Ese «más 1 GiB por terabyte» es el número que se ignora y luego se paga. Nosotros usamos discos giratorios para la capacidad y los metadatos en SSD (un special device de ZFS en espejo), porque las tareas que recorren millones de bloques son de acceso aleatorio y sobre discos mecánicos tardan días en lugar de horas.
La segunda decisión es dónde vive la máquina. El servidor de copias no puede ser una máquina virtual dentro del mismo clúster al que respalda, ni compartir su almacenamiento. Si se apaga el clúster, las copias tienen que seguir estando.
Almacén de datos y usuarios
Un almacén de datos (datastore) es el sitio donde se guardan los bloques. Creamos uno por cliente o por finalidad y dentro usamos espacios de nombres para separar entornos, en vez de multiplicar almacenes.
proxmox-backup-manager datastore create copias /mnt/datastore/copias
proxmox-backup-manager user create backup@pbs
proxmox-backup-manager acl update /datastore/copias DatastoreBackup --auth-id backup@pbsEse usuario puede hacer copias pero no borrarlas, y eso impide que un servidor comprometido vacíe el almacén. La máquina que hace la copia nunca tiene credenciales para destruirla, y en eso no hacemos excepciones.
Conectar el clúster de virtualización
En Proxmox VE se añade como un almacenamiento más. Hace falta la huella del certificado del servidor de copias, que se obtiene en su panel o con proxmox-backup-manager cert info.
pvesm add pbs copias --server pbs.interna --datastore copias \
--username backup@pbs --fingerprint 64:d3:ff:3a:... --passwordDespués hay que comprobar dos cosas antes de seguir. Que una copia manual de una máquina pequeña termina sin avisos, y que la segunda copia de esa misma máquina tarda mucho menos que la primera. Si no baja, el incremental no está funcionando y el resto del diseño no se sostiene.
Servidores físicos y ficheros sueltos
PBS no sirve solo para máquinas virtuales. En servidores físicos instalamos el cliente y respaldamos el sistema de ficheros contra el mismo almacén, con la misma deduplicación y la misma retención.
proxmox-backup-client backup raiz.pxar:/ \
--repository backup@pbs@pbs.interna:copias \
--exclude /proc --exclude /sys --exclude /mntSi activas el cifrado en el cliente, la clave la tienes tú y solo tú. Sin ella no hay restauración posible, así que su custodia pasa a ser tan crítica como la copia misma.
Retención, verificación y espacio
La retención se define con reglas de conservación por periodos, no con «borra lo de hace un mes». Un punto de partida razonable para una pyme son catorce copias diarias, seis semanales y seis mensuales, y de ahí se ajusta al objetivo de pérdida de datos aceptable, no al espacio que sobra en los discos.
La primera vez sorprende a casi todos que podar copias no libere espacio. Solo elimina la referencia, y el espacio lo devuelve la recolección de basura, que es una tarea aparte y hay que programarla. La verificación es una tercera tarea, la que detecta la corrupción silenciosa del disco antes de que la descubras el día que necesitas restaurar.
proxmox-backup-manager prune-job create diaria --store copias \
--schedule 'daily' --keep-daily 14 --keep-weekly 6 --keep-monthly 6
proxmox-backup-manager datastore update copias --gc-schedule 'Sat 03:00'
proxmox-backup-manager verify copiasLa documentación oficial recomienda reverificar todas las copias una vez al mes. En almacenes grandes repartimos esa verificación por espacios de nombres para que la ventana nocturna no se desborde.
La copia que está fuera
Un único servidor de copias en la misma sala que los servidores protege del borrado accidental, pero no sirve como plan de continuidad. La segunda copia va a otra ubicación mediante una tarea de sincronización, y la dirección importa mucho. Preferimos que sea el servidor remoto quien tire de los datos, porque así el origen no tiene ninguna credencial capaz de escribir ni borrar en el destino. Si la conectividad obliga a lo contrario, PBS también sabe empujar las copias, pero entonces el usuario remoto se restringe al mínimo. La serie 4 añadió además almacenes sobre almacenamiento de objetos compatible con S3, cómodo para la copia externa, aunque conviene leer las notas de la versión antes de confiarle la única copia que tienes fuera.
PBS frente a las alternativas
La pregunta que más nos llega es si compensa frente a Veeam, frente a un NAS o frente a las instantáneas del propio hipervisor.
| Opción | Qué resuelve bien | Dónde flojea | Cuándo la elegimos |
|---|---|---|---|
| Proxmox Backup Server | Incremental deduplicado, verificación, ficheros sueltos y réplica entre sedes, sin licencia | Solo entiende Proxmox y clientes de fichero | Plataformas Proxmox |
| Veeam | Un panel único para entornos mixtos | Licencia por carga y una capa más que mantener | Varios hipervisores conviviendo |
| vzdump a un NAS | Simple y suficiente para pocas máquinas | Archivo completo cada vez, sin deduplicar ni verificar | Una o dos máquinas sin crecimiento |
| Instantáneas y replicación | Volver atrás en segundos y reducir la parada | Viven en el mismo almacenamiento y se borran desde la misma consola | Como complemento, nunca como copia |
Si la plataforma es Proxmox usamos PBS, porque está hecho para ese formato, no cuesta licencias y la restauración de ficheros sueltos resuelve la mayoría de las peticiones reales. Veeam entra cuando hay entornos mixtos bajo un mismo procedimiento, y aparece a menudo en las migraciones de VMware a Proxmox mientras quedan máquinas en los dos lados. Las instantáneas y la replicación las usamos siempre, pero como red de seguridad operativa.
Un escenario típico: copias que tardaban toda la noche
Una empresa industrial de unas ochenta personas, con un clúster Proxmox de tres nodos y unas cuarenta máquinas entre ficheros, gestión y aplicaciones de planta. Las copias se hacían con vzdump a una carpeta de un NAS, completas cada noche. La ventana se había comido la madrugada hasta desbordarse, los lunes seguían corriendo a media mañana con el sistema de gestión notablemente lento, y el NAS estaba tan al límite que la retención efectiva había bajado a cuatro días sin que nadie lo decidiera.
Se montó un servidor de copias dedicado con metadatos en SSD, se migraron las máquinas a copia incremental deduplicada, se escribió una retención (catorce diarias, seis semanales, seis mensuales) y se programaron poda, recolección de basura y verificación mensual. La segunda copia se sincroniza a otra ubicación, que es quien tira de los datos, con credenciales que no existen en la red de la fábrica.
La ventana nocturna quedó en una fracción de lo que ocupaba y el espacio bajó lo suficiente para multiplicar la retención sin comprar discos. Meses después, un borrado accidental de una carpeta de proyectos se resolvió restaurando ficheros sueltos de la copia de la noche anterior, en minutos y sin tocar la máquina virtual entera.
Lo que hemos aprendido
- Los metadatos en SSD no son un lujo. Sobre discos mecánicos sin caché de metadatos, verificación y recolección de basura no caben en un fin de semana y acaban desactivándose «temporalmente» para siempre.
- Podar no libera espacio. Sin recolección de basura programada, el almacén se llena con copias que creías borradas y las tareas fallan de golpe.
- La copia no se protege sola. El diseño de permisos lo pones tú. Un almacén que el servidor de origen puede borrar es un almacén que un atacante también puede borrar; para la retención que debe sobrevivir a un incidente serio, la vía es una copia inmutable fuera de la red.
- Sin prueba de restauración no hay copia. Medimos cuánto tarda una restauración real, porque ese número, y no el porcentaje de copias correctas, responde a cuánto estarías parado.
- Las alertas tienen que llegar a alguien que las lea. Un correo de tarea fallida a una cuenta que nadie mira equivale a no tener alertas. Integramos las notificaciones en nuestra monitorización, con opción de guardia 24/7 para incidencias críticas.
- La clave de cifrado se custodia aparte. Guardada solo en la máquina que se respalda, deja de existir justo el día que la necesitas.
Por dónde empezar
Si ya tienes Proxmox y sigues haciendo copias completas a una carpeta, el primer paso es medir tres cosas antes de comprar nada. Cuánto tarda hoy la ventana de copia, cuántos días de historia tienes de verdad y cuánto tardarías en levantar el servidor más crítico desde cero. Con esos tres números se decide el dimensionado y la retención. Si además valoras salir de VMware, las copias se diseñan a la vez que la plataforma y no después, como planteamos en nuestra solución de migración de VMware a Proxmox.
Nosotros montamos y operamos esta arquitectura dentro del servicio de backup y continuidad de negocio, con retención acordada, verificación, réplica fuera de la sede y pruebas de restauración medidas. Si quieres saber cuánto tardarías hoy en volver a producción tras perder un nodo, cuéntanos cómo tienes montadas las copias y lo revisamos contigo.
Si lo que te preocupa es el ransomware más que el fallo de hardware, la pieza que falta es la inmutabilidad, y la explicamos en por qué tu backup actual no te salva de un ransomware.