pgBackRest frente a pg_dump: WAL, RPO y restauración
Comparativa técnica para elegir pg_dump, WAL o pgBackRest: qué guarda cada método, que RPO promete, que permisos exige y cómo probarlo.
Un dump nocturno deja una foto; un archivo WAL marca hasta que minuto puede volver PostgreSQL. En pymes con facturacion, turnos o stock, esa diferencia decide cuantas operaciones se recargan a mano después de una falla. pgBackRest 2.58 arma repositorios, retencion y recuperacion por punto. Esta guía compara pg_dump, WAL y pgBackRest para elegir prueba, costo y primer entregable inicial medible.
Qué guarda cada método cuando la base cae
La cifra que corrige muchas rutinas esta en la documentación de PostgreSQL: los segmentos WAL son normalmente archivos de 16 MB y registran cambios secuenciales de la base. Esa unidad pequena permite recuperar una base hasta un punto cercano al incidente, siempre que el archivo haya sido archivado y que el respaldo base exista. Un archivo sin restauración medida es una promesa escrita por cron. La escala global muestra por que esta disciplina dejo de ser una rareza de grandes equipos. Octoverse 2025 informo más de 180 millones de desarrolladores y 630 millones de repositorios. Una organización mendocina administra menos código, pero su base guarda turnos, pagos, proveedores, permisos y estados que cambian cada minuto.
Cuando pg_dump sirve y cuando pide WAL
El antagonista es la carpeta de dumps fechados que nadie abrio en seis meses. Un IT manager de una municipalidad chica del Gran Mendoza puede tener un UPS con bateria vencida y un servidor de torre bajo llave. El punto critico aparece cuando tesoreria carga veinte pagos entre las 8:00 y las 10:00, y el último dump usable es de las 2:00. La guía de pg_dump explica que el volcado crea comandos SQL para recrear una base en el estado de inicio del dump. Sirve para migraciones, bases chicas y copias logicas. La guía de archivado continuo separa otra necesidad: copiar una base física y reproducir WAL para recuperar por punto. pgBackRest ordena esa segunda familia con stanzas, repositorios, compresion, retencion y comandos de restore.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, PostgreSQL guarda registros estructurados, usuarios, estados y auditoría en el cluster. Segundo, pgBackRest define una stanza con la ruta del cluster y el repositorio. Tercero, el comando backup toma full, differential o incremental segun política. Cuarto, archive-push envia cada WAL al repositorio. Quinto, el repositorio local o S3 conserva archivos, metadatos, cifrado y retencion. Sexto, monitoreo revisa atraso de WAL, último backup y espacio. Septimo, restore copia backup y WAL a otro host y prueba un punto horario. pg_dump recibe una base y entrega SQL o un archivo custom para pg_restore. pgBackRest recibe archivos del cluster y WAL; entrega backups físicos, catalogo, info y restauración. PostgreSQL recibe transacciones y entrega WAL. MinIO/S3 recibe objetos de backup y conserva versión, fecha y hash. Si falla archive-push, crece pg_wal. Si falla el repositorio, el backup queda incompleto. Si falla el restore, el RPO declarado queda sin prueba.
Qué se instala o configura primero
La pila inicial usa PostgreSQL 18, pgBackRest 2.58, repositorio S3 o disco dedicado, usuario postgres con permisos mínimos, archivo de configuración, retencion, alerta y ensayo mensual. El piloto cuesta entre USD 1.200 y USD 3.600, entre ARS 1,70 y ARS 5,11 millones al dólar vendedor oficial de $1.419 informado por Bluelytics. Incluye una base, repositorio, tres políticas y dos restauraciones. El plazo va de dos a cuatro semanas. UMSA suele pedir un entregable verificable: backup full, incremental, WAL archivado, alerta por atraso, restauración a las 11:35, usuario de solo lectura para control y reporte de duracion. El costo no incluye compra de hardware, enlace dedicado ni limpieza de datos historicos. La primera prueba debe borrar un registro de laboratorio, tomar la hora exacta, restaurar en otro entorno y consultar el registro antes del borrado. El equipo de negocio valida el resultado, no solo IT. Una prueba completa también mide tiempos. El operador anota inicio del incidente, inicio del restore, fin de copia, fin de replay WAL y primera consulta aprobada. Esa tabla deja RTO real, RPO real y espacio usado por cada backup. Sin esa medición, la política queda escrita y la guardia aprende el costo durante la falla.
Dónde se rompe y cómo probarlo Primer riesgo: RPO escrito sin archivo WAL.
La señal aparece cuando el último WAL archivado queda horas atras. La prueba fuerza una transaccion, ejecuta switch WAL y revisa el repositorio. Segundo riesgo: retencion mal definida. La señal es un full viejo borrado antes de que terminen sus incrementales. La prueba lista dependencias con info. Tercer riesgo: repositorio con permisos de lectura publica. La señal aparece cuando otro usuario descarga backups. La prueba intenta leer con credencial ajena y exige rechazo. Cuarto riesgo: restore que solo recupera datos y olvida configuración. La señal es una base viva con usuarios, extensiones o horarios distintos. La prueba restaura cluster, roles, parametros y una consulta real. El backup se termina cuando alguien firma una recuperacion.