pgbackrest/pgbackrest

 (github.com/pgbackrest)
3 puntos por GN⁺ 2 일 전 | 1 comentarios | Compartir por WhatsApp
  • Herramienta de respaldo y recuperación para PostgreSQL, diseñada para escalar incluso a entornos grandes, pero actualmente está en estado de fin de mantenimiento
  • Se detuvieron por completo los bug fixes, 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 trabajos interrumpidos y delta restore, para guardar y recuperar solo las partes modificadas
  • Cuenta con una protocol layer que abarca entornos locales y remotos, además de multiple repositories, y amplía su alcance operativo mediante conexiones TLS y SSH y 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 verificación de page checksum, pero de ahora en adelante, incluso si aparece un fork, tendrá que construir su propia confianza por separado

Fin de 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 bug fixes, revisión de PR, atención de issues ni desarrollo de nuevas funciones
  • Incluso después de que terminaran los patrocinios y esquemas de empleo previos, se intentó continuar con el mantenimiento, pero no se consiguieron suficientes oportunidades laborales ni patrocinios para sostener el proyecto
  • Se consideró mejor terminarlo de forma clara, en lugar de continuar con un mantenimiento irregular o incompleto
  • En el futuro alguien podría hacer un fork, pero en ese caso se considerará un proyecto nuevo y el nuevo mantenedor tendrá que ganarse la confianza por su cuenta

Funciones clave del proyecto

  • Apunta a respaldos y recuperación escalables hasta entornos PostgreSQL de gran escala, y la 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, mediante 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, sino también con block-level backup para copiar solo 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 están en el respaldo y luego compara 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, recuperación y archivado tanto en entornos locales como remotos, y usa TLS/SSH para conexiones remotas
  • Esa misma protocol layer también ofrece una interfaz de consultas para PostgreSQL, lo que permite trabajar sin conectarse remotamente de forma directa a PostgreSQL y mejora la seguridad
  • Soporta multiple repositories, por lo que se puede usar a la vez un repositorio local para recuperación rápida y uno remoto para retención a 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 periodo de retención
  • El repositorio en sí 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 revisar durante restore o verify
  • Después de terminar la copia de archivos, espera a que lleguen al repositorio todos los WAL segment necesarios para dejar el respaldo en un estado consistente
  • En todas las operaciones usa fsync a nivel de archivo y directorio para asegurar durabilidad
  • Si page checksum está activado en PostgreSQL, en los respaldos full verifica los checksums de página de todos los archivos, y en los respaldos differential e incremental verifica solo los archivos modificados
  • Aunque falle la verificación de page checksum, el respaldo no se detiene; en cambio, deja una advertencia sobre qué páginas fallaron para poder detectar temprano page-level corruption antes de que expire un respaldo válido

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

  • Proporciona comandos dedicados para WAL push/get, y ambos soportan procesamiento en paralelo y ejecución asíncrona, diseñados para mantener el tiempo de respuesta de PostgreSQL lo más rápido posible
  • WAL push elimina automáticamente duplicados si el mismo WAL segment entra varias veces, y si el contenido es distinto genera un error
  • El WAL push asíncrono delega la transferencia a otro proceso que comprime WAL segment en paralelo, por lo que es especialmente importante en bases de datos con volúmenes de escritura muy altos
  • El WAL get asíncrono mantiene localmente una cola de WAL descomprimido para poder suministrarlo de inmediato antes del replay, lo que resulta especialmente ventajoso en conexiones de alta latencia o repositorios como S3
  • Tanto WAL push como get comparan la versión de PostgreSQL y el system identifier para verificar que la base de datos y el repositorio coincidan, reduciendo en gran medida la posibilidad de configurar mal la ubicación del WAL archive

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 guardarse en el mismo formato del PostgreSQL cluster, y si se desactiva la compresión y se habilitan hard links, incluso se puede iniciar directamente un PostgreSQL cluster sobre un snapshot del repositorio
  • Este enfoque es ventajoso en una terabyte-scale database donde la restauración tradicional tarda mucho tiempo
  • Soporta completamente tablespace, y durante restore cada tablespace puede moverse a una ubicación diferente o remapearse en bloque a una sola ubicación
  • También soporta enlaces de archivos y directorios, por lo que en restore se puede conservar la ubicación original, hacer remap parcial o total, o convertirlos y restaurarlos como archivos o directorios normales
  • Soporta 10 versiones de PostgreSQL, incluidas las 5 versiones actualmente soportadas y las 5 más recientes ya EOL, de modo que haya tiempo suficiente para realizar actualizaciones

Recursos de referencia y estado del patrocinio

Lecturas relacionadas

1 comentarios

 
GN⁺ 2 일 전
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