Barman frente a pgBackRest: WAL, catálogo y restauración
Dos caminos abiertos para backup de PostgreSQL. Cómo elegir por catálogo, WAL, cifrado, prueba de restauración, alertas y costo mensual medible.
Un catálogo de backups sirve cuando dice qué servidor respalda, dónde guarda cada WAL y qué punto de recuperación ya fue probado. Barman 3.20.0 salió el 27 de agosto de 2026 y elevó su requisito mínimo a Python 3.12, según su release oficial. Esta guía compara Barman y pgBackRest para una pyme que usa PostgreSQL y necesita restaurar datos con horario, responsable y evidencia.
Dónde aparece la decisión de backup
La decisión aparece el día que una consulta de turnos desaparece de producción y el equipo debe volver a las 11:43, no al cierre de ayer. PostgreSQL explica en su documentación de continuous archiving y PITR que el WAL permite reconstruir cambios después de una copia base. Esa frase mueve la discusión desde "tenemos backup" hacia "probamos la hora exacta". La cifra incómoda está en la Stack Overflow Developer Survey 2025: SQL figura en 58,6 % de las respuestas de tecnologías usadas. La base relacional sigue en el trabajo diario, y por eso el backup de PostgreSQL suele proteger caja, stock, turnos, auditoría y facturación al mismo tiempo. En una clínica privada de Godoy Cruz, el detalle de estatus era un talonario de admisión con esquinas dobladas. Seguía ahí porque el sistema de turnos no tenía una prueba de salida confiable. Barman y pgBackRest resuelven el mismo miedo con mecanismos distintos. Barman pone mucho peso en el catálogo central de servidores, comandos claros y tareas de archivo. pgBackRest ordena repositorios, retención, cifrado y paralelismo con una guía muy madura para operación diaria.
Cómo funciona por dentro
El flujo técnico tiene siete pasos. Primero, PostgreSQL escribe cada cambio en WAL y guarda los registros estructurados de la aplicación. Segundo, una copia base toma el estado completo del servidor en un momento conocido. Tercero, Barman o pgBackRest copia WAL hacia un repositorio. En Barman, el catálogo registra servidores, backups, políticas, comandos y estado de chequeo; en pgBackRest, la configuración define stanza, repositorio, retención y cifrado. Cuarto, el almacenamiento guarda archivos de backup y WAL. Puede ser disco local, NFS, S3 o MinIO, con permisos de escritura para el servicio de backup y lectura controlada para restauración. Quinto, el monitoreo lee edad del último backup, atraso de WAL y resultado del último comando. Sexto, una alerta marca atraso, copia fallida o repositorio lleno. Séptimo, la prueba restaura una base real en un servidor aislado y ejecuta una consulta de control. El permiso importa. El usuario de PostgreSQL que archiva WAL no debería administrar la aplicación, y el usuario que consulta reportes no debería borrar repositorios. Si falla el catálogo, se pierde visibilidad; si falla el repositorio, se pierde la copia; si falla la prueba, se pierde confianza operativa. ## Qué se instala o configura primero Para Barman, el primer paso es un servidor de backup separado con Python 3.12, acceso SSH o streaming, configuración por servidor y política de retención. La documentación de Barman 3.20.0 y su referencia de configuración ayudan a definir método de backup, compresión, retención y destino. Para pgBackRest, el primer paso es crear el repositorio, la stanza, el archivo de configuración y la política de retención. Su guía de usuario ordena backup, restore, WAL, cifrado, monitoreo y programación. Con dólar oficial vendedor a $ 1530, una VM de backup de USD 18 a USD 35 por mes queda entre $ 27.540 y $ 53.550. A eso se suma almacenamiento: una pyme con 300 GB de base y retención corta puede empezar con disco dedicado; una empresa con auditoría pesada debería separar repositorio y snapshots. El primer entregable verificable es un informe de restauración: fecha, hora objetivo, backup usado, WAL aplicado, duración y consulta de control. UMSA usa ese formato en proyectos dónde la salida pesa tanto como la instalación, porque el cliente necesita ver una operación recuperada y no una captura del comando.
Dónde se rompe y cómo probarlo
El primer riesgo es archivar WAL en el mismo disco que la base. La señal aparece cuando el repositorio crece junto con producción y ambos se quedan sin espacio. La prueba llena un umbral controlado y revisa que la alerta llegue antes del corte. El segundo riesgo es definir retención por deseo y no por volumen. La señal aparece cuando el backup más viejo desaparece antes del plazo legal o interno. La prueba calcula días, tamaño diario y copia mensual antes de aceptar la política. El tercer riesgo es restaurar solo el motor, sin extensiones ni usuarios. La señal aparece cuando la base levanta y la aplicación falla por permisos, timezone o extensión ausente. La prueba restaura en una VM vacía y ejecuta login, consulta crítica y reporte. La elección queda bastante simple: Barman conviene cuando el catálogo central y la operación guiada pesan más; pgBackRest conviene cuando el equipo quiere repositorios, cifrado y retención muy afinados. El backup que cuenta es el que vuelve con hora escrita.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.