Barman vs pgBackRest: árbol de decisión para backup PostgreSQL en producción

Hay una pregunta que aparece siempre que alguien crece con PostgreSQL sin un DBA dedicado: ¿qué herramienta uso para backup? La comunidad ya empujó a pgBackRest como la respuesta "moderna". Y Barman lleva años siendo la elección "enterprise". Yo tengo algo para decir, pero no es elegir un ganador — es explicar por qué la pregunta mal planteada te lleva a una decisión equivocada.

Mi tesis es esta: no hay un ganador universal entre Barman y pgBackRest. Barman gana cuando necesitás simplicidad y WAL streaming en tiempo real con poco overhead operacional. pgBackRest gana cuando el volumen crece, necesitás backup incremental paralelo y un restore rápido en bases de datos grandes. El criterio —RTO, RPO, entorno de deploy y tamaño de la DB— importa más que cualquier recomendación genérica.

Esto no lo dice ninguna documentación oficial. Es la fricción que aparece cuando tenés que decidir sin ser DBA y sin que nadie te dibuje el árbol de decisión.

Qué dice cada herramienta de sí misma (y qué no dice)

Antes de cualquier decisión, hay que leer las fuentes sin romantizarlas.

Barman (pgbarman.org) es una herramienta de backup y recuperación para PostgreSQL desarrollada y mantenida por EnterpriseDB. Su documentación oficial describe soporte para WAL streaming en tiempo real vía pg_receivewal, backup base, catálogo de backups, y recuperación point-in-time (PITR). El modelo de configuración es declarativo: un archivo barman.conf por servidor. Se conecta al servidor primario y puede manejar múltiples instancias desde un servidor Barman centralizado.

Lo que la documentación de Barman no dice explícitamente: cuánto tiempo tarda un restore en bases de datos de múltiples terabytes. Eso depende del hardware, de la red y de si tenés compresión activa o no.

pgBackRest (pgbackrest.org) presenta un set de features más amplio: backup full, diferencial e incremental, paralelismo configurable en backup y restore, compresión con múltiples algoritmos (gzip, lz4, zstd), encriptación, y soporte para almacenamiento en S3/GCS/Azure además de local. La documentación oficial incluye guías de configuración extensas y un comando info que muestra el estado de todos los backups catalogados.

Lo que la documentación de pgBackRest no dice explícitamente: que la curva de configuración inicial es sensiblemente más alta que Barman. Un primer setup funcional requiere configurar correctamente los repos, los stanzas, la autenticación SSH o los permisos de cloud storage, y el archivo pgbackrest.conf en el servidor de base de datos. No es difícil, pero tampoco es trivial en un VPS con acceso root propio y sin runbook.

Nada de esto es un defecto de diseño. Es el trade-off honesto entre dos herramientas con prioridades distintas.

Árbol de decisión: cuándo elegir cada una

Antes de elegir, hay cuatro variables que importan. Si las respondés con honestidad, la decisión casi se toma sola.

Variable 1: Tamaño de la base de datos

Para bases de datos que entran cómodamente en decenas de gigabytes, el tiempo de backup completo no es el cuello de botella. Barman funciona bien en ese rango con su modelo de backup base + WAL archiving.

Para bases de datos que crecen en cientos de gigabytes o más, el backup full empieza a ser un problema operacional. pgBackRest con backup incremental y paralelismo configurable (--process-max) cambia la ecuación: en lugar de copiar todo cada vez, copia solo los bloques modificados desde el último diferencial o incremental. La documentación oficial de pgBackRest describe este comportamiento con detalle en la sección de tipos de backup.

Variable 2: RPO requerido (¿cuántos datos podés perder?)

Si el RPO es estricto —digamos, segundos o minutos— necesitás WAL archiving en tiempo real o WAL streaming. Barman soporta pg_receivewal para WAL streaming en tiempo real según su documentación oficial. pgBackRest también soporta WAL archiving, aunque el mecanismo de streaming en tiempo real no es su feature central de marketing.

Si el RPO puede ser horas (un backup diario alcanza), cualquiera de las dos herramientas resuelve el problema.

Variable 3: RTO requerido (¿cuánto tiempo podés tardar en restaurar?)

Este es el punto donde pgBackRest tiene una ventaja documentada: el paralelismo en restore. Si tenés un equipo con múltiples CPUs disponibles durante la restauración, pgBackRest puede usar varios procesos simultáneos para descomprimir y copiar archivos. Barman restaura en serie por defecto.

Para aplicaciones donde el tiempo de restore es crítico y la base es grande, esto no es un detalle menor.

Variable 4: Entorno de deploy

Entorno	Consideración clave	Herramienta que encaja mejor
VPS propio con acceso root	Control total, setup manual viable	Cualquiera; Barman si es primer setup
Bare metal, múltiples instancias	Centralización necesaria	Barman (manejo multi-servidor nativo)
Railway u otros PaaS	Acceso limitado a sistema de archivos y procesos	Ninguna directamente — evaluá `pg_dump` + S3
Cloud con S3/GCS disponible	Storage remoto barato y escalable	pgBackRest (soporte nativo documentado)

La fila de Railway no es casual. En entornos PaaS donde no tenés acceso directo al sistema de archivos del servidor de PostgreSQL, ni Barman ni pgBackRest se instalan de forma estándar. El approach típico en esos entornos es pg_dump periódico hacia un bucket S3, con un script o un job externo. No es elegante, pero es lo que el entorno permite.

Donde se equivoca la gente (y el costo oculto)

El error más común es tratar el backup como una decisión de instalación, no de operación. Se instala Barman o pgBackRest, se corre un primer backup, se chequea que el directorio tenga archivos, y se asume que el problema está resuelto.

El costo oculto aparece después:

1. Nadie prueba el restore. Un backup no probado es teoría. La única forma de validar que el backup sirve es correr un restore en un ambiente de prueba y verificar que la base levanta y los datos son consistentes. Ninguna herramienta puede hacer eso por vos automáticamente — es una decisión operacional que requiere un proceso periódico.

2. El WAL archiving silencioso falla. Barman puede estar corriendo, el proceso pg_receivewal puede estar activo, y aun así el WAL streaming puede interrumpirse sin alarma visible si nadie monitorea el lag entre el último WAL recibido y el WAL actual en el servidor primario. barman check <servidor> devuelve el estado de todos los checks configurados — eso hay que correrlo, no asumirlo.

3. pgBackRest mal configurado en paralelo puede saturar el servidor durante un backup. El parámetro --process-max controla cuántos procesos paralelos usa pgBackRest. En un servidor con workload activo, subir ese número sin medir el impacto puede degradar la base durante el backup. La documentación oficial lo menciona como variable configurable sin dar un valor universal — porque no existe.

4. La retención no se configura sola. Si no configurás una política de retención explícita en Barman (retention policy) o en pgBackRest (repo1-retention-full), el directorio de backups crece indefinidamente. Esto es documentación oficial de ambas herramientas, no una opinión.

Checklist de decisión antes de elegir

Respondé estas preguntas antes de instalar nada:

# Checklist de decisión: Barman vs pgBackRest
# Respondé con honestidad — no hay respuestas incorrectas

[ ] ¿La base supera los 100 GB en producción?
    SÍ → pgBackRest (incremental + paralelismo)
    NO → Barman o pgBackRest, según preferencia

[ ] ¿Necesitás RPO de minutos o menos?
    SÍ → Barman con pg_receivewal O pgBackRest con WAL archiving configurado
    NO → pg_dump + cron puede ser suficiente

[ ] ¿Necesitás RTO de menos de 1 hora en una base grande?
    SÍ → pgBackRest (restore paralelo documentado)
    NO → Barman es viable

[ ] ¿Administrás múltiples instancias PostgreSQL?
    SÍ → Barman (manejo multi-servidor centralizado nativo)
    NO → Cualquiera de las dos

[ ] ¿El entorno es PaaS (Railway, Render, Heroku)?
    SÍ → Ninguna directamente; evaluá pg_dump + S3 con job externo
    NO → Seguí el árbol

[ ] ¿Tenés acceso a S3 o cloud storage compatible?
    SÍ → pgBackRest tiene soporte nativo documentado para S3/GCS/Azure
    NO → Barman con almacenamiento local o NFS

[ ] ¿Es el primer setup de backup serio del equipo?
    SÍ → Barman tiene menos superficie de configuración inicial
    NO → pgBackRest si ya hay experiencia con repos y stanzas

[ ] ¿Hay un proceso de prueba de restore definido?
    SÍ → Cualquiera funciona si el proceso existe
    NO → Empezá por ahí antes de elegir la herramienta

Límites de este análisis

Hay cosas que este post no puede concluir sin experimento propio o datos productivos:

No puedo decir cuánto tarda un restore en vos hardware. Eso depende del disco, la red, la cantidad de WAL acumulado y el tamaño de los datos base. La única forma de saberlo es medir en un ambiente de prueba parecido al de producción.
No puedo decir cuál usa menos CPU o RAM en condiciones de carga mixta. Ambas herramientas tienen parámetros configurables que afectan el impacto en el servidor primario. Sin logs de producción propios, cualquier número que cite aquí sería inventado.
No puedo decir cuál "es más confiable". Ambas tienen años de uso en producción, documentación activa y comunidades reales. La confiabilidad operacional depende de la configuración, el monitoreo y la práctica de restore — no de la herramienta.

Si necesitás validar una decisión con datos propios, el experimento reproducible es claro: instalá la herramienta en un ambiente de staging con un dump de producción anonimizado, corré un backup, medí el tiempo, corré un restore, medí el tiempo, y tomá la decisión con esos números. No con los de nadie más.

FAQ

¿Puedo usar Barman o pgBackRest en Railway?

En Railway, el acceso al sistema de archivos del servidor PostgreSQL y la capacidad de correr procesos auxiliares como pg_receivewal o el agente de pgBackRest están limitados por el modelo PaaS. El approach más pragmático en esos entornos es pg_dump periódico hacia un bucket S3 usando un job externo o un contenedor separado. No es lo mismo que WAL archiving en tiempo real, pero es reproducible y auditable.

¿Barman necesita un servidor dedicado?

No es obligatorio, pero la documentación oficial de Barman asume un servidor Barman separado del servidor PostgreSQL. En un VPS pequeño, es posible correrlos en la misma máquina, pero eso elimina la protección ante falla de hardware del servidor primario. Si el backup y la base viven en el mismo disco, un fallo de disco rompe los dos.

¿pgBackRest puede hacer backup incremental desde el primer día?

No directamente. pgBackRest requiere un backup full como punto de partida antes de poder correr backups diff o incr. La documentación oficial lo describe explícitamente: sin un full previo en el stanza, el primer backup siempre es full independientemente del tipo que especifiques.

¿Qué pasa si no configuro retención?

En Barman, si no configurás retention policy, los backups se acumulan indefinidamente y el espacio disponible se agota eventualmente. En pgBackRest, si no configurás repo1-retention-full, el comportamiento por defecto retiene un número limitado de backups full, pero los WAL asociados pueden acumularse. Revisá la documentación oficial de cada herramienta antes de asumir defaults seguros.

¿Puedo migrar de pg_dump a Barman o pgBackRest sin downtime?

La migración no requiere downtime de la base. Barman y pgBackRest se configuran en paralelo y empiezan a tomar backups sin interrumpir el servicio. Lo que sí requiere es una ventana de validación: correr el primer backup completo, verificar el catálogo, y probar un restore en staging antes de retirar el proceso de pg_dump anterior.

¿pgBackRest es más difícil de configurar que Barman?

En términos de configuración inicial, sí. pgBackRest requiere definir stanzas, configurar repos (local, S3 o cloud), y asegurar que el archivo pgbackrest.conf esté correctamente ubicado tanto en el servidor de base de datos como en el servidor de backup. Barman tiene un modelo de configuración más lineal. La complejidad adicional de pgBackRest viene con features adicionales — no es complejidad gratuita.

Cierre: el criterio antes que la herramienta

Cuando trabajo con PostgreSQL vía Prisma sin un DBA dedicado, la pregunta que me hago no es "¿cuál es la mejor herramienta de backup?" sino "¿qué necesito probar antes de que algo falle en producción?". Esas dos preguntas llevan a respuestas muy distintas.

Mi postura después de analizar ambas herramientas con sus documentaciones oficiales es esta: si el equipo está configurando backup serio por primera vez, Barman tiene menos superficie inicial y el WAL streaming en tiempo real está bien documentado. Si la base ya creció y el tiempo de restore empieza a ser un problema medible, pgBackRest tiene las herramientas para atacarlo — pero hay que invertir en el setup.

Lo que no compro es la versión donde una herramienta "siempre gana". Eso suele ser alguien que encontró lo que le funcionó a escala X y lo generalizó sin mirar el contexto. El criterio —RTO, RPO, entorno, tamaño— importa más que cualquier recomendación genérica.

Y antes de elegir cualquiera de las dos: definí cómo vas a probar el restore. Sin eso, el backup es documentación bonita que nunca leíste.

Si te interesa el ecosistema de herramientas de infraestructura y diagnóstico, también escribí sobre cómo monitorear vos red sin volverte loco con tcpdump y sobre rate limiting en aplicaciones web: qué proteger antes de elegir una librería. Y si trabajás con Next.js y PostgreSQL juntos, el post sobre App Router caching tiene decisiones que aplican directo al stack.

Fuentes originales: