Técnico
pgBackRest 2.59.2: WAL, RPO y restauración
Guía técnica para decidir backups de PostgreSQL con pgBackRest: WAL, repositorios, retención, permisos, costos, prueba de recuperación y salida real.
Un servidor de USD 24 al mes puede guardar copias mejores que un snapshot tomado sin saber cuántos minutos de datos se aceptan perder. pgBackRest 2.59.2 trabaja con backups y WAL de PostgreSQL para recuperar una base a un punto preciso. Para una clínica de Godoy Cruz, la pregunta operativa es cuánto demora volver una agenda, una admisión o una caja sin reconstruir datos a mano.
Dónde aparece la restauración que falta
La página de releases de pgBackRest marca la versión 2.59.2 como publicada el 27 de septiembre de 2026 y lista correcciones sobre backup, archive-push y archivos truncados a cero durante una copia. Esa cifra corrige una comodidad peligrosa: el backup existe, pero la restauración depende de que también vuelvan WAL, repositorio, configuración y permisos. PostgreSQL documenta que el archivado continuo combina una copia base con segmentos WAL para recuperar la base. La guía oficial nombra el punto central: los cambios se escriben en WAL antes de llegar a los archivos de datos. El antagonista técnico es el snapshot nocturno que parece suficiente hasta que una tabla cambia a las 10:17 y el corte llega a las 10:23. La conexión global aparece en la Stack Overflow Developer Survey 2025: SQL figura con 58,6 % de uso entre todos los respondentes. Para una pyme, ese dato aterriza en una decisión sencilla: si la base guarda turnos, facturas o stock, la restauración debe medirse con una hora y un archivo abierto, no con una casilla marcada.
Cómo funciona por dentro
El flujo mínimo tiene seis pasos. 1. PostgreSQL escribe transacciones en WAL y guarda tablas, índices y estados en el directorio de datos. 2. pgBackRest ejecuta backup completo, diferencial o incremental y lo guarda en un repositorio local, SFTP o S3 compatible. 3. archive-push copia cada segmento WAL al repositorio para permitir recuperación a un punto cercano al corte. 4. Un rol de administración ejecuta backups y restauraciones; los usuarios de negocio solo consultan reportes de estado. 5. La retención borra copias vencidas y conserva las necesarias para cumplir RPO y plazo interno. 6. La prueba restaura una base en otro servidor, corre una consulta real y registra duración, tamaño y último WAL aplicado. pgBackRest recibe archivos de datos y WAL; entrega conjuntos de backup, metadatos, logs y comandos de restore. PostgreSQL recibe la base restaurada y reproduce cambios hasta el punto elegido. El monitoreo debe mostrar última copia, último WAL archivado, tamaño de repositorio y error de envío. Si falla el repositorio, la base sigue funcionando, pero el reloj de recuperación empieza a perder minutos.
Qué se instala o configura primero
La pila inicial puede usar PostgreSQL 17, pgBackRest 2.59.2, repositorio S3 compatible, usuario dedicado, claves fuera del repositorio, backup diario, WAL continuo y alerta por atraso de archive-push. Un servidor 4 vCPU y 8 GB cuesta entre USD 24 y USD 45 por mes; al dólar oficial venta de $1545 equivale a $37.080 a $69.525. Ese costo incluye cómputo básico; quedan aparte almacenamiento, egreso, implementación y soporte. La ficha de arranque debe anotar tamaño de base, frecuencia de WAL, ventana de copia y responsable de restauración. UMSA suele empezar con una restauración antes de ampliar el alcance. El primer entregable verificable es una base restaurada en ambiente separado, una consulta que muestre el último turno o factura, una medición de RPO real y un documento con responsables. La gerencia recibe tres datos: cuánto se perdió, cuánto tardó volver y quién puede ejecutar el procedimiento. El acta queda firmada por sistemas y gerencia.
Dónde se rompe y cómo probarlo
El primer riesgo es archivar WAL tarde. La señal aparece cuando archive-push acumula cola o muestra errores repetidos. La prueba mínima es cortar red en ensayo, restaurarla y medir cuántos segmentos quedaron pendientes. El segundo riesgo es mezclar permisos. La señal aparece cuando una cuenta de aplicación puede borrar copias. La prueba mínima es separar usuario de base, usuario de repositorio y cuenta de restore. El tercer riesgo es retener sin cálculo. La señal aparece cuando el repositorio crece y nadie sabe qué copia se puede borrar. La prueba mínima es fijar retención, ejecutar expire y revisar que una fecha elegida todavía restaure. El cuarto riesgo es probar solo el comando. La señal aparece cuando el restore termina, pero la aplicación no abre. La prueba mínima es levantar base, credenciales y variable de conexión en otro ambiente. El backup vale cuando alguien puede leer la pantalla restaurada antes de firmar que volvió.
