pgBackRest n’est plus maintenu

 (github.com/pgbackrest)
3 points par GN⁺ 2 일 전 | 1 commentaires | Partager sur WhatsApp
  • Outil de sauvegarde et de restauration pour PostgreSQL, il a été conçu pour évoluer jusqu’aux environnements de grande échelle, mais sa maintenance est désormais arrêtée
  • Les bug fixes, la review des PR, le traitement des issues et le développement de nouvelles fonctionnalités sont tous stoppés, et le choix a été fait d’arrêter clairement plutôt que de faire durer le projet de façon irrégulière
  • Il prend en charge les sauvegardes full, differential et incremental, ainsi que le block-level backup, la reprise des tâches interrompues et le delta restore, afin de ne stocker et restaurer que les parties modifiées
  • Il dispose d’une protocol layer couvrant les environnements locaux et distants, ainsi que de multiple repositories, et étend son périmètre opérationnel via des connexions TLS·SSH et des object stores compatibles S3·Azure·GCS
  • C’était un outil largement doté de mécanismes de garantie d’intégrité comme les checksum, l’attente des WAL segment, fsync et la vérification des page checksum, mais à l’avenir, même si un fork apparaît, il devra construire sa propre crédibilité

Fin de maintenance et état du projet

  • pgBackRest est un outil de sauvegarde et de restauration pour PostgreSQL, mais il n’est désormais plus maintenu
  • Le travail sur le projet a été arrêté, et il est indiqué qu’à l’avenir, plus de temps ne sera consacré aux bug fixes, à la review des PR, au traitement des issues ni au développement de nouvelles fonctionnalités
  • Même après la fin du sponsoring et des formes d’emploi existantes, l’équipe a tenté de poursuivre la maintenance, mais n’a pas réussi à obtenir suffisamment d’opportunités professionnelles et de sponsoring pour continuer à faire vivre le projet
  • Il a été jugé préférable de mettre un terme clair au projet plutôt que de poursuivre une maintenance irrégulière ou incomplète
  • Quelqu’un pourra éventuellement faire un fork à l’avenir, mais dans ce cas il sera considéré comme un nouveau projet, et le nouveau mainteneur devra établir sa crédibilité séparément

Fonctionnalités clés du projet

  • Il vise la sauvegarde et la restauration extensibles jusqu’aux environnements PostgreSQL de grande échelle, et la version stable actuelle est v2.58.0
  • Il a été conçu pour réduire le coût de compression, souvent source de goulots d’étranglement lors des sauvegardes, en s’appuyant sur le traitement parallèle et sur des méthodes de compression comme lz4 et zstd
  • Il prend en charge les sauvegardes full, differential et incremental, et permet, non seulement au niveau des fichiers mais aussi via le block-level backup, de ne copier que les parties modifiées afin d’économiser l’espace de stockage
  • Il peut reprendre une sauvegarde interrompue et revérifie l’intégrité des fichiers déjà copiés en les comparant aux checksum du manifest
  • Avec le delta restore, les fichiers absents de la sauvegarde sont d’abord supprimés, puis les checksum des fichiers restants sont comparés ; les fichiers identiques sont laissés en place et seuls les fichiers nécessaires sont restaurés

Exploitation à distance et architecture du stockage

  • Grâce à sa propre protocol layer, il peut effectuer des opérations de sauvegarde, de restauration et d’archivage aussi bien en local qu’à distance, en utilisant TLS/SSH pour les connexions distantes
  • Cette même protocol layer fournit aussi une interface de requête PostgreSQL, ce qui permet d’effectuer des opérations sans se connecter directement à PostgreSQL à distance et améliore ainsi la sécurité
  • Il prend en charge les multiple repositories, ce qui permet de combiner un dépôt local pour les restaurations rapides et un dépôt distant pour la conservation longue durée et la redondance
  • Les dépôts peuvent aussi être placés sur des object stores compatibles S3, Azure et GCS, ce qui permet d’augmenter fortement la capacité et la durée de conservation
  • Le dépôt lui-même peut être chiffré, ce qui permet de protéger les données de sauvegarde quel que soit l’endroit où elles sont stockées

Mécanismes de garantie d’intégrité et de cohérence

  • Un checksum est calculé pour tous les fichiers de la sauvegarde, puis revérifié lors d’une restauration ou d’une vérification
  • Une fois la copie des fichiers terminée, l’outil attend que tous les WAL segment nécessaires soient arrivés dans le dépôt afin de garantir un état cohérent de la sauvegarde
  • Toutes les opérations utilisent fsync au niveau des fichiers et des répertoires afin d’assurer la durabilité
  • Si le page checksum est activé dans PostgreSQL, tous les checksums de page sont vérifiés pour les sauvegardes full, et seuls les fichiers modifiés sont vérifiés pour les sauvegardes differential et incremental
  • Même si une vérification de checksum de page échoue, la sauvegarde n’est pas interrompue ; un avertissement indique quelles pages ont échoué, afin de détecter tôt une page-level corruption avant l’expiration d’une sauvegarde valide

Traitement des WAL et optimisation des performances de restauration

  • Il fournit des commandes dédiées WAL push/get, toutes deux conçues pour prendre en charge le traitement parallèle et l’exécution asynchrone afin de minimiser autant que possible l’impact sur le temps de réponse de PostgreSQL
  • WAL push déduplique automatiquement un même WAL segment s’il arrive plusieurs fois, et déclenche une erreur si son contenu diffère
  • Le WAL push asynchrone confie le transfert à un autre processus, qui compresse les WAL segment en parallèle, ce qui est particulièrement important pour les bases de données à très fort volume d’écriture
  • Le WAL get asynchrone maintient localement une WAL queue décompressée pour pouvoir l’alimenter immédiatement avant le replay, avec un avantage particulièrement marqué sur les connexions à forte latence ou les stockages comme S3
  • WAL push et get comparent tous deux la version de PostgreSQL et le system identifier afin de vérifier que la base de données et le dépôt correspondent, ce qui réduit fortement le risque de mauvaise configuration de l’emplacement d’archivage WAL

Flexibilité opérationnelle et compatibilité

  • Les politiques de backup retention et d’archive expiration peuvent être configurées séparément au niveau full, differential et WAL, ce qui permet de couvrir la plage de conservation souhaitée
  • Les sauvegardes peuvent être stockées au format natif du cluster PostgreSQL, et si la compression est désactivée et les hard links activés, il est même possible de démarrer directement le cluster PostgreSQL depuis un snapshot du dépôt
  • Cette approche est avantageuse pour les terabyte-scale databases, où une restauration traditionnelle peut prendre beaucoup de temps
  • Les tablespaces sont entièrement pris en charge, et lors de la restauration, chaque tablespace peut être déplacé vers un autre emplacement ou remappé en bloc vers un emplacement unique
  • Les liens de fichiers et de répertoires sont également pris en charge, avec la possibilité lors de la restauration de conserver leur emplacement d’origine, de remapper une partie ou la totalité, ou encore de les restaurer sous forme de fichiers et répertoires ordinaires
  • Il prend en charge 10 versions de PostgreSQL, incluant les 5 versions actuellement supportées et les 5 versions récemment passées en EOL, afin de laisser une marge confortable pour les mises à niveau

Ressources de référence et état du sponsoring

À lire aussi

1 commentaires

 
GN⁺ 2 일 전
Commentaires sur Hacker News
  • D’après le message publié par l’auteur sur LinkedIn, il a vraiment consacré énormément de temps et d’attachement à pgBackRest pendant 13 ans, et a désormais décidé d’arrêter la maintenance
    Il bénéficiait d’un soutien de son entreprise, mais y consacrait aussi ses soirées et ses week-ends ; après la vente de Crunchy Data, il a continué à maintenir le projet tout en cherchant un poste qui lui permettrait de poursuivre ce travail, sans succès
    Il doit désormais viser des opportunités plus larges pour gagner sa vie, et ne peut donc plus dégager le temps nécessaire pour la maintenance, les corrections de bugs, la revue des PR et la gestion des issues ; il va donc archiver le dépôt
  • J’utilise pgBackRest dans un projet personnel, au point d’avoir rédigé un guide de sauvegarde PostgreSQL pour volumes locaux et stockage cloud, donc c’est triste de voir cela se terminer ainsi
    Le guide est ici : https://github.com/freakynit/postgre-backup-and-restore-guide, et un immense merci pour tout le temps et les efforts investis jusqu’ici
    • J’ai aussi l’impression qu’avec les attentes autour de l’IA, les développeurs subissent des délais plus serrés et disposent de moins de temps
      En plus, beaucoup ont brûlé de l’argent dans les tokens, ce qui a aussi réduit leur marge financière et leur temps disponible
    • J’aimerais vraiment qu’on évite de voir ce type de projet disparaître faute de financement, tant les difficultés concrètes de l’OSS sont énormes
  • Ici, ce n’est pas vraiment le modèle open source lui-même qui a échoué ; c’est surtout que l’auteur n’arrive plus à trouver de soutien financier et change donc de cap, ce qui est tout à fait légitime
    Si cet outil était au-delà du simple projet hobby, au point d’être un produit de qualité utilisé en environnement commercial et créant une vraie valeur, alors il y a clairement une opportunité pour une entreprise de venir combler ce vide
    Mais les utilisateurs doivent devenir des clients et payer réellement ; ce n’est pas soutenable de continuer à envoyer rapports de bugs et plaintes à un mainteneur gratuit
    Il faut de nouvelles solutions pour la pérennité financière du FOSS, car les dons seuls ne semblent pas suffire
    • J’ai appris que, dans n’importe quel écosystème, si je veux qu’une chose survive, je dois la soutenir directement
      Que ce soit un commerce de quartier ou un projet open source, c’est la même logique
    • Je me demande si l’auteur a envisagé de transformer cela en produit payant
      Mais selon les contributeurs, il peut y avoir des questions de droits d’auteur, donc selon l’existence d’un ACL et la juridiction, il faudrait peut-être clarifier les droits et se mettre d’accord sur une répartition des revenus
  • À mon avis, ce à quoi les gens devraient davantage prêter attention, c’est le rachat de Crunchy Data
    Tant qu’il y avait un soutien d’entreprise, tout tournait ; mais une fois l’entreprise vendue et les priorités du nouveau propriétaire modifiées, cet outil d’infrastructure à 3,8k stars est immédiatement devenu fragile, sans que les utilisateurs réalisent que le financement de leur outil de sauvegarde dépendait de la stratégie M&A de quelqu’un d’autre
    Du coup, je migre peu à peu vers des fichiers suivis avec SQLite et git
    Même les stacks Postgres managés reposent finalement sur une série d’outils maintenus par des gens dont on ne connaît pas la situation financière
    • Cela n’a pas complètement disparu, et au moins pour l’instant, les sauvegardes ne vont pas s’arrêter du jour au lendemain
      Mais l’idée générale d’une structure de financement fragile reste tout à fait juste
    • Cela dit, SQLite n’est pas totalement à l’abri du même risque non plus ; je me demande donc pourquoi ce serait considéré comme plus sûr
  • Le code source est toujours là, donc au lieu d’être seulement triste, on peut aussi forker soi-même le projet pour le maintenir, ou payer quelqu’un pour s’en charger
    Et tant qu’à faire, c’est peut-être le bon moment pour passer en revue les dépendances qu’on ne veut pas perdre et mettre en place un soutien financier dès maintenant
    • Je pense que c’est la bonne attitude
      Tout le monde dit que c’est triste, mais si c’est vraiment triste, il faut d’abord se demander si c’est assez triste pour donner de l’argent
  • D’après ce que j’ai vu de l’écosystème, pgBackRest était la meilleure solution dans le domaine des sauvegardes PostgreSQL
    Le fait qu’il prenne au sérieux non seulement la sauvegarde, mais aussi la restauration et la vérification, était particulièrement rare, et j’ai déjà payé très cher au travail le fait d’avoir négligé cet aspect
    Il y a plus de détails ici : https://blog.dijit.sh/that-time-my-manager-spend-1m-on-a-backup-server/
    Donc cela ressemble à une perte assez importante
  • C’est assez surprenant, et je considérais pratiquement cela comme l’outil de référence pour la sauvegarde/restauration PG
    Je me demande comment il se compare à WAL-G ou Barman
    https://github.com/wal-g/wal-g
    https://github.com/EnterpriseDB/barman
    • Je ne peux pas faire une comparaison précise, mais nous utilisons Barman depuis longtemps et nous en sommes très satisfaits
      Chaque nuit, nous créons avec Barman une base restaurée servant aussi à la formation et aux tests utilisateurs, ce qui nous permet de vérifier en continu si les sauvegardes sont réellement corrompues ; cela fonctionne sans problème depuis des années
    • Je suis l’un des mainteneurs de wal-g, et je pense qu’en termes de fonctionnalités c’est tout à fait comparable
      Après quelques années d’inactivité, je suis revenu sur le sujet du managed Postgres, et j’aimerais que wal-g prenne en charge, en plus de sa sauvegarde différentielle fondée sur sa propre comparaison de blocs, aussi la sauvegarde incrémentale de pg17
      Et il vaut vraiment mieux utiliser le mode daemon
      C’est dommage de voir disparaître un outil concurrent, mais il y a encore beaucoup de marge d’amélioration dans ce domaine, et quand Postgres veut tourner sur un système sans overcommit, le C a aussi des avantages sur Golang
    • Nous utilisions autrefois WAL-E, et maintenant son successeur WAL-G, avec satisfaction
      Quand nous l’avions évalué il y a environ 9 ans, nous le trouvions plus attractif que pgBackRest à cause de ses caractéristiques de streaming PITR
    • Je comprends qu’on l’ait vu comme l’outil de référence, mais cela rappelle aussi une situation du genre https://xkcd.com/2347/
  • J’utilise pgBackRest avec satisfaction sur une base de production de 2 To, et justement cette semaine j’allais le déployer aussi sur une base de 8 To
    Du coup, je me demande si l’alternative la plus proche est désormais wal-g, barman ou databasus
    Je disais en plaisantant que je faisais juste semblant d’être DBA, mais en réalité le choix est assez important
    • J’ai utilisé Barman sur des bases de plus de 30 To sans avoir grand-chose à lui reprocher
      Pour référence, je suis DBRE
    • Si vous sauvegardez un Postgres de production de plusieurs téraoctets, ce n’est pas juste faire semblant d’être DBA ; vous faites déjà vraiment le travail
    • Si votre configuration met les sauvegardes dans du stockage cloud, alors Barman avec des hook scripts est probablement l’alternative la plus proche
      La documentation associée est ici : 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 semble aussi intéressant, même si je ne l’ai pas encore validé moi-même
    • Je me demande aussi si quelqu’un a déjà fait des sauvegardes avec un standby sur ZFS ou sur un autre système de fichiers capable de snapshots
    • Je n’avais même jamais utilisé pgBackRest, et j’ai justement commencé à l’intégrer à un projet il y a 2 heures ; quand j’ai fini de lire le README, la mise à jour était déjà tombée
  • pgBackRest fait partie des technologies de sauvegarde PostgreSQL les plus polyvalentes, et d’après mon expérience, les autres produits n’arrivent pas à ce niveau
    C’est ce qui rend la situation encore plus regrettable, et atteindre une équivalence fonctionnelle avec cet excellent outil ne sera probablement pas simple
    Si possible, j’espère que cette décision pourra encore être annulée ; sinon, j’aimerais aussi voir le projet PostgreSQL l’absorber dans contrib
  • Pour l’instant, on peut toujours continuer à l’utiliser, donc il n’y a pas de raison d’arrêter immédiatement
    L’auteur préférerait probablement que les gens continuent à s’en servir jusqu’à ce que cela ne fonctionne vraiment plus, plutôt que de l’abandonner tout de suite
    • Et d’ici là, ce serait bien que quelqu’un se propose comme nouveau mainteneur
      Je ne sais pas s’il faudrait un fork, ou s’il serait possible de reprendre le flambeau directement sur le dépôt existant en devenant contributeur