Sauvegardes, pas d'épuisement : Ce que nous avons livré dans Postgresus 2.0 (et ce que nous avons abandonné)

\ Cela fait 6 mois depuis la première version de Postgresus. Pendant cette période, le projet a reçu 247 commits, de nouvelles fonctionnalités, ainsi que ~2,8k étoiles sur GitHub et ~42k téléchargements depuis Docker Hub. La communauté du projet a également grandi, il y a maintenant 13 contributeurs et 90 personnes dans le groupe Telegram.

Dans cet article, je vais couvrir :

• ce qui a changé dans le projet au cours des six mois ;
• quelles nouvelles fonctionnalités sont apparues
• quels sont les plans pour la suite.

\

Qu'est-ce que Postgresus ?

Pour ceux qui entendent parler du projet pour la première fois : Postgresus est un outil de sauvegarde PostgreSQL open source avec interface utilisateur. Il exécute des sauvegardes programmées de plusieurs bases de données, les enregistre localement ou sur des stockages externes, et vous notifie lorsque les sauvegardes sont terminées ou échouent.

Le projet se déploie avec une seule commande dans Docker. Il peut être installé via un script shell, une commande Docker, docker-compose.yml et maintenant via Helm pour Kubernetes. Plus d'informations sur les méthodes d'installation.

Outre la fonctionnalité principale "faire des sauvegardes", le projet peut :

• Stocker des sauvegardes localement, dans S3, CloudFlare R2, Google Drive, Azure Blob Storage et NAS. Plus de détails ici.
• Envoyer des notifications de statut à Slack, Discord, Telegram, MS Teams, par e-mail et vers un webhook configurable. Plus de détails ici.
• Séparer les bases de données par espaces de travail, accorder l'accès à d'autres utilisateurs et enregistrer les journaux d'audit. Plus de détails ici.
• Chiffrer les sauvegardes et les identifiants. Plus de détails ici.
• Travailler avec des bases de données auto-hébergées et des bases de données gérées dans le cloud.

Site web - https://postgresus.com/

GitHub - https://github.com/RostislavDugin/postgresus (une étoile serait appréciée ⭐️)

L'interface du projet ressemble à ceci :

Vidéo d'aperçu : https://www.youtube.com/watch?v=1qsAnijJfJE

Pour ceux qui souhaitent participer au développement, il existe une page séparée dans la documentation. Si quelqu'un veut aider le projet mais ne veut pas coder — parlez simplement du projet à vos collègues et amis ! C'est aussi une grande aide et une contribution au projet.

Je sais comment développer, mais promouvoir même un projet open source est assez difficile. Le projet gagne en reconnaissance grâce à ceux qui font des critiques vidéo et parlent du projet sur les réseaux sociaux. Merci !

Nouvelles fonctionnalités apparues dans la version 2.0

Beaucoup de choses ont changé au cours de ces six mois. Le projet a été amélioré dans quatre directions :

• fonctionnalités de base élargies ;
• UX améliorée ;
• nouvelles capacités pour les équipes (DBA, DevOps, équipes, entreprises) ;
• protection et chiffrement améliorés pour répondre aux exigences des entreprises.

Passons en revue chacune d'entre elles.

1) Vérification de l'état de la base de données

Outre les sauvegardes, Postgresus surveille désormais l'état de la base de données : il affiche le temps de fonctionnement et vous alerte si une base de données était indisponible.

La vérification de l'état peut être désactivée et configurée.

Si la base de données est indisponible — le système enverra une notification à ce sujet.

2) Nouvelles sources pour stocker les sauvegardes et envoyer des notifications

Initialement, Postgresus ne pouvait stocker les sauvegardes que localement et dans S3. Google Drive, CloudFlare R2, Azure Blob Storage et NAS ont été ajoutés. Les plans incluent l'ajout de FTP et éventuellement SFTP et NFS.

Pour les notifications, le projet avait initialement Telegram et e-mail (SMTP). Maintenant, Slack, Discord, MS Teams et les webhooks sont également pris en charge. De plus, les webhooks sont désormais configurés de manière flexible pour se connecter à différentes plateformes :

3) Gestion des espaces de travail et des utilisateurs

Auparavant, le système n'avait qu'un seul utilisateur (administrateur), et les bases de données étaient globales pour l'ensemble du système. Maintenant, Postgresus prend en charge la création d'espaces de travail pour séparer les bases de données et l'ajout d'utilisateurs aux espaces de travail. Avec séparation des rôles :

• lecture seule (peut consulter l'historique des sauvegardes, télécharger les fichiers de sauvegarde) ;
• édition (peut ajouter\supprimer\modifier des bases de données en plus de la lecture).

Par conséquent, vous pouvez maintenant séparer les bases de données :

• bases de données du client X ;
• bases de données de la startup Y ;
• bases de données de l'équipe Z ;

Les équipes DBA et les grandes entreprises d'externalisation ont commencé à utiliser Postgresus, ce qui en fait une fonctionnalité importante. Cela rend le projet utile non seulement pour les développeurs individuels, DevOps ou DBA, mais pour des équipes et des entreprises entières.

Les journaux d'audit sont également apparus :

Si quelqu'un décide de supprimer toutes les bases de données ou pour une raison quelconque télécharge toutes les sauvegardes de toutes les bases de données — cela sera visible 🙃

4) Chiffrement et protection

Dans la première version, honnêtement, je n'avais pas le temps pour la sécurité. Je stockais tous les fichiers de sauvegarde localement, personne n'y avait accès, et mes projets n'étaient pas exactement top secrets.

Mais quand Postgresus est devenu open source, j'ai rapidement appris que les équipes sauvegardent souvent des sauvegardes dans des buckets S3 partagés et ne veulent pas que d'autres les lisent. Les mots de passe des bases de données ne devraient pas non plus être stockés dans la propre base de données de Postgresus, car de nombreuses personnes ont accès à ses serveurs. ~~Et il y a une certaine méfiance les uns envers les autres.~~ Ne pas exposer simplement les secrets via l'API n'est plus suffisant.

Ainsi, le chiffrement et la sécurité de l'ensemble du projet sont devenus la priorité principale pour Postgresus. La protection fonctionne maintenant à trois niveaux, et il y a une page de documentation dédiée pour cela.

1) Chiffrement de tous les mots de passe et secrets

Tous les mots de passe de base de données, les tokens Slack et les identifiants S3 sont stockés chiffrés dans la base de données de Postgresus. Ils ne sont déchiffrés que lorsque c'est nécessaire. La clé secrète est stockée dans un fichier séparé de la base de données, donc même si quelqu'un piratait la base de données de Postgresus (qui n'est de toute façon pas exposée en externe) — ils ne pourraient toujours rien lire. Le chiffrement utilise AES-256-GCM.

2) Chiffrement des fichiers de sauvegarde

Les fichiers de sauvegarde sont maintenant également chiffrés (en option, mais le chiffrement est activé par défaut). Si vous avez perdu un fichier ou l'avez enregistré dans un S3 public — ce n'est plus si effrayant.

Le chiffrement utilise à la fois du sel et un vecteur d'initialisation unique. Cela empêche les attaquants de trouver des modèles pour deviner la clé de chiffrement, même s'ils volent tous vos fichiers de sauvegarde.

Le chiffrement est effectué en mode streaming, AES-256-GCM est également utilisé ici.

3) Utilisation d'un utilisateur en lecture seule pour les sauvegardes

Malgré les deux premiers points, il n'existe pas de méthode de protection à 100%. Il y a toujours une infime chance que :

• votre serveur soit complètement piraté, ils obtiennent la clé secrète et l'adresse IP légitime pour accéder à la base de données ;
• un pirate informatique déchiffre d'une manière ou d'une autre les mots de passe dans la base de données interne de Postgresus et découvre votre mot de passe de base de données ;
• ou, pire, ce ne sera pas un pirate informatique mais quelqu'un de l'intérieur ;
• et ils corrompront votre base de données, après avoir préalablement supprimé les sauvegardes.

Donc Postgresus devrait aider les utilisateurs à minimiser les dommages. La probabilité d'un tel piratage peut être proche de zéro, mais c'est une maigre consolation si vous êtes celui à qui cela arrive.

Maintenant, lorsque vous ajoutez un utilisateur de base de données avec des autorisations d'écriture à Postgresus, le système propose de créer automatiquement un utilisateur en lecture seule et d'exécuter des sauvegardes à travers lui. Les gens sont beaucoup plus susceptibles de créer un rôle en lecture seule lorsqu'il suffit d'un clic au lieu de le configurer manuellement dans la base de données.

Voici comment Postgresus propose :

Propose très persistamment :

Avec cette approche, même si votre serveur Postgresus est piraté, tout est déchiffré et les attaquants obtiennent l'accès à votre base de données — ils ne pourront au moins pas corrompre la base de données. Savoir que tout n'est pas perdu est une assez bonne consolation.

5) Compression par défaut, la plus optimale

La première version de Postgresus offrait tous les algorithmes de compression que PostgreSQL prend en charge : gzip, lz4 et zstd, avec des niveaux de compression de 1 à 9. Honnêtement, je ne comprenais pas vraiment pourquoi quelqu'un aurait besoin de toutes ces options. J'ai simplement choisi gzip avec le niveau 5 comme ce qui semblait être un juste milieu raisonnable.

Mais une fois que le projet est devenu open source, j'ai dû réellement faire des recherches à ce sujet. J'ai donc exécuté 21 sauvegardes dans toutes les combinaisons possibles et trouvé le meilleur compromis entre vitesse et taille.

Donc maintenant par défaut pour toutes les sauvegardes, zstd avec un niveau de compression 5 est défini, si la version de PostgreSQL est 16 et supérieure. Si inférieure — toujours gzip (au fait, merci encore aux contributeurs pour le support de PG 12). Voici zstd 5 comparé à gzip 5 (c'est en bas) :

En moyenne, les sauvegardes sont compressées ~8 fois par rapport à la taille réelle de la base de données.

6) Support Kubernetes Helm

Celui-ci est rapide — nous avons ajouté le support natif k8s avec l'installation Helm. Les équipes exécutant k8s dans le cloud peuvent maintenant déployer Postgresus plus facilement. Trois contributeurs ont aidé avec cette fonctionnalité.

7) Thème sombre

Je ne suis pas vraiment fan des thèmes sombres. Mais il y avait beaucoup de demandes, alors j'en ai ajouté un (~~merci Claude pour l'aide et l'œil de designer~~). Étonnamment, il s'est avéré meilleur que le thème clair et est devenu le thème par défaut. J'ai même redessiné le site web du clair au sombre — il était si beau.

Avant :

Après :

8) Se débarrasser des sauvegardes incrémentielles et PITR (Point In Time Recovery)

D'abord, un peu de contexte :

• Sauvegarde logique — c'est quand PostgreSQL lui-même exporte ses données (vers un fichier ou un groupe de fichiers).
• Sauvegarde physique — c'est quand nous nous connectons au disque dur de PostgreSQL et faisons une copie de ses fichiers.
• Sauvegarde incrémentielle avec support PITR — est une sauvegarde physique + journal des modifications (WAL), copié depuis le disque ou via le protocole de réplication.

Je croyais que Postgresus devrait éventuellement prendre en charge les sauvegardes incrémentielles. Après tout, c'est ce que font les outils sérieux ! Même ChatGPT dit que les outils sérieux peuvent récupérer avec précision jusqu'à la seconde et la transaction.

J'ai donc commencé à y travailler. Mais ensuite la réalité a frappé :

• C'est très difficile de le rendre pratique en termes d'UX et de DevEx. Parce que vous devez soit vous connecter physiquement au disque avec la base de données, soit configurer la réplication.

Pour la récupération — il n'y a pas d'option pour ne pas se connecter au disque avec la base de données. Pour récupérer à partir d'une sauvegarde incrémentielle, l'outil de sauvegarde restaure simplement le dossier pgdata (plus précisément, une partie de celui-ci).

Si la base de données est vraiment grande, par exemple, plusieurs To et plus — un réglage fin dans les configurations est nécessaire. Ici, l'interface utilisateur est plus un obstacle qu'une aide.

• La plupart des clouds (AWS, Google, Selectel) ne fonctionneront pas avec des sauvegardes incrémentielles externes, si elles nécessitent un accès au disque. En théorie, avec quelques contournements, via la réplication — ils le feront. Mais la récupération à partir d'une telle sauvegarde vers un cloud géré ne fonctionnera toujours pas de toute façon.
• Tous les clouds fournissent des sauvegardes incrémentielles prêtes à l'emploi. En général, c'est l'une des raisons pour lesquelles ils sont payants. Et même eux ne permettent généralement pas la récupération seconde par seconde ou à un moment spécifique de transaction. Et si vous n'êtes pas dans le cloud — encore plus improbable que votre projet soit suffisamment critique pour nécessiter une telle précision.

Par conséquent, si Postgresus fait une sauvegarde d'une base de données gérée — il suffit de le faire environ une fois par semaine. Juste au cas où d'urgence imprévue ou si le cloud ne permet pas de stocker les sauvegardes assez longtemps. Sinon, fiez-vous aux propres sauvegardes incrémentielles du cloud.

• Pour la plupart des projets, les sauvegardes incrémentielles ne sont pas vraiment nécessaires. Pour les petites bases de données, une granularité entre les sauvegardes d'une heure est suffisante, si nécessaire fréquemment. Pour les grandes — au moins une fois par jour. C'est suffisant pour 99% des projets pour retrouver des données perdues ou récupérer complètement. Ces besoins sont entièrement couverts par les sauvegardes logiques.

Mais si vous êtes une banque ou un développeur de base de données gérée, vous avez vraiment besoin de la meilleure configuration de sauvegarde pour vos dizaines et centaines de téraoctets de données. Ici, Postgresus ne surpassera jamais les sauvegardes physiques de WAL-G ou pgBackRest en termes de commodité de console et d'efficacité pour les bases de données avec un volume en To et plus. Mais, à mon avis, ce sont déjà des outils spécialisés pour de telles tâches, fabriqués par des génies et des mainteneurs de PostgreSQL lui-même.

À mon avis, les sauvegardes incrémentielles sont vraiment nécessaires dans deux cas :

• Dans le passé, quand il n'y avait pas un tel choix de bases de données gérées dans le cloud et que les grands projets nécessitaient d'héberger tout vous-même. Maintenant, les mêmes banques, places de marché et télécoms ont des clouds internes avec PITR prêt à l'emploi.
• Vous êtes un cloud géré. Mais ici la tâche est radicalement plus complexe que simplement faire des sauvegardes et les récupérer.

Compte tenu de tout cela, j'ai pris la décision délibérée d'abandonner le développement de sauvegardes incrémentielles. Au lieu de cela, je me concentre sur la réalisation de sauvegardes logiques aussi pratiques, fiables et pratiques pour une utilisation quotidienne par les développeurs, DevOps, DBA et entreprises.

9) De nombreuses petites améliorations

Les points ci-dessus sont loin d'être tout. 80% du travail n'est généralement pas visible. De mémoire, voici une courte liste :

• Optimisation de la mise en mémoire tampon et de la RAM. Postgresus n'essaie plus de mettre en mémoire tampon tout ce que pg_dump envoie en attendant que S3 rattrape (le téléchargement depuis la base de données est généralement plus rapide que le téléchargement vers le cloud). L'utilisation de la RAM est maintenant limitée à 32 Mo par sauvegarde parallèle.
• Diverses améliorations de stabilité et corrections de bugs mineurs.
• Ajout de SMTP sans nom d'utilisateur et sans mot de passe. Je ne savais même pas que cela arrivait…
• Ajout de sujets pour l'envoi de notifications aux groupes Telegram.
• La documentation est apparue !
• Support de PostgreSQL 12.

Et bien plus encore.

Qu'est-ce qui n'a pas fonctionné ?

Bien sûr, tout ne fonctionne pas et certaines choses doivent être abandonnées. Je construis Postgresus pendant mon temps libre, qui existe à peine. Je ne peux donc pas me disperser ou compliquer l'UX avec des fonctionnalités inutiles. Trop de fonctionnalités est également mauvais.

1) Surveillance complète des ressources de la base de données

Je voulais faire de Postgresus un outil de surveillance PostgreSQL également. Y compris les ressources système du serveur exécutant PostgreSQL :

• CPU
• RAM
• ROM
• Vitesse et charge IO

J'ai même créé la base pour collecter des métriques (n'importe lesquelles) et un modèle pour les graphiques :

Il s'avère que PostgreSQL n'expose que l'utilisation de la RAM et les métriques IO prêtes à l'emploi.

La surveillance d'autres ressources nécessite des extensions. Mais toutes les bases de données ne peuvent pas installer les extensions dont j'ai besoin, je ne pouvais donc collecter que des métriques partielles. Puis j'ai découvert que les bases de données cloud ne permettent souvent pas d'installer des extensions du tout.

Puis j'ai réalisé que les métriques devraient être stockées dans VictoriaMetrics ou au moins TimescaleDB, pas dans le propre PostgreSQL de Postgresus, ce qui compliquerait la construction de l'image.

Au final, cette fonctionnalité non essentielle ajouterait :

• une complexité de code significative, ce qui signifie une maintenance plus difficile ;
• plus d'exigences de construction d'image (composants supplémentaires) ;
• UX compliquée (comme je l'ai dit, trop de fonctionnalités est mauvais) ;
• ~~positionnement peu clair : sommes-nous un outil de sauvegarde, un outil de surveillance, ou essayons-nous de tout faire ?~~

J'ai donc abandonné la surveillance des ressources et me suis concentré sur faire de Postgresus le meilleur outil de sauvegarde possible.

2) Console SQL

Je voulais également ajouter une console SQL. Puisque Postgresus est déjà connecté à la base de données, pourquoi ne pas exécuter des requêtes directement à partir de celle-ci ? Ce serait pratique — pas besoin d'ouvrir PgAdmin, DataGrip ou DBeaver à chaque fois.

Je n'ai jamais trouvé le temps d'y travailler, seulement planifié. Un contributeur a commencé sur la fonctionnalité et a fait une PR. Mais comme prévu avec des fonctionnalités complexes, de nombreuses exigences et cas limites sont apparus :

• besoin d'ajouter le support de la syntaxe SQL ;
• ajouter l'autocomplétion et les conseils ;
• faire un chargement paresseux pour que même 100 Mo de lignes ne viennent pas au navigateur ;
• ajouter au moins plusieurs exportations vers CSV et XLSX.

C'est essentiellement un projet complet en soi, pas seulement un onglet.

Nous avons décidé d'abandonner la fonctionnalité et d'économiser l'effort. Cela s'est avéré être le bon choix, puisque nous avons ajouté des rôles en lecture seule qui ne permettent pas INSERT, UPDATE et DELETE de toute façon.

Conclusion

C'est le voyage que Postgresus a fait en six mois. Il est passé d'un projet de niche à un outil de niveau entreprise qui aide à la fois les développeurs individuels et des équipes DBA entières (j'ai été surpris d'apprendre cela seulement ~2 mois après la première version, d'ailleurs). Je suis sincèrement heureux que des milliers de projets et d'utilisateurs comptent sur Postgresus.

Le projet ne s'arrête pas là. Mon objectif maintenant est de faire de Postgresus l'outil de sauvegarde PostgreSQL le plus pratique au monde. Il y a un grand arriéré de fonctionnalités et d'améliorations qui arrivent progressivement.

Mes principales priorités restent :

• la sécurité du projet — c'est critique, sans elle tout le reste n'a pas de sens ;
• UX pratique en termes d'utilisation du projet lui-même et pas d'excès de fonctionnalités (nous faisons une tâche, mais très bien) ;
• UX pratique en termes de déploiement : pour que tout se déploie avec une seule commande et que rien n'ait besoin d'être configuré prêt à l'emploi ;
• ouverture du projet — complètement open source et gratuit pour toute personne ou entreprise.

Si vous aimez le projet ou le trouvez utile — j'apprécierais une étoile sur GitHub ou le partager avec des amis ❤️

\