pgBackRest frente a Barman: WAL, costo y restauración

Un backup PostgreSQL vale cuando vuelve a levantar la caja. La comparación entre pgBackRest y Barman empieza por la restauración que la empresa necesita demostrar. En la encuesta 2025 de Stack Overflow, SQL aparece usado por el 58,6% de quienes respondieron. Esa cifra ayuda a dimensionar por qué un error de respaldo en una base transaccional sigue siendo un riesgo operativo directo. ## La decisión empieza en el punto de recuperación pgBackRest publicó la versión 2.59.1 el 17 de agosto de 2026, con foco en respaldo y restauración para PostgreSQL. El proyecto declara copias completas, diferenciales e incrementales, repositorios múltiples, restauración delta, archivado asíncrono y soporte para S3, Azure, Google Cloud y SFTP. Barman muestra la versión 3.20.0 del 27 de agosto de 2026 y se presenta como administrador de respaldos y recuperación para varias instancias PostgreSQL desde un lugar central. La elección práctica suele girar sobre tres preguntas: cuántas bases hay, quién opera la consola a las tres de la mañana y cuánto tiempo se puede perder. Si hay una sola base crítica y un equipo chico, pgBackRest puede quedar más cerca del servidor y del procedimiento de restauración. Si hay varias instancias, ambientes y ventanas de retención distintas, Barman ordena catálogo, políticas y recuperación centralizada. Para equipos sin guardia permanente, la alerta vale tanto como el respaldo. Un correo diario con “backup ok” sirve poco si nadie sabe leer el repositorio, revisar espacio libre, confirmar el último WAL archivado o levantar una copia en otro host. La política debería decir cuántas copias se conservan, qué alerta llega por falta de WAL, quién la recibe y cuánto tiempo tiene para responder antes de escalar el incidente.

Cómo funciona por dentro PostgreSQL registra cambios en archivos WAL dentro de pg_wal.

La documentación oficial explica que la recuperación continua combina una copia base con una secuencia completa de WAL archivados para volver a un punto del tiempo. Ahí aparece la primera diferencia operativa: la herramienta no reemplaza la disciplina de archivar, monitorear y probar. Si el archivado falla y pg_wal se llena, la base puede quedar fuera de servicio hasta liberar espacio. El flujo mínimo tiene seis pasos. Primero se activa wal_level en modo replica, archive_mode y el comando o librería de archivado. Segundo se define dónde quedan los repositorios: disco local, almacenamiento de objetos o servidor dedicado. Tercero se toma una copia base. Cuarto se archiva WAL de manera continua. Quinto se ejecuta una restauración de ensayo en un servidor aislado. Sexto se mide el punto de recuperación y el tiempo total hasta abrir la aplicación. La prueba de punto en el tiempo merece una fecha incómoda, no una fecha redonda. Conviene elegir una venta, una cobranza o una orden cargada veinte minutos antes del corte y confirmar qué aparece al restaurar. Después se repite con una hora anterior, para comprobar que la base vuelve al estado solicitado y que la aplicación no lee datos mezclados de otro ambiente.

Qué se instala o configura primero

En pgBackRest, la primera configuración real es el stanza: nombre, rutas de datos, repositorios, retención y compresión. Después se corre check, backup y restore en ambiente de prueba. En Barman, el inicio está en registrar servidores PostgreSQL, definir método de conexión, directorios, streaming o archivado por comando, y reglas de retención por servidor. En ambos casos, el registro de la última restauración exitosa pesa más que cualquier comentario de configuración. Un proyecto UMSA lo baja a una matriz simple: base protegida, tamaño, frecuencia de backup, destino, retención, última restauración, responsable y evidencia. Para una pyme con 200 GB a 500 GB de datos, un servidor de respaldo, almacenamiento externo y monitoreo básico puede quedar entre USD 60 y USD 120 mensuales, entre $91.800 y $183.600 al dólar oficial vendedor de $1.530. Ese valor no incluye horas de migración, limpieza de tablas ni guardias fuera de horario.

Dónde se rompe y cómo probarlo

El antagonista del respaldo PostgreSQL es el backup nocturno que nadie restauró. Puede verse prolijo en el correo diario, pero fallar por permisos, WAL incompleto, repositorio lleno o contraseña vencida. La prueba debe ser incómoda y repetible: restaurar en otro servidor, abrir la aplicación contra esa base, comparar conteos de registros, revisar la hora recuperada y guardar los logs de la herramienta. También hay que probar el peor día posible. Un cambio de versión PostgreSQL, un archivo WAL corrupto, un repositorio que responde lento o una clave expirada pueden cambiar una restauración de veinte minutos en una mañana perdida. La salida técnica es escribir el procedimiento con comandos, tiempos, evidencias y criterio de corte: cuándo seguir intentando restaurar, cuándo volver a la última copia completa y quién toma la decisión.

Para seguir leyendo

La documentación de recuperación continua de PostgreSQL es la base conceptual. Las notas de pgBackRest y la documentación de Barman permiten revisar capacidades actuales. En Última Milla, la guía sobre Kopia en pymes sirve para comparar respaldo de archivos contra respaldo de bases.