Barman 3.19 en PostgreSQL: WAL, retención y restauración
Barman permite respaldos remotos de PostgreSQL con WAL, catálogo y recuperación a punto en el tiempo. Cómo definir permisos, costo y prueba mínima.
Un archivo WAL decide cuántos minutos de datos puede recuperar PostgreSQL después de una caída. Barman 3.19.1, publicado el 26 de mayo de 2026 según su sitio oficial, administra backups remotos, catálogo y recuperación a punto en el tiempo. Esta guía explica qué guarda Barman, qué conserva PostgreSQL, quién toca las credenciales y cómo probar una restauración antes de firmar que el respaldo existe.
Dónde aparece el backup que nunca volvió
El síntoma se repite en colegios profesionales, clínicas y pymes con sistemas propios: la base tiene copias diarias, pero el cierre del día vive en archivos WAL que nadie revisó. El antagonista concreto es el job verde que dice exitoso sin haber levantado una base recuperada. En una secretaría administrativa de Cuyo, el sello fechador todavía marca expedientes; el sistema debería marcar también el punto exacto al que puede volver. La cifra que corrige la rutina sale de Barman: la versión 3.19.1 figura como release vigente del 26 de mayo de 2026. La documentación lo define como herramienta abierta de administración para recuperación ante desastres de servidores PostgreSQL, escrita en Python y pensada para backups remotos. La escala global llega desde Stack Overflow 2025: 37.341 respuestas declararon influencia o decisión sobre compras tecnológicas. PostgreSQL aparece entre las bases usadas por equipos profesionales; cuando esa base guarda cuotas, turnos o expedientes, la compra técnica real es tiempo recuperable. El backup sirve cuando alguien puede elegir una hora y abrir el sistema restaurado.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, PostgreSQL guarda registros estructurados: usuarios, cuotas, estados, tickets o auditoría. Segundo, el servidor activa archivado o streaming de WAL. La guía de PostgreSQL sobre continuous archiving explica que la recuperación combina backup base y registros WAL para llegar a un punto posterior. Tercero, Barman recibe backups base y WAL desde cada servidor definido. Cuarto, el catálogo guarda identificador de backup, fecha, tamaño, estado, servidor y archivos asociados. Quinto, una política de retención decide cuántos backups quedan disponibles. Sexto, monitoreo avisa si falta WAL, si el último backup venció o si un servidor dejó de enviar. Séptimo, una prueba de recuperación restaura en otra ruta y abre una consulta real. La documentación de Barman describe el archivo WAL como pieza necesaria para recuperar una base y recomienda configurar streaming o archivado. También documenta barman-wal-archive para copiar WAL con fsync en destino. Barman recibe archivos y metadatos; entrega catálogo, comandos de restore y reportes de estado. PostgreSQL entrega datos y WAL; el almacenamiento conserva bloques, backups y logs. IT administra claves SSH, usuarios barman y postgres, retención y pruebas.
Qué se instala o configura primero
La pila inicial usa PostgreSQL 17 o superior, Barman 3.19, un servidor de backup separado, disco con espacio medido, usuario barman, clave SSH restringida, monitoreo y una carpeta de restauración. Si se usa nube, la guía de Barman Cloud documenta barman-cloud-backup para crear backup local y transferirlo a proveedor compatible. El costo mensual de infraestructura para una base chica puede ubicarse entre USD 45 y USD 130, entre ARS 67.500 y ARS 195.000 al dólar oficial de venta de ARS 1.500. El rango cubre servidor de backup, almacenamiento, monitoreo y copia externa mínima. Diseño de RPO, limpieza de bases y simulacros quedan como horas de proyecto. El primer entregable verificable es una restauración fechada: backup base, WAL aplicado, usuario de prueba, consulta de control y reporte con duración. UMSA puede ayudar cuando la organización necesita separar copia, catálogo, permisos y prueba para dejar de confiar en un correo de tarea exitosa.
Dónde se rompe y cómo probarlo
El primer riesgo aparece con WAL incompleto. El indicador es un backup base disponible y un hueco de minutos sin archivos WAL. La prueba es detener el servidor de aplicación a una hora elegida y recuperar hasta cinco minutos antes. El segundo riesgo aparece con claves demasiado amplias. El indicador es una clave SSH qué permite shell completo desde producción al servidor de backup. La prueba es ejecutar solo el comando permitido y confirmar rechazo para acciones fuera de Barman. El tercer riesgo aparece con retención que borra antes de tiempo. El indicador es un pedido de restauración de hace 45 días con política de 30 días. La prueba es documentar RPO, RTO y días de retención con gerencia antes de aplicar prune. El cuarto riesgo aparece en una recuperación hecha sobre un directorio vivo. La guía de recovery advierte detener PostgreSQL y no restaurar sobre una instancia en uso. La prueba usa una ruta limpia, levanta el servicio y ejecuta consultas de aceptación. El backup queda aceptado cuando el responsable puede leer un reporte con hora objetivo, backup usado, WAL aplicado y consulta abierta.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.