Proxmox Backup 4.2 en escuelas técnicas: restauración con horario
Un caso anonimizado muestra cómo una escuela técnica puede probar backups de aulas, VM y archivos con Proxmox Backup Server 4.2.
Un datastore de Proxmox Backup Server guarda copias incrementales, índices y permisos; si nadie lo verifica, solo es una promesa con interfaz prolija. En una escuela técnica agrotécnica del este mendocino, el laboratorio usaba máquinas virtuales para gestión, prácticas y sensores de riego, pero la restauración dependía del docente que recordaba el último arreglo. Este caso muestra cómo ordenar backup, horario de prueba y evidencia sin frenar clases. ## Dónde aparece el backup que nunca volvió Proxmox publicó Backup Server 4.2 el 29 de abril de 2026 con Debian 13.4, kernel 7.0, ZFS 2.4 y mejoras en organización de grupos, namespaces, sincronización y almacenamiento S3. La cifra que corrige la rutina es el precio de soporte: la suscripción empresarial arranca en EUR 560 por servidor por año, aunque el software se puede descargar y usar como FLOSS. Para una institución, esa cuenta obliga a separar costo de soporte, hardware, discos y horas de prueba. El dato que conecta el caso local con la práctica global está en la documentación 4.2.1: Proxmox Backup Server respalda máquinas virtuales, contenedores y hosts físicos con deduplicación, compresión y cifrado autenticado. La escuela no necesitaba una frase épica sobre continuidad; necesitaba recuperar una VM de preceptoría antes del recreo largo. En el laboratorio, una etiqueta escrita a mano en el gabinete decía "servidor aulas". Ese rótulo era útil para ubicar el equipo, pero inútil para saber qué copia servía y quién podía restaurarla.
Cómo funciona por dentro
El flujo quedó en seis pasos. Primero, Proxmox VE ejecuta las VM de gestión, prácticas y servicios internos. Segundo, Proxmox Backup Server se agrega como almacenamiento desde el datacenter de Proxmox VE o por cliente; la guía de integración y características describe esa relación. Tercero, cada job envía bloques incrementales al datastore. Cuarto, el datastore guarda grupos, snapshots, chunks y namespaces. Quinto, los permisos definen quién puede leer, borrar, verificar o restaurar. Sexto, una prueba mensual restaura una VM chica, abre sesión y guarda evidencia. La base técnica queda visible en piezas concretas. El almacenamiento puede vivir en ext4, xfs o zfs, y la documentación de backup storage explica datastores, namespaces y S3 compatible con comunicación HTTPS. En esta pila, PostgreSQL aparece solo si una aplicación dentro de una VM lo usa; esa base debe entrar en la prueba de restauración de esa VM o en un backup lógico separado. Los permisos importan tanto como el disco. La guía de user management describe usuarios, realms, API tokens y ACL por rutas como datastore o namespace. En una escuela, dirección puede leer reportes; el docente de informática puede ejecutar pruebas; un proveedor puede tener acceso temporal a un namespace; nadie debe borrar retenciones sin acta.
Qué se instala o configura primero
El primer entregable verificable es una restauración con horario: VM de prueba, usuario que ejecuta, duración, hash o captura del servicio levantado y acta corta. El equipamiento mínimo puede ser un servidor usado con discos dedicados o un equipo nuevo de bajo consumo, más almacenamiento externo para copia fuera del sitio. Una prueba inicial razonable queda entre USD 600 y USD 1.200 de hardware, ARS 877.200 a ARS 1.754.400 al dólar oficial vendedor de $1.462, sin incluir mano de obra ni reemplazo de UPS. UMSA puede intervenir en el relevamiento de VM, red, UPS, rotulado y calendario. El foco operativo es dejar una matriz: qué servicio se respalda, con qué frecuencia, cuántas copias se retienen, quién puede restaurar y cuánto tiempo tarda. El primer mes no se mide por cantidad de backups; se mide por una restauración completa antes de una hora pactada. La directora no necesita leer logs de chunks. Necesita saber que preceptoría, biblioteca y prácticas vuelven con usuarios, archivos y fecha correcta.
Dónde se rompe y cómo probarlo
El primer riesgo es respaldar máquinas encendidas con datos inconsistentes. La señal aparece cuando la VM vuelve, pero la aplicación interna muestra errores de base. La prueba restaura, inicia servicio, entra con usuario de prueba y exporta un registro. El segundo riesgo es guardar todo en el mismo sitio. La señal aparece cuando un corte eléctrico largo afecta servidor y backup. La prueba sincroniza una copia a otro lugar o a S3 compatible, corta acceso al servidor principal y revisa si el inventario de copias sigue disponible. El tercer riesgo es borrar por error. La señal aparece cuando un usuario con permiso amplio puede eliminar snapshots vencidos sin revisión. La prueba crea un rol acotado, intenta borrar desde ese usuario y documenta el rechazo. El cuarto riesgo es dejar de verificar por calendario escolar. La señal aparece cuando las pruebas se corren solo después de un incidente. La prueba agenda restauración mensual, rota el responsable y guarda resultado en una carpeta compartida con lectura para dirección. El cierre incómodo es administrativo: si la escuela no puede decir qué vuelve, quién lo restaura y cuánto tarda, el backup queda sin valor operativo.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.