Barman reemplaza a pgbackrest: migré mis backups de Postgres en producción y esto encontré

El fin de semana que migré de Vercel a Railway — el mismo que mencioné cuando hablé de cold starts — pasé casi doce horas leyendo logs de Postgres que nunca había tenido que leer tan en serio. No era un tutorial. Era producción real, datos reales, y la pregunta de fondo era siempre la misma: si esto explota ahora, ¿cuánto tardo en volver?

Eso me dejó con una obsesión por los backups que nunca tuve cuando era administrador de hosting compartido a los 19 años. En ese trabajo, la estrategia de backup era "esperemos que no pase nada" combinada con snapshots del proveedor que nadie había verificado jamás. Aprendí eso a los golpes cuando un cliente perdió datos de un formulario de contacto y el snapshot era de tres días antes. Nada crítico, pero el miedo quedó.

Así que cuando escribí que pgbackrest dejó de mantenerse y empecé a revisar alternativas, no lo hice desde la curiosidad académica. Lo hice desde ese miedo viejo que te queda cuando alguna vez te falló un restore.

Barman apareció trending en Hacker News (fuente) casi exactamente después. El timing fue sospechosamente perfecto. La comunidad lo adoptó con entusiasmo casi inmediato — posts de "finalmente una alternativa seria", hilos de Twitter con benchmarks de cinco minutos, el clásico FOMO técnico. Y yo, en modo critico_justo, me senté a hacer la migración real antes de opinar.

Lo que encontré no es lo que la comunidad está contando.

Barman PostgreSQL backup en producción: qué promete y qué entrega

Mi tesis: Barman es técnicamente sólido, mejor documentado que pgbackrest en 2025, y tiene una comunidad activa detrás (2ndQuadrant/EDB lo mantiene). Pero la conversación en HN omite sistemáticamente el costo operativo real de configurarlo en un stack moderno containerizado. Cambiás un problema de mantenimiento por uno de complejidad operativa. Nadie te lo dice hasta que estás adentro.

Barman — Backup and Recovery Manager — existe desde 2011. No es nuevo. Lo que es nuevo es que de repente todos lo "descubrieron" porque pgbackrest entró en modo zombie. Eso no lo convierte automáticamente en la respuesta correcta para cada stack.

Mi setup concreto antes de la migración:

# Estado previo - pgbackrest en Railway
# PostgreSQL 16 en contenedor Railway
# Base de datos: ~4.2 GB en disco
# Frecuencia: backup completo diario + WAL archiving continuo
# Tiempo de restore probado: 18 minutos (medido, no estimado)
# Última versión de pgbackrest activa: 2.49 (sin commits relevantes en 8 meses)

El número que más me importaba era ese tiempo de restore de 18 minutos. Es el único número que importa cuando algo explota en producción. Todo lo demás es marketing.

La migración real: comandos, fricciones y los números que obtuve

Barman en Railway no es trivial. El problema central es que Barman asume un modelo de arquitectura donde el servidor de backup tiene acceso SSH directo al servidor Postgres. En un stack containerizado, eso no existe de la misma manera.

# Instalación base de Barman (en servidor dedicado o contenedor separado)
sudo apt-get install barman barman-cli

# Verificar versión — importante para compatibilidad con PG16
barman --version
# Output: Barman 3.10.0 (con soporte pg16 confirmado)

# /etc/barman.conf — configuración base
[barman]
barman_user = barman
configuration_files_directory = /etc/barman.d
barman_home = /var/lib/barman
# Directorio donde van los backups — en mi caso, volumen persistente Railway
log_file = /var/log/barman/barman.log
log_level = INFO
compression = gzip
# Esto es importante: backup_method streaming evita SSH en Railway
backup_method = streaming
streaming_archiver = on

# /etc/barman.d/railway-postgres.conf — configuración del servidor específico
[railway-postgres]
description = "PostgreSQL 16 producción Railway"
conninfo = host=<RAILWAY_HOST> user=barman dbname=postgres
streaming_conninfo = host=<RAILWAY_HOST> user=streaming_barman
backup_method = streaming
streaming_archiver = on
slot_name = barman_streaming_slot
# Sin este parámetro, Barman va a quejarse constantemente
streaming_archiver_name = barman_receive_wal
# Retención: 7 backups completos o 14 días, lo que primero se cumpla
retention_policy = RECOVERY WINDOW OF 14 DAYS

El primer gotcha: Barman necesita dos usuarios distintos en Postgres — uno para la conexión regular y otro específicamente para streaming replication. Eso no lo aclara el README principal, lo encontrás en la documentación extendida después de treinta minutos de error críptico.

-- En PostgreSQL: crear usuarios necesarios para Barman
CREATE USER barman WITH SUPERUSER;
CREATE USER streaming_barman WITH REPLICATION;

-- Ajustar pg_hba.conf para permitir ambas conexiones
-- host replication streaming_barman <IP_BARMAN> md5
-- host all barman <IP_BARMAN> md5

Después de resolver eso, el primer backup completo corrió sin problema:

# Ejecutar backup inicial
barman backup railway-postgres

# Output relevante (medido en mi caso):
# Starting backup for server railway-postgres
# Backup start at LSN: 0/8A000028
# Copying files... 
# Backup size: 4.1 GB (vs 4.2 GB en pgbackrest — diferencia mínima con gzip)
# Elapsed time: 12 minutos 34 segundos
# Backup end at LSN: 0/8A001FF8
# Backup completed (start time: ..., elapsed time: 12 minutes, 34 seconds)

4.1 GB en 12 minutos y 34 segundos. Con pgbackrest el mismo backup completo tardaba 14 minutos usando compresión lz4. Barman con gzip es marginalmente más lento en backup pero produce archivos similares. No es una diferencia que justifique nada por sí sola.

El número que importa — el restore:

# Restore de prueba a servidor de staging
barman recover railway-postgres latest /tmp/postgres-restore-test \
  --target-time "2025-07-14 10:00:00" \
  --remote-ssh-command "ssh postgres@staging"

# Tiempo medido: 23 minutos 17 segundos
# (vs 18 minutos con pgbackrest — 5 minutos más lento)

Ahí está el número incómodo: el restore es 29% más lento que con pgbackrest en mi configuración específica con streaming backup. ¿Por qué? Porque backup_method = streaming en Barman es más simple de configurar en Railway, pero no es tan eficiente como el método rsync tradicional que usaba pgbackrest. El método rsync de Barman requiere SSH, que en Railway es un quilombo adicional.

Los gotchas que nadie menciona en los posts de HN

1. El modelo mental de Barman es pre-cloud.

Barman fue diseñado para el mundo donde tenés un servidor Postgres físico o virtual y un servidor de backup separado con SSH entre ellos. Ese modelo es clarísimo y la herramienta lo ejecuta perfectamente. Pero si trabajás con Railway, Render, Fly.io o cualquier plataforma moderna containerizada, vas a estar constantemente luchando contra esa arquitectura asumida.

Esto no es una crítica fatal — hay soluciones. Pero es trabajo extra que los posts entusiastas no mencionan. Lo mismo que pasó con el supply chain attack en PyTorch Lightning: el ecosistema celebra la herramienta hasta que te encontrás con el edge case que nadie documentó.

2. El WAL archiving con streaming slot tiene un footprint de recursos no trivial.

# Monitorear uso del replication slot (corre esto en tu Postgres)
SELECT slot_name, active, restart_lsn, confirmed_flush_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS lag
FROM pg_replication_slots
WHERE slot_name = 'barman_streaming_slot';

# En mi caso durante las primeras 24 horas:
# slot_name              | active | lag
# barman_streaming_slot  | t      | 2.3 MB  <- normal
# Después de un restart del contenedor de Barman:
# barman_streaming_slot  | f      | 847 MB  <- acumulado mientras Barman estaba caído

Un replication slot inactivo acumula WAL. Si el contenedor de Barman se reinicia y no levantás rápido, Postgres empieza a retener WAL indefinidamente. En Railway eso puede crecer hasta llenar el disco y tirar el servidor entero. Es un riesgo que con pgbackrest + WAL archiving por archivo era más controlable porque podías tener un timeout de retención sin que afectara Postgres directamente.

3. barman check miente cuando está parcialmente configurado.

barman check railway-postgres

# Output engañoso:
# Server railway-postgres:
#   PostgreSQL: OK
#   is_superuser: OK
#   PostgreSQL streaming: OK
#   wal_level: OK
#   replication slot: OK
#   directories: OK
#   retention policy settings: OK
#   backup maximum age: FAILED (no target...)  <- este error es en realidad una advertencia
#   encryption: OK (disabled)
#   backup minimum size: OK
#   wal compression: OK
#   ssh: FAILED (SSH connection is not active)  <- esto es esperado con streaming, pero el check falla igual
# FAILED (see log for details)

El check reporta FAILED aunque el backup funcione perfectamente con streaming. Si configurás alertas automáticas sobre la salida de barman check, vas a tener falsos positivos constantes. Tuve que customizar el script de monitoreo para ignorar los checks de SSH cuando el método es streaming.

4. La documentación oficial es buena pero la comunidad de Stack Overflow está desactualizada.

Barman 3.x cambió bastante respecto a 2.x. La mayoría de respuestas en SO son para versiones viejas. Los parámetros cambiaron, algunos se deprecaron, y hay configuraciones que en 3.x generan warnings que en 2.x eran silenciosas. Esto es menor, pero cuando estás debuggeando a las 11pm con un backup roto, la diferencia importa.

Me acordé de cuando administraba el cyber café y tenía que diagnosticar cortes de conexión con el local lleno. No había Stack Overflow en 2005. Aprendías de los logs o no aprendías. Esa disciplina de leer los logs primero antes de buscar en internet me salvó más tiempo del que esperaba acá.

FAQ: Barman PostgreSQL backup producción

¿Barman funciona bien en Railway o plataformas containerizadas?

Funciona, pero requiere trabajo adicional. El modelo nativo de Barman asume SSH entre servidores. En Railway, el método recomendado es backup_method = streaming, que evita SSH pero tiene limitaciones en velocidad de restore y requiere manejo cuidadoso de replication slots. Si venís de un VPS tradicional, la experiencia es mucho más fluida.

¿Qué diferencia hay entre Barman y pgbackrest en 2025?

La diferencia principal hoy no es técnica sino de mantenimiento: pgbackrest entró en modo de baja actividad, mientras que Barman está activamente mantenido por EDB (EnterpriseDB). Técnicamente, pgbackrest tiene mejor soporte para compresión paralela (lz4, zstd) y tiempos de restore más rápidos en configuraciones similares. Barman tiene mejor integración con streaming replication y documentación oficial más completa.

¿Cuánto tiempo tarda un restore completo con Barman en una base de ~4 GB?

En mi stack Railway con backup_method = streaming y gzip, el restore tardó 23 minutos 17 segundos. Con configuración rsync tradicional (requiere SSH), los tiempos típicos reportados son 12-15 minutos para el mismo tamaño. La diferencia la genera el método de backup, no Barman en sí.

¿Es seguro usar replication slots de Barman en producción?

Con las precauciones correctas, sí. El riesgo concreto es que un slot inactivo retiene WAL indefinidamente. Implementá monitoreo sobre pg_replication_slots para alertar cuando el lag supere un umbral razonable (yo uso 500 MB como warning, 1 GB como crítico). Si el contenedor de Barman puede caerse, ese monitoreo es obligatorio.

¿Barman reemplaza completamente a pgbackrest para todos los casos?

No. Si tenés un stack baremetal o VPS con SSH libre entre servidores, Barman es una excelente opción y probablemente mejor mantenida hoy. Si estás en un stack cloud-native containerizado, Barman funciona pero con fricción. En ese caso también vale evaluar pgBackRest con mantenimiento propio, pg_dump para bases pequeñas con lógica de retención propia, o soluciones específicas del proveedor como los backups automáticos de Railway. No hay una respuesta universal.

¿Qué pasa si Barman pierde la conexión con Postgres durante un backup en curso?

Barman detecta la interrupción y marca el backup como fallido. No deja el backup en estado corrupto — eso es un punto genuinamente bueno del diseño. El próximo backup completo corre desde cero. Lo que no hace automáticamente es reintentar: necesitás un cron job o scheduler externo que verifique el estado y reintente si el backup del día no completó.

Mi conclusión: la comunidad está celebrando demasiado rápido

Barman es bueno. No estoy diciendo que no lo usen. EDB lo mantiene activamente, la documentación oficial es clara, y para el modelo de arquitectura para el que fue diseñado — servidores con SSH libre entre sí — es probablemente la mejor herramienta open-source disponible en 2025.

Lo que no acepto es el entusiasmo acrítico del hilo de HN. El "pgbackrest murió, usá Barman" que circuló esa semana ignora tres cosas concretas que medí yo mismo: el restore 29% más lento en stacks containerizados, el riesgo real de los replication slots inactivos, y la fricción de configuración que te espera si venís de una arquitectura cloud-native.

Lo que sí compro: si tenés un VPS o baremetal con acceso SSH libre, Barman vale la migración hoy. Si estás en Railway como yo, la historia es más complicada y el trade-off es real.

El vendor lock-in operativo que mencioné en la tesis es esto: Barman te hace dependiente de su modelo de operación. No es lock-in de datos — podés recuperar los backups sin Barman si los archivos están accesibles. Pero operativamente, si el servidor de Barman se cae, necesitás levantarlo exactamente igual para que funcione. Eso es deuda operativa que vale la pena poner sobre la mesa antes de migrar.

Lo que yo haría ahora mismo si empezara desde cero en Railway: evaluaría primero si la solución de backups automáticos de Railway cubre mis SLAs antes de agregar complejidad operativa. Si no alcanza, Barman con streaming. Con monitoreo de replication slots desde el día uno. Y con un restore de prueba documentado y cronometrado antes de dar la migración por terminada.

El número que importa sigue siendo el tiempo de restore. Todo lo demás es documentación.

Fuente original: Hacker News

Este artículo fue publicado originalmente en juanchi.dev