Proxmox Backup frente a copias sueltas: prueba y costo
Guía técnica para decidir cuándo usar Proxmox Backup Server, qué guarda, cómo separa permisos y cómo probar restauración antes de producción.
La copia diaria falla el día que nadie sabe qué archivo restaurar primero. En una clínica privada de Godoy Cruz, la diferencia entre copiar una VM y recuperar una agenda de turnos se mide en minutos, permisos y orden de arranque. Proxmox Backup Server entra cuando la operación necesita deduplicación, catálogo, verificación y una prueba repetible. Esta guía muestra qué guarda, cuánto cuesta y dónde se rompe.
Dónde aparece el costo de copiar sin catálogo
La documentación de Proxmox Backup Server describe un servidor de backup con deduplicación, compresión, cifrado opcional, verificación y permisos. La cifra que corrige la discusión está en la deduplicación: cuando varias copias comparten bloques, el repositorio guarda chunks reutilizables y baja el consumo real de disco frente a copias completas repetidas. La Stack Overflow Developer Survey 2025 muestra que SQL mantiene 58,6 % de uso entre todos los respondentes. Ese dato explica por qué una pyme no puede mirar solo la VM: el backup de máquina recupera sistema operativo y servicios; el backup lógico de PostgreSQL ayuda a volver a una tabla, un esquema o una base puntual. El antagonista operativo es la carpeta llamada backups-final-final, con archivos de distintas fechas y sin prueba de lectura. Una etiqueta escrita a mano en un disco externo da calma hasta que alguien pide restaurar el jueves a las 16:20.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. 1. El servidor de producción envía backups de VM, contenedores o directorios al datastore de Proxmox Backup. 2. El datastore guarda chunks deduplicados, manifiestos, índices y metadatos de cada snapshot. 3. El administrador define usuarios, permisos por namespace y tokens para separar lectura, escritura y borrado. 4. El proceso de verificación lee bloques y detecta corrupción antes de una emergencia. 5. Una réplica o remoto sincroniza copias hacia otro sitio según ventana, ancho de banda y retención. 6. La prueba restaura una VM, monta un archivo y recupera una base PostgreSQL desde su backup lógico asociado. Proxmox Backup recibe bloques, archivos, snapshots, credenciales y políticas de retención; entrega catálogo, restauración granular y reportes de verificación. PostgreSQL guarda registros transaccionales y necesita su propia estrategia de dump, WAL o herramienta dedicada. Si Proxmox cae, la pyme pierde el catálogo operativo de copias; si PostgreSQL vuelve sin respaldo lógico, la restauración queda rígida. El punto operativo qué conviene escribir en una hoja de corrida es quién mira cada reporte. Sistemas revisa verificación y espacio; administración confirma qué servicio tiene prioridad; gerencia firma una ventana de prueba. Ese reparto evita que el backup sea una tarea invisible hasta el incidente. También define qué datos pueden borrarse por retención y qué registros deben quedar guardados por contrato o auditoría.
Qué se instala o configura primero
La pila inicial puede usar Proxmox Backup Server, un datastore en ZFS o almacenamiento local confiable, red separada para backups, usuario por servidor, job de verificación, copia remota y monitoreo de espacio. Un servidor dedicado chico con discos puede costar entre USD 700 y USD 1.200; al dólar oficial venta de $1.081.500 a $1.854.000. Ese costo incluye hardware base y discos iniciales, sin instalación, soporte ni repositorio fuera del edificio. UMSA suele empezar con un alcance de una semana: una VM crítica, una carpeta compartida y una base PostgreSQL de ensayo. El entregable verificable es un reporte con tres resultados: backup terminado, verificación sin errores y restauración medida. El equipo directivo no necesita leer comandos; necesita saber qué sistema vuelve, en qué orden y cuánto tarda.
Dónde se rompe y cómo probarlo
El primer riesgo es guardar todo en el mismo edificio. La señal aparece cuando un corte eléctrico o robo deja producción y backup fuera de línea. La prueba mínima es sincronizar un namespace a un remoto y restaurar desde ese destino. El segundo riesgo es dar permiso de borrado al mismo usuario que escribe copias. La señal aparece cuando un token puede crear y eliminar snapshots. La prueba mínima es probar rutas de lectura, escritura y borrado con usuarios separados. El tercer riesgo es medir éxito por copia terminada. La señal aparece cuando el job figura verde, pero la VM restaurada no arranca o la base no abre. La prueba mínima es restaurar una VM de ensayo y correr una consulta real. El cuarto riesgo es olvidar retención y limpieza. La señal aparece cuando el datastore se llena y bloquea nuevas copias. La prueba mínima es revisar política de prune, garbage collection y alerta de espacio. La pregunta incómoda es simple: ¿qué sistema podés restaurar hoy sin pedirle memoria a nadie?
