Ya hablamos de PBS para sacar copias fuera de casa hacia S3 y de que un backup de VM no garantiza una base de datos íntegra. Toca el otro lado: entender cómo funciona Proxmox Backup Server por dentro, porque de eso depende que confíes en tus copias. Casi todo el mundo lo usa como una caja negra que «hace backups», y luego se sorprende de dos cosas: de lo poco que ocupan, y —en el peor momento— de descubrir que un backup estaba corrupto y nadie se había enterado.
Las dos sorpresas tienen la misma raíz: no entender las tres piezas que hacen a PBS bueno. La deduplicación, que explica el ahorro de espacio. La verificación, que existe precisamente para que la segunda sorpresa no ocurra. Y la retención, que decide cuánta historia guardas y cuánto espacio recuperas. Este artículo las desmenuza, para que uses PBS con criterio y no como una caja negra en la que rezas que todo vaya bien.
La primera vez que se usa PBS en serio, sorprende: haces un backup diario de un montón de VMs y el repositorio crece muchísimo menos de lo que la aritmética ingenua diría. La magia se llama deduplicación, y funciona así.
PBS no guarda cada backup como una copia entera e independiente. Trocea los datos en bloques (chunks), calcula una huella de cada bloque, y guarda cada bloque único una sola vez en todo el repositorio. Cuando un bloque ya existe —porque no ha cambiado desde ayer, o porque otra VM tiene exactamente los mismos datos—, no se vuelve a guardar: solo se apunta una referencia al bloque que ya está. Y la deduplicación es global: opera sobre todo el repositorio, no VM a VM, así que datos idénticos entre máquinas distintas también se comparten.
Las consecuencias son enormes:
Entender esto cambia cómo dimensionas: no calcules «tamaño de VM × número de backups». El consumo real, con deduplicación, es una fracción de eso. Por eso PBS permite políticas de retención generosas sin que el disco explote.
Aquí está la pieza que separa un backup en el que puedes confiar de uno que solo esperas que funcione. Un backup guardado no es un backup garantizado: los discos sufren corrupción silenciosa (bit rot) —bits que se degradan con el tiempo sin que nada avise—, y un fallo de hardware o de software puede dañar datos ya escritos. Un backup corrupto tiene un problema cruel: parece estar ahí, ocupa su espacio, figura en la lista… hasta que intentas restaurarlo y descubres que no sirve. Y ese descubrimiento, en mitad de un desastre, es el peor momento posible.
PBS resuelve esto con la verificación: trabajos que releen los backups almacenados y comprueban que la huella de cada bloque sigue coincidiendo, detectando cualquier bloque dañado. Es una comprobación de integridad activa que puedes programar para que corra periódicamente sobre el repositorio.
La diferencia de filosofía es clave: la verificación mueve el descubrimiento del fallo del momento del desastre al momento de la calma. En vez de enterarte de que un backup está corrupto cuando desesperadamente lo necesitas, te enteras un martes cualquiera por un aviso de verificación, con tiempo para volver a hacer esa copia. Programar la verificación no es opcional en un backup serio: es lo que convierte «tengo backups» en «tengo backups que sé que funcionan».
Con la deduplicación permitiendo guardar mucho, la pregunta pasa a ser: ¿cuánto quieres guardar? Ahí entran las políticas de retención (prune). En lugar de acumular backups indefinidamente, defines cuántos conservar en cada escala temporal:
Un ejemplo típico: guardar los últimos 7 diarios, 4 semanales y 6 mensuales. Así tienes cada día de la última semana, cada semana del último mes, y cada mes del último semestre, sin guardar 180 copias. Es la forma sensata de tener «historia suficiente» sin acumular sin fin, y encaja con una estrategia 3-2-1 bien pensada.
Aquí un matiz técnico importante que la gente confunde: el prune marca backups para eliminar, pero no libera el espacio inmediatamente. Como los bloques están deduplicados y compartidos, borrar un backup no puede simplemente borrar sus bloques —algunos los usan otros backups—. El espacio lo libera la recolección de basura (garbage collection): un proceso, también programable, que identifica los bloques que ya no referencia ningún backup vivo y esos sí los elimina. La secuencia es: prune (decide qué backups mueren) → garbage collection (recupera el espacio de los bloques huérfanos). Ambos hay que programarlos; sin garbage collection, el espacio de lo «borrado» no vuelve.
Una pieza más que redondea la confianza, sobre todo si los backups salen de casa. PBS soporta cifrado en el lado cliente: los datos se cifran en el nodo Proxmox antes de enviarse al servidor de backup, con una clave que tú controlas. El servidor de backup almacena datos que no puede descifrar.
Esto tiene una implicación potente para los backups offsite: puedes guardar tus copias en un servidor remoto, en otra ubicación, incluso en infraestructura que no controlas al 100 %, con la tranquilidad de que quien tenga acceso físico a ese servidor no puede leer tus datos. Enlaza con la lógica del cifrado en reposo: el dato viaja y reposa cifrado, y solo tú tienes la llave. Con el consabido aviso de siempre: si pierdes esa clave, pierdes los backups. Custódiala como el activo crítico que es.
Reuniendo las piezas, un PBS bien gobernado:
Con esto, PBS deja de ser una caja negra y pasa a ser un sistema de backup que entiendes y en el que puedes confiar. Que es exactamente lo que se le pide a algo cuya única razón de existir es funcionar el día que todo lo demás ha fallado.
¿Por qué ocupan tan poco los backups de Proxmox Backup Server? Por la deduplicación global: PBS trocea los datos en bloques y guarda cada bloque único una sola vez en todo el repositorio. Lo que no cambia entre backups, o lo que se repite entre VMs, no se vuelve a guardar. Por eso cada backup diario añade muy poco y puedes conservar mucho historial sin que el disco explote.
¿Para qué sirve la verificación de backups? Para detectar la corrupción silenciosa (bit rot) o los daños en backups ya almacenados antes de que necesites restaurarlos. La verificación relee los backups y comprueba la integridad de cada bloque. Sin ella, un backup corrupto parece estar bien hasta que intentas usarlo en mitad de un desastre. Programarla mueve el descubrimiento del fallo al momento de la calma.
¿Qué diferencia hay entre prune y garbage collection? El prune aplica la política de retención: decide qué backups se conservan y cuáles se marcan para eliminar. Pero no libera el espacio, porque los bloques están deduplicados y compartidos entre backups. La garbage collection es el proceso que identifica los bloques que ya no usa ningún backup vivo y los borra de verdad, recuperando el espacio. Hay que programar ambos.
¿Cómo defino cuántos backups guardar? Con una política de retención en pirámide: por ejemplo, los últimos 7 diarios, 4 semanales y 6 mensuales. Así tienes granularidad reciente (cada día de la última semana) que se va espaciando hacia atrás, sin acumular copias infinitas. Gracias a la deduplicación, guardar bastante historial cuesta mucho menos espacio del que parece.
¿Es seguro guardar backups de PBS en un sitio que no controlo del todo? Con el cifrado del lado cliente, sí: los datos se cifran en tu nodo antes de salir, con una clave que solo tú tienes, y el servidor de backup guarda datos que no puede leer. Eso hace viable el backup offsite en infraestructura ajena. La contrapartida: si pierdes la clave, pierdes los backups, así que hay que custodiarla con el máximo cuidado.
¿Usas Proxmox Backup Server como una caja negra y no sabes si tus copias resistirían un desastre? Te ayudamos a configurar la verificación, la retención y el cifrado para que tus backups sean de fiar, no una esperanza. Empieza por nuestra comparativa de cloud o hablemos de tu proyecto.
Cómo funciona Proxmox Backup Server por dentro y cómo se monta bien: troceado en chunks y deduplicación global, incrementales para siempre con el dirty bitmap de QEMU, verificación programada, retención con prune y recolección de basura, réplica offsite con sync jobs, S3 y cinta, y los tres caminos de restauración. Con el dimensionado del servidor, los fallos que vemos repetirse y en qué casos Veeam sigue teniendo sentido.
Asignar a tus VMs más CPU y RAM de la que el servidor tiene físicamente —overcommit— es lo que permite meter más máquinas en el mismo hardware. Con la CPU suele salir bien; con la memoria, hecho a la ligera, es la receta de un servidor que muere de golpe. Explicamos por qué la CPU se sobreasigna con tranquilidad y la RAM con mucho cuidado, y las herramientas (ballooning, KSM) para hacerlo con cabeza.
Ceder unas horas de una GPU suele significar crear un usuario, repartir claves SSH, revisar permisos y acordarse de retirarlo todo después. RunSnack reduce eso a ejecutar un script y pasar un enlace que abre una terminal en el navegador, dentro de un contenedor Docker con acceso a la GPU del anfitrión. Es una idea buena y pequeña, con una frontera de seguridad que su propio autor documenta sin adornos: repasamos qué resuelve, qué no, y cuándo la respuesta correcta sigue siendo una máquina virtual.