Copias de seguridad, no agotamiento: Lo que lanzamos en Postgresus 2.0 (y lo que eliminamos)

\ Han pasado 6 meses desde el primer lanzamiento de Postgresus. Durante este tiempo, el proyecto recibió 247 commits, nuevas características, así como ~2.8k estrellas en GitHub y ~42k descargas desde Docker Hub. La comunidad del proyecto también ha crecido, ahora hay 13 contribuidores y 90 personas en el grupo de Telegram.

En este artículo cubriré:

• qué cambió en el proyecto durante seis meses;
• qué nuevas características aparecieron
• cuáles son los planes siguientes.

\

¿Qué es Postgresus?

Para aquellos que escuchan sobre el proyecto por primera vez: Postgresus es una herramienta de backup de PostgreSQL de código abierto con interfaz de usuario. Ejecuta backups programados de múltiples bases de datos, los guarda localmente o en almacenamientos externos, y te notifica cuando los backups se completan o fallan.

El proyecto se despliega con un solo comando en Docker. Puede instalarse mediante script de shell, comando Docker, docker-compose.yml y ahora vía Helm para Kubernetes. Más sobre métodos de instalación.

Además de la característica principal "hacer backups", el proyecto puede:

• Almacenar backups localmente, en S3, CloudFlare R2, Google Drive, Azure Blob Storage y NAS. Más detalles aquí.
• Enviar notificaciones de estado a Slack, Discord, Telegram, MS Teams, vía email y a un webhook configurable. Más detalles aquí.
• Separar bases de datos por espacios de trabajo, otorgar acceso a otros usuarios y guardar logs de auditoría. Más detalles aquí.
• Encriptar backups y credenciales. Más detalles aquí.
• Trabajar tanto con bases de datos autohospedadas como con bases de datos gestionadas en la nube.

Sitio web - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (agradecería una estrella ⭐️)

La interfaz del proyecto se ve así:

Video de descripción general: https://www.youtube.com/watch?v=1qsAnijJfJE

Para aquellos que quieran participar en el desarrollo, hay una página separada en la documentación. Si alguien quiere ayudar al proyecto pero no quiere programar — ¡simplemente cuéntale a tus colegas y amigos sobre el proyecto! Esto también es una gran ayuda y contribución al proyecto.

Sé cómo desarrollar, pero promocionar incluso un proyecto de código abierto es bastante difícil. El proyecto gana reconocimiento gracias a aquellos que hacen reseñas en video y hablan sobre el proyecto en redes sociales. ¡Gracias!

Nuevas características aparecidas en la versión 2.0

Muchas cosas han cambiado durante estos seis meses. El proyecto ha mejorado en cuatro direcciones:

• funcionalidad básica ampliada;
• UX mejorada;
• aparecieron nuevas capacidades para equipos (DBAs, DevOps, equipos, empresas);
• protección y encriptación mejoradas para cumplir con requisitos empresariales.

Veamos cada una.

1) Verificación de salud de la base de datos

Además de backups, Postgresus ahora monitorea la salud de la base de datos: muestra el tiempo de actividad y te alerta si una base de datos no está disponible.

La verificación de salud puede deshabilitarse y configurarse.

Si la base de datos no está disponible — el sistema enviará una notificación al respecto.

2) Nuevas fuentes para almacenar backups y enviar notificaciones

Inicialmente Postgresus solo podía almacenar backups localmente y en S3. Se agregaron Google Drive, CloudFlare R2, Azure Blob Storage y NAS. Los planes incluyen agregar FTP y posiblemente SFTP y NFS.

Para notificaciones, inicialmente el proyecto tenía Telegram y email (SMTP). Ahora también se admiten Slack, Discord, MS Teams y webhooks. Además, los webhooks ahora se configuran de manera flexible para conectarse a diferentes plataformas:

3) Gestión de espacios de trabajo y usuarios

Anteriormente el sistema tenía solo un usuario (administrador), y las bases de datos eran globales para todo el sistema. Ahora Postgresus admite la creación de espacios de trabajo para separar bases de datos y agregar usuarios a espacios de trabajo. Con separación de roles:

• solo visualización (puede ver el historial de backups, descargar archivos de backup);
• edición (puede agregar\eliminar\modificar bases de datos además de leer).

En consecuencia, ahora puedes separar bases de datos:

• bases de datos del cliente X;
• bases de datos de la startup Y;
• bases de datos del equipo Z;

Equipos de DBA y grandes empresas de outsourcing comenzaron a usar Postgresus, por lo que esto se convirtió en una característica importante. Hace que el proyecto sea útil no solo para desarrolladores individuales, DevOps o DBAs, sino para equipos completos y empresas.

También aparecieron logs de auditoría:

Si alguien decidió eliminar todas las bases de datos o por alguna razón descargó todos los backups de todas las bases de datos — esto será visible 🙃

4) Encriptación y protección

En la primera versión, honestamente, no tuve tiempo para la seguridad. Almacenaba todos los archivos de backup localmente, nadie tenía acceso a ellos, y mis proyectos no eran exactamente de alto secreto.

Pero cuando Postgresus se convirtió en código abierto, rápidamente aprendí que los equipos a menudo guardan backups en buckets S3 compartidos y no quieren que otros los lean. Las contraseñas de las bases de datos tampoco deberían almacenarse en la propia base de datos de Postgresus, ya que muchas personas tienen acceso a sus servidores. ~~Y hay cierta desconfianza entre ellos.~~ Simplemente no exponer secretos a través de la API ya no es suficiente.

Así que, la encriptación y seguridad de todo el proyecto se convirtió en la principal prioridad para Postgresus. La protección ahora funciona en tres niveles, y hay una página de documentación dedicada para esto.

1) Encriptación de todas las contraseñas y secretos

Todas las contraseñas de bases de datos, tokens de Slack y credenciales de S3 se almacenan encriptadas en la base de datos de Postgresus. Solo se desencriptan cuando es necesario. La clave secreta se almacena en un archivo separado de la base de datos, por lo que incluso si alguien hackeara la base de datos de Postgresus (que de todos modos no está expuesta externamente) — aún no podrían leer nada. La encriptación utiliza AES-256-GCM.

2) Encriptación de archivos de backup

Los archivos de backup ahora también están encriptados (opcionalmente, pero la encriptación está habilitada por defecto). Si perdiste un archivo o lo guardaste en S3 público — ya no es tan aterrador.

La encriptación utiliza tanto sal como un vector de inicialización único. Esto evita que los atacantes encuentren patrones para adivinar la clave de encriptación, incluso si roban todos tus archivos de backup.

La encriptación se realiza en modo streaming, AES-256-GCM también se utiliza aquí.

3) Uso de usuario de solo lectura para backups

A pesar de los dos primeros puntos, no hay un método de protección 100%. Todavía existe una pequeña posibilidad de que:

• tu servidor sea completamente hackeado, obtengan la clave secreta y la dirección IP legítima para acceder a la base de datos;
• un hacker de alguna manera desencripte contraseñas en la base de datos interna de Postgresus y descubra tu contraseña de base de datos;
• o, peor aún, no será un hacker sino alguien desde dentro;
• y corromperán tu base de datos, habiendo eliminado previamente los backups.

Así que Postgresus debería ayudar a los usuarios a minimizar el daño. La probabilidad de tal hackeo puede ser casi cero, pero eso es un consuelo frío si eres tú a quien le sucede.

Ahora cuando agregas un usuario de base de datos con permisos de escritura a Postgresus, el sistema ofrece crear automáticamente un usuario de solo lectura y ejecutar backups a través de él. Es mucho más probable que las personas creen un rol de solo lectura cuando toma un clic en lugar de configurarlo manualmente en la base de datos.

Así es como Postgresus lo ofrece:

Ofrece muy persistentemente:

Con este enfoque, incluso si tu servidor Postgresus es hackeado, todo se desencripta y los atacantes obtienen acceso a tu base de datos — al menos no podrán corromper la base de datos. Saber que no todo está perdido es un consuelo bastante bueno.

5) Compresión por defecto, la más óptima

La primera versión de Postgresus ofrecía todos los algoritmos de compresión que PostgreSQL soporta: gzip, lz4 y zstd, con niveles de compresión de 1 a 9. Honestamente, no entendía realmente por qué alguien necesitaría todas estas opciones. Simplemente elegí gzip con nivel 5 como lo que parecía un punto medio razonable.

Pero una vez que el proyecto se convirtió en código abierto, tuve que investigar esto realmente. Así que ejecuté 21 backups en todas las combinaciones posibles y encontré el mejor equilibrio entre velocidad y tamaño.

Así que ahora por defecto para todos los backups se establece zstd con nivel de compresión 5, si la versión de PostgreSQL es 16 o superior. Si es inferior — todavía gzip (por cierto, gracias de nuevo a los contribuidores por el soporte de PG 12). Aquí está zstd 5 comparado con gzip 5 (está en la parte inferior):

En promedio, los backups se comprimen ~8 veces en relación con el tamaño real de la base de datos.

6) Soporte de Kubernetes Helm

Este es rápido — agregamos soporte nativo de k8s con instalación Helm. Los equipos que ejecutan k8s en la nube ahora pueden desplegar Postgresus más fácilmente. Tres contribuidores ayudaron con esta característica.

7) Tema oscuro

No soy realmente un fan de los temas oscuros. Pero hubo muchas solicitudes, así que agregué uno (~~gracias Claude por la ayuda y el ojo de diseñador~~). Sorprendentemente, resultó mejor que el tema claro y se convirtió en el predeterminado. Incluso rediseñé el sitio web de claro a oscuro — se veía tan bien.

Antes:

Después:

8) Deshacerse de backups incrementales y PITR (Point In Time Recovery)

Primero, algo de contexto:

• Backup lógico — es cuando PostgreSQL mismo exporta sus datos (a un archivo o grupo de archivos).
• Backup físico — es cuando nos conectamos al disco duro de PostgreSQL y hacemos una copia de sus archivos.
• Backup incremental con soporte PITR — es un backup físico + registro de cambios (WAL), copiado desde el disco o vía protocolo de replicación.

Creía que Postgresus eventualmente debería soportar backups incrementales. Después de todo, ¡eso es lo que hacen las herramientas serias! Incluso ChatGPT dice que las herramientas serias pueden recuperar con precisión hasta el segundo y la transacción.

Así que comencé a trabajar en ello. Pero entonces la realidad golpeó:

• Es muy difícil hacerlo conveniente en términos de UX y DevEx. Porque necesitas conectarte físicamente al disco con la base de datos, o configurar la replicación.

Para la recuperación — no hay opción de no conectarse al disco con la base de datos. Para recuperar desde un backup incremental, la herramienta de backup simplemente restaura la carpeta pgdata (más precisamente, parte de ella).

Si la base de datos es realmente grande, por ejemplo, varios TB y más — se necesita un ajuste fino en las configuraciones. Aquí la interfaz de usuario es más un obstáculo que una ayuda.

• La mayoría de las nubes (AWS, Google, Selectel) no funcionarán con backups incrementales externos, si requieren acceso al disco. En teoría, con algunas soluciones alternativas, vía replicación — lo harán. Pero recuperar de tal backup a una nube gestionada aún no funcionará de todos modos.
• Todas las nubes proporcionan backups incrementales de fábrica. En general, esta es una de las razones por las que son pagadas. E incluso ellas generalmente no permiten recuperación segundo a segundo o a un momento específico de transacción. Y si no estás en la nube — aún más improbable que tu proyecto sea lo suficientemente crítico como para requerir tal precisión.

Por lo tanto, si Postgresus está haciendo un backup de una base de datos gestionada — es suficiente hacerlo aproximadamente una vez por semana. Solo en caso de emergencia imprevista o si la nube no permite almacenar backups por suficiente tiempo. De lo contrario, confía en los propios backups incrementales de la nube.

• Para la mayoría de los proyectos, los backups incrementales no son realmente tan necesarios. Para bases de datos pequeñas, la granularidad entre backups de una hora es suficiente, si se necesita con frecuencia. Para las grandes — al menos una vez al día. Esto es suficiente para el 99% de los proyectos para encontrar datos perdidos o recuperarse completamente. Estas necesidades están totalmente cubiertas por backups lógicos.

Pero si eres un banco o un desarrollador de base de datos gestionada, realmente necesitas la mejor configuración de backup para tus decenas y cientos de terabytes de datos. Aquí Postgresus nunca superará los backups físicos de WAL-G o pgBackRest en términos de conveniencia de consola y eficiencia para bases de datos con volumen en TB y más. Pero, en mi opinión, estas ya son herramientas especializadas para tales tareas, hechas por genios y mantenedores del propio PostgreSQL.

En mi opinión, los backups incrementales son realmente necesarios en dos casos:

• En el pasado, cuando no había tal elección de bases de datos gestionadas en la nube y los proyectos grandes requerían hospedar todo por ti mismo. Ahora los mismos bancos, marketplaces y telecom tienen nubes internas con PITR de fábrica.
• Eres una nube gestionada. Pero aquí la tarea es radicalmente más compleja que solo hacer backups y recuperarse de ellos.

Considerando todo esto, tomé una decisión deliberada de abandonar el desarrollo de backup incremental. En su lugar, me estoy enfocando en hacer backups lógicos tan convenientes, confiables y prácticos para el uso diario por desarrolladores, DevOps, DBAs y empresas.

9) Muchas pequeñas mejoras

Los puntos anteriores están lejos de ser todo. El 80% del trabajo generalmente no es visible. De memoria, aquí hay una lista corta:

• Optimización de buffer y RAM. Postgresus ya no intenta almacenar en buffer todo lo que pg_dump envía mientras espera que S3 se ponga al día (descargar desde la base de datos suele ser más rápido que subir a la nube). El uso de RAM ahora está limitado a 32 MB por backup paralelo.
• Varias mejoras de estabilidad y correcciones de errores menores.
• Agregar SMTP sin nombre de usuario y sin contraseña. Ni siquiera sabía que eso sucede...
• Agregar temas para enviar notificaciones a grupos de Telegram.
• ¡Apareció documentación!
• Soporte para PostgreSQL 12.

Y mucho más.

¿Qué no funcionó?

Por supuesto, no todo funciona y algunas cosas tienen que ser abandonadas. Estoy construyendo Postgresus en mi tiempo libre, que apenas existe. Así que no puedo dispersarme demasiado o complicar la UX con características innecesarias. Demasiadas características también es malo.

1) Monitoreo completo de recursos de base de datos

Quería hacer de Postgresus también una herramienta de monitoreo de PostgreSQL. Incluyendo recursos del sistema del servidor que ejecuta PostgreSQL:

• CPU
• RAM
• ROM
• Velocidad y carga de IO

Incluso hice la base para recopilar métricas (cualquiera) y una plantilla para gráficos:

Resulta que PostgreSQL solo expone el uso de RAM y métricas de IO de fábrica.

Monitorear otros recursos requiere extensiones. Pero no todas las bases de datos pueden instalar las extensiones que necesito, así que solo podría recopilar métricas parciales. Luego descubrí que las bases de datos en la nube a menudo no permiten instalar extensiones en absoluto.

Luego me di cuenta de que las métricas deberían almacenarse en VictoriaMetrics o al menos TimescaleDB, no en el propio PostgreSQL de Postgresus, lo que complicaría la construcción de la imagen.

Al final, esta característica no esencial agregaría:

• complejidad significativa del código, lo que significa mantenimiento más difícil;
• más requisitos de construcción de imagen (componentes adicionales);
• UX complicada (como dije, demasiadas características es malo);
• ~~posicionamiento poco claro: ¿somos una herramienta de backup, una herramienta de monitoreo, o tratamos de hacer todo?~~

Así que abandoné el monitoreo de recursos y me enfoqué en hacer de Postgresus la mejor herramienta de backup que puede ser.

2) Consola SQL

También quería agregar una consola SQL. Ya que Postgresus ya está conectado a la base de datos, ¿por qué no ejecutar consultas directamente desde él? Sería conveniente — no es necesario abrir PgAdmin, DataGrip o DBeaver cada vez.

Nunca encontré tiempo para trabajar en ello, solo lo planifiqué. Un contribuidor comenzó con la característica e hizo un PR. Pero como era de esperar con características complejas, surgieron muchos requisitos y casos extremos:

• necesidad de agregar soporte de sintaxis SQL;
• agregar autocompletado y sugerencias;
• hacer carga perezosa para que incluso 100MB de filas no lleguen al navegador;
• agregar al menos varias exportaciones a CSV y XLSX.

Eso es básicamente un proyecto completo por sí mismo, no solo una pestaña.

Decidimos abandonar la característica y ahorrar el esfuerzo. Esto resultó ser la decisión correcta, ya que agregamos roles de solo lectura que no permiten INSERT, UPDATE y DELETE de todos modos.

Conclusión

Ese es el viaje que Postgresus ha hecho en seis meses. Creció de un proyecto de nicho a una herramienta de nivel empresarial que ayuda tanto a desarrolladores individuales como a equipos completos de DBA (me sorprendió saber esto solo ~2 meses después del primer lanzamiento, por cierto). Estoy genuinamente contento de que miles de proyectos y usuarios confíen en Postgresus.

El proyecto no se detiene aquí. Mi objetivo ahora es hacer de Postgresus la herramienta de backup de PostgreSQL más conveniente del mundo. Hay un gran backlog de características y mejoras que vienen gradualmente.

Mis principales prioridades siguen siendo:

• seguridad del proyecto — esto es crítico, sin ella todo lo demás no tiene sentido;
• UX conveniente en términos de usar el proyecto mismo y sin exceso de características (hacemos una tarea, pero muy bien);
• UX conveniente en términos de despliegue: para que todo se despliegue con un comando y nada necesite ser configurado de fábrica;
• apertura del proyecto — completamente de código abierto y gratuito para cualquier persona o empresa.

Si te gusta el proyecto o lo encuentras útil — agradecería una estrella en GitHub o compartirlo con amigos ❤️

\