pgBackRest frente a pg_dump: WAL, RPO y restauracion
Comparativa tecnica para elegir pg_dump, WAL o pgBackRest: que guarda cada metodo, que RPO promete, que permisos exige y como 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 despues de una falla. pgBackRest 2.58 arma repositorios, retencion y recuperacion por punto. Esta guia compara pg_dump, WAL y pgBackRest para elegir prueba, costo y primer entregable inicial medible.
Que guarda cada metodo cuando la base cae
La cifra que corrige muchas rutinas esta en la documentacion 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 restauracion 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 mas de 180 millones de desarrolladores y 630 millones de repositorios. Una organizacion mendocina administra menos codigo, 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 ultimo dump usable es de las 2:00.
La guia 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 guia de archivado continuo separa otra necesidad: copiar una base fisica y reproducir WAL para recuperar por punto. pgBackRest ordena esa segunda familia con stanzas, repositorios, compresion, retencion y comandos de restore.
Como funciona por dentro
El flujo minimo tiene siete pasos. Primero, PostgreSQL guarda registros estructurados, usuarios, estados y auditoria 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 politica. 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, ultimo 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 fisicos, catalogo, info y restauracion. PostgreSQL recibe transacciones y entrega WAL. MinIO/S3 recibe objetos de backup y conserva version, 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.
Que se instala o configura primero
La pila inicial usa PostgreSQL 18, pgBackRest 2.58, repositorio S3 o disco dedicado, usuario postgres con permisos minimos, archivo de configuracion, 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 dolar vendedor oficial de $1.419 informado por Bluelytics. Incluye una base, repositorio, tres politicas 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, restauracion 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 tambien 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 medicion, la politica queda escrita y la guardia aprende el costo durante la falla.
Donde se rompe y como probarlo
Primer riesgo: RPO escrito sin archivo WAL. La senal aparece cuando el ultimo WAL archivado queda horas atras. La prueba fuerza una transaccion, ejecuta switch WAL y revisa el repositorio. Segundo riesgo: retencion mal definida. La senal 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 senal 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 configuracion. La senal 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.