pgBackRest ya no recibe mantenimiento

• Aunque fue diseñado como una herramienta de respaldo y recuperación para PostgreSQL capaz de escalar hasta entornos grandes, ahora ha terminado su mantenimiento
• Se suspendieron las correcciones de bugs, la revisión de PR, la atención de issues y el desarrollo de nuevas funciones; en vez de arrastrarlo de forma irregular, se optó por detenerlo con claridad
• Soporta respaldos full, differential e incremental, además de block-level backup, reanudación de tareas interrumpidas y delta restore, para guardar y restaurar solo las partes modificadas
• Cuenta con una protocol layer que cubre entornos locales y remotos, además de multiple repositories, y amplía su alcance operativo mediante conexiones TLS y SSH, así como object stores compatibles con S3, Azure y GCS
• Era una herramienta con amplios mecanismos de garantía de integridad, como checksum, espera de WAL segment, fsync y validación de page checksum, pero de ahora en adelante, incluso si aparece un fork, tendrá que construir su propia confianza desde cero

---

Fin del mantenimiento y estado del proyecto

• pgBackRest es una herramienta de respaldo y recuperación para PostgreSQL, pero actualmente ya no recibe mantenimiento
• Se detuvo el trabajo del proyecto, y se anunció que en adelante no se dedicará tiempo a corrección de bugs, revisión de PR, atención de issues ni desarrollo de nuevas funciones
• Incluso después de que terminaran las formas previas de patrocinio y contratación, se intentó continuar con el mantenimiento, pero no se consiguieron suficientes oportunidades laborales ni patrocinio para sostener el proyecto
• Se consideró mejor darlo por terminado de forma clara, en lugar de mantenerlo de manera irregular o incompleta
• En el futuro alguien podría hacer un fork, pero en ese caso se considerará un proyecto nuevo, y su nuevo mantenedor tendrá que ganarse la confianza por separado

Funciones principales del proyecto

• Apunta a ofrecer respaldo y recuperación escalables hasta entornos PostgreSQL de gran tamaño, y su versión estable actual es v2.58.0
• Está diseñado para reducir el costo de compresión, que suele convertirse en cuello de botella durante los respaldos, usando procesamiento en paralelo y métodos de compresión como lz4 y zstd
• Soporta respaldos full, differential e incremental, y no solo a nivel de archivo: también usa block-level backup para copiar únicamente las partes modificadas y ahorrar espacio de almacenamiento
• Puede reanudar respaldos interrumpidos y vuelve a verificar la integridad de los archivos ya copiados comparándolos con los checksums del manifest
• En delta restore, primero elimina los archivos que no existen en el respaldo y luego compara los checksums de los archivos restantes, dejando intactos los que coinciden y restaurando solo los necesarios

Operación remota y diseño del repositorio

• Mediante su propia protocol layer, puede realizar tareas de respaldo, restauración y archivado tanto en entornos locales como remotos, usando TLS/SSH para las conexiones remotas
• Esa misma protocol layer también ofrece una interfaz de consultas para PostgreSQL, lo que permite trabajar sin conectarse directamente de forma remota a PostgreSQL y mejora la seguridad
• Soporta multiple repositories, por lo que se puede combinar un repositorio local para recuperación rápida con uno remoto para retención de largo plazo y redundancia
• Los repositorios también pueden ubicarse en object stores compatibles con S3, Azure y GCS, lo que permite ampliar considerablemente la capacidad y el tiempo de retención
• El propio repositorio puede cifrarse, de modo que los datos de respaldo queden protegidos sin importar dónde se almacenen

Cómo garantiza integridad y consistencia

• Calcula checksum para todos los archivos del respaldo y los vuelve a verificar durante restore o verify
• Después de terminar la copia de archivos, espera a que todos los WAL segment necesarios lleguen al repositorio para dejar el respaldo en un estado consistente
• Usa fsync a nivel de archivo y directorio en todas las operaciones para asegurar durabilidad
• Si PostgreSQL tiene activado page checksum, en los respaldos full valida los checksums de página de todos los archivos, y en los respaldos differential e incremental valida solo los archivos modificados
• Incluso si falla la validación de page checksum, el respaldo no se detiene, pero se deja una advertencia indicando qué páginas fallaron, para poder detectar page-level corruption de forma temprana antes de que expire un respaldo válido

Procesamiento de WAL y optimización del rendimiento de recuperación

• Ofrece comandos dedicados para WAL push/get, y ambos soportan procesamiento en paralelo y ejecución asíncrona para ajustarse lo mejor posible a los tiempos de respuesta de PostgreSQL
• WAL push elimina automáticamente duplicados cuando llega varias veces el mismo WAL segment, y si el contenido difiere genera un error
• El WAL push asíncrono delega la transferencia a otro proceso y comprime WAL segment en paralelo, algo especialmente importante en bases de datos con una tasa de escritura muy alta
• El WAL get asíncrono mantiene localmente una cola de WAL descomprimido, para poder entregarlo de inmediato antes del replay; esto resulta especialmente ventajoso en conexiones de alta latencia o con repositorios como S3
• Tanto WAL push como get comparan la versión de PostgreSQL y el system identifier para confirmar que la base de datos y el repositorio coinciden, reduciendo mucho la posibilidad de configurar mal la ubicación del archivo WAL

Flexibilidad operativa y compatibilidad

• Las políticas de backup retention y archive expiration pueden configurarse por full, differential y WAL, lo que permite cubrir el rango de tiempo que se necesite
• Los respaldos pueden almacenarse en el mismo formato de PostgreSQL cluster, y si se desactiva la compresión y se habilitan hard links, incluso se puede arrancar directamente un PostgreSQL cluster sobre un snapshot del repositorio
• Este enfoque es ventajoso en una terabyte-scale database donde un restore tradicional tarda mucho tiempo
• Soporta completamente tablespace, y durante restore puede mover cada tablespace a una ubicación distinta o remapearlas todas a una sola ubicación
• También soporta enlaces de archivos y directorios, lo que permite durante restore mantener la ubicación original, remapear algunos o todos, o restaurarlos convertidos en archivos y directorios normales
• Soporta 10 versiones de PostgreSQL, incluyendo las 5 versiones actualmente soportadas y las 5 versiones recientes ya EOL, para dar suficiente margen de tiempo en las actualizaciones

Recursos de referencia y estado del patrocinio

• User guides
• Command reference
• Configuration reference
• El patrocinador actual es Supabase
• Entre los patrocinadores anteriores estuvieron Crunchy Data y Resonate

[xguru]

Se hizo una actualización al respecto.

• Tras anunciar que dejarían de mantener pgBackRest, su buzón se desbordó
• Hubo muchos mensajes de apoyo
• Gracias a una alianza de varios patrocinadores, pgBackRest recibirá financiamiento y podrá continuar con el proyecto
• Además, incorporaron a otra persona encargada del mantenimiento para distribuir la carga de trabajo y mantener la continuidad del proyecto
• La versión actual de pgBackRest funciona con normalidad y no tiene errores graves ni problemas de seguridad, por lo que no es necesario bifurcar el proyecto de inmediato
• Están esforzándose activamente para reactivar pgBackRest

[GN⁺]

Comentarios de Hacker News

• Al ver la publicación del autor en LinkedIn, se nota que realmente invirtió muchísimo tiempo y cariño en pgBackRest durante 13 años, y que ahora decidió dejar de mantenerlo
  Aunque tuvo patrocinio empresarial, siguió metiéndole noches y fines de semana, y después de la venta de Crunchy Data intentó seguir manteniéndolo mientras buscaba un puesto para continuar con este trabajo, pero no le funcionó
  Dice que necesita buscar oportunidades más amplias para ganarse la vida, y que eso significa que ya no podrá dedicar el tiempo necesario al mantenimiento, corrección de bugs, revisión de PRs y atención de issues, por lo que va a archivar el repositorio
• He usado pgBackRest en proyectos personales, al punto de crear una guía de backups de PostgreSQL para volúmenes locales y almacenamiento en la nube, así que me da pena que termine así
  La guía es https://github.com/freakynit/postgre-backup-and-restore-guide y de verdad agradezco todo el tiempo y esfuerzo que le dedicó
  • Creo que últimamente las expectativas alrededor de la IA también han hecho que los desarrolladores trabajen con plazos más apretados y tengan menos tiempo
    Además, mucha gente quemó dinero en tokens, así que en algunos casos también se redujeron tanto el tiempo como el dinero disponible
  • Ojalá no sigamos viendo desaparecer proyectos así por falta de financiamiento, porque las dificultades reales del OSS son demasiado grandes
• Aquí no es que haya fracasado el modelo open source en sí, sino que el autor ya no pudo conseguir más apoyo financiero y está cambiando de rumbo, lo cual me parece totalmente razonable
  Si esto ya era una herramienta a nivel producto, más allá de un proyecto de hobby, y aportaba valor real en entornos comerciales, entonces claramente existe una oportunidad para que una empresa con fines de lucro cubra ese hueco
  Pero los usuarios tienen que convertirse en clientes y pagar de verdad; no es sostenible seguir enviando reportes de bugs y quejas a un mantenedor gratuito
  Hace falta una nueva solución para la sostenibilidad financiera del FOSS, porque las donaciones por sí solas no parecen suficientes
  • He aprendido que, en cualquier ecosistema, si quiero que algo siga vivo, tengo que apoyarlo directamente
    Da igual si es un negocio local o un proyecto open source
  • Me pregunto si el autor consideró convertir esto en un producto de pago
    Aunque cada contribuidor podría tener derechos de autor sobre su parte, así que dependiendo de si existe un ACL y de la jurisdicción, habría que ordenar esos derechos y quizá acordar algo como reparto de ingresos
• Creo que la gente debería fijarse más en la parte de la adquisición de Crunchy Data
  Con patrocinio corporativo esto funcionaba, pero en cuanto la empresa se vendió y el nuevo dueño cambió prioridades, una herramienta de infraestructura con 3.8k estrellas se volvió inestable de inmediato, y los usuarios ni siquiera sabían que el financiamiento de su herramienta de backups dependía de la estrategia de M&A de otra empresa
  Por eso yo también me estoy moviendo poco a poco hacia archivos rastreados con SQLite y git
  Porque incluso los stacks de Postgres administrado terminan apoyándose en varias herramientas mantenidas por personas cuya situación financiera no conocemos
  • No es que haya desaparecido por completo, y al menos por ahora los backups no se van a detener
    Pero la idea general de que la estructura de financiamiento es frágil sigue siendo cierta
  • Aunque SQLite tampoco está completamente libre del mismo riesgo, así que me da curiosidad por qué lo ves como una opción más segura
• El código sigue ahí, así que en vez de solo lamentarlo, también existe la opción de hacer un fork y mantenerlo uno mismo, o pagarle a alguien para que lo haga
  De paso, conviene revisar los proyectos de los que dependemos y que no queremos perder, y empezar a patrocinarlos desde ya
  • Creo que esa actitud es la correcta
    Todos dicen que les da tristeza, pero si de verdad les da tristeza, primero habría que preguntar si les da la suficiente tristeza como para donar
• Hasta donde yo entendía el ecosistema, pgBackRest era la mejor solución en el área de backups para PostgreSQL
  Sobre todo porque no solo se tomaba en serio el backup, sino también la recuperación y validación, y eso es raro; una vez sufrí bastante en el trabajo por haber descuidado justo esa parte
  Los detalles están en https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
  Por eso esto se siente como una pérdida importante
• Es bastante sorprendente; yo pensaba que esto era prácticamente la herramienta de referencia para backup/restore de PG
  Me pregunto cómo se compara con WAL-G o Barman
  https://github.com/wal-g/wal-g
  https://github.com/EnterpriseDB/barman
  • No puedo hacer una comparación exacta, pero nosotros llevamos mucho tiempo usando Barman y estamos muy satisfechos
    Todas las noches generamos una DB nightly restaurada con Barman y la usamos también para capacitación de usuarios y pruebas, verificando continuamente si los backups realmente están corruptos, y en años no hemos tenido problemas
  • Soy uno de los mantenedores de wal-g, y creo que en funcionalidades está a un nivel totalmente comparable
    Estuve inactivo unos años y luego volví al mundo del managed Postgres, y espero que además del delta backup que wal-g ofrece con su propia comparación de bloques, también soporte pg17 incremental backup
    Y de verdad conviene usar el daemon mode
    Es una pena que desaparezca una herramienta competidora, pero en esta área todavía hay mucho por mejorar, y cuando Postgres quiere correr en sistemas sin overcommit, C tiene ventajas sobre Golang
  • Antes usábamos WAL-E y ahora usamos con satisfacción su sucesor, WAL-G
    Cuando evaluamos opciones hace unos 9 años, este nos atrajo más que pgBackRest por sus características de PITR por streaming
  • Entiendo por qué lo veías como la herramienta de referencia, pero también me hace pensar en una situación como https://xkcd.com/2347/
• He usado pgBackRest con buenos resultados en una DB de producción de 2 TB, y justo esta semana pensaba implementarlo también en una DB de 8 TB
  Así que ahora me pregunto si la alternativa más cercana es wal-g, barman o databasus
  Dije que solo estaba jugando a ser DBA, pero en realidad esta elección sí es bastante importante
  • He usado Barman en DBs de más de 30 TB y no tengo grandes quejas
    Como referencia, soy DBRE
  • Si estás respaldando un Postgres de producción de varios terabytes, eso ya no es jugar a ser DBA, eso ya es hacerlo de verdad
  • Si tu configuración guarda backups en almacenamiento en la nube, entonces Barman con hook scripts probablemente sea la alternativa más cercana
    La documentación relacionada es https://docs.pgbarman.org/release/3.18.0/user_guide/hook_scripts.html#hook-scripts-using-barman-cloud-scripts-as-hooks-in-barman
    https://github.com/aiven-open/pghoard también se ve bien, aunque todavía no lo he validado personalmente
  • También me pregunto si alguien ha hecho backups poniendo el standby sobre ZFS o sobre otro sistema de archivos con snapshots
  • Yo ni siquiera había usado pgBackRest antes, pero hace apenas 2 horas empecé a integrarlo en un proyecto, y cuando terminé de leer el README ya estaba actualizado
• pgBackRest está entre las tecnologías de backup de PostgreSQL más versátiles, y por mi experiencia otros productos no llegan hasta ese nivel
  Por eso da todavía más pena, y no parece fácil igualar la paridad de funcionalidades de esta gran herramienta
  Ojalá sea una decisión reversible, y si no, también estaría bien que el proyecto PostgreSQL la absorbiera como contrib
• Todavía se puede seguir usando, así que simplemente puedes continuar con él
  Supongo que el autor preferiría que la gente siguiera usándolo mientras todavía funcione, en lugar de abandonarlo de inmediato
  • Y para ese momento, ojalá alguien dé un paso al frente como nuevo mantenedor
    No sé si haría falta un fork o si alguien podría entrar como contribuidor al repositorio actual y hacerse cargo