#JaiDécouvert que wal-g ne se limite pas au support de PostgreSQL : il prend également en charge MySQL, MS SQL Server, et ajoutera bientôt le support de MongoDB et Redis.

WAL-G is an archival restoration tool for PostgreSQL, MySQL/MariaDB, and MS SQL Server (beta for MongoDB and Redis).

-- from

Avec la sortie de la version 17 de PostgreSQL, de nouvelles options de sauvegarde sont désormais disponibles : l'outil pg_basebackup permet de réaliser les sauvegardes incrémentales, et un nouvel utilitaire, pg_combinebackup, permet de reconstituer une sauvegarde complète à partir de sauvegardes incrémentales.

J'ai lu les articles suivants de Robert Haas, créateur de ces nouvelles fonctionnalités :

• Incremental Backup: What To Copy?
  • #JaiDécouvert le projet ptrack.
• Incremental Backups: Evergreen and Other Use Cases

J'en ai profité aussi pour lire :

• Is pg_dump a Backup Tool?
• Why pg_dump Is Amazing

J'ai trouvé tous ces articles très intéressants, j'y ai appris beaucoup de choses.

Je me demande quel impact ces fonctionnalités auront ou ont déjà sur les outils existants comme pgBackRest, barman, et wal-g.

Autres ressources :

• 25.3.3. Making an Incremental Backup

Impact sur pgBackRest ?

Voici ce que j'ai trouvé dans le projet pgBackRest.

We are aware of what's been committed to PG17.

-- from

Je comprends d'après ce commentaire que les auteurs de pgBackRest sont bien au courant des avancées de PostgreSQL 17.

Issue : WAL summarizer in pg 17 and incremental backups in pgbackrest ?.

We already support page-level (we call it block-level) incremental since v2.46 and it works for all versions of PostgreSQL supported by pgBackRest (>= 9.4), see https://pgbackrest.org/user-guide.html#backup/block.

We are planning to use the WAL summarizer to help us pick more optimal block sizes and cross-check timestamps but we are waiting for it to be a bit more stable. Also, the WAL summarizer output uses a lot of memory and is not the best fit for large databases with a lot of changes. We have some ideas on how to make that more efficient but have not had time to pursue it yet.

D'après ce commentaire, je pense avoir compris que les nouvelles fonctionnalités de backup incrémental de PostgreSQL 17 ne sont d'aucune utilité pour pgBackRest, qui implémente déjà cette fonctionnalité de manière efficace 🤔.

Impact sur barman ?

La version 3.11.0 de barman intègre des fonctionnalités liées aux nouvelles fonctionnalités de PostgreSQL 17.

Impact sur wal-g

J'ai n'ai trouvé aucune mention de pg_combinebackup, ni de pg_basebackup incremental dans le repository de wal-g.

J'ai l'impression qu'il est possible d'utiliser directement pg_basebackup pour effectuer des sauvegardes incrémentales de bases de données PostgreSQL. Cependant, je crains que cette idée soit un peu naïve.

Vers la fin de 2023, j'ai commencé à implémenter un POC de pgBackRest : https://github.com/stephane-klein/backlog/issues/322. J'ai pu réaliser une simulation complète de son utilisation dans ce dépôt : poc-pgbackrest. Cependant, je n'ai pas conservé un souvenir précis des raisons pour lesquelles mon expérience utilisateur n'a pas été satisfaisante, ce qui m'a dissuadé de déployer pgBackRest en production.

Après avoir constaté que barman intègre la fonctionnalité increment de pg_basebackup, j'ai envie de tester barman.

#JaiDécouvert restic-exporter : « Prometheus exporter for the Restic backup system ».

#JaiDécouvert l'option "append-only" mode de restic.

#JaiDécouvert rustic, un clone de restic implémenté en Rust (from).

Je pense avoir terminé le projet Projet 7 - "Améliorer et mettre à jour le projet restic-pg_dump-docker".

Merci à Alexandre pour ses commits de GitHub Actions CI/CD et du support multi architectures publié sur Docker Hub : # stephaneklein/restic-pg_dump.

Je suis assez satisfait du résultat. Le projet a été réalisé avec soin et j'ai tenté de le simplifier au maximum.
Il reste cependant une dernière possibilité de simplification à implémenter : Suggestion : Remplacer Supercronic par Cronie.

Bilan du temps passé sur le Projet 7 :

• 8 sessions de travail entre le 5 juin et le 6 juillet 2024 ;
• Pour un total de 10h16.

Nouvelle #iteration sur Projet 7 - "Améliorer et mettre à jour le projet restic-pg_dump-docker".

Alors que je travaille sur cette partie du projet, je relis la documentation de pg_dumpall et je constate à nouveau que cette commande ne supporte pas les différents formats de sortie que propose pg_dump 😡.
C'est pénible… du coup, j'ai enfin pris le temps de chercher si il existe une solution alternative et #JaiDécouvert pg_back :

pg_back is a dump tool for PostgreSQL. The goal is to dump all or some databases with globals at once in the format you want, because a simple call to pg_dumpall only dumps databases in the plain SQL format.

C'est parfait, c'est exactement ce que je cherche 👌.

Mais je découvre aussi les fonctionnalités suivantes :

• Pre-backup and post-backup hooks
• Purge based on age and number of dumps to keep
• Dump from a hot standby by pausing replication replay
• Encrypt and decrypt dumps and other files
• Upload and download dumps to S3, GCS, Azure or a remote host with SFTP

Conséquence : #JeMeDemande si j'ai encore besoin de restic dans Projet 7 🤔.

Je viens de lire ici :

In addition to the N previous backups, it would be nice to keep N' weekly backups and N'' monthly backups, to be able to look back into the far past.

C'est une fonctionnalité supporté par restic, donc pour le moment, je choisis de continuer à utiliser restic.

Pour le moment, #JaiDécidé d'intégrer simplement pg_back dans restic-pg_dump-docker en remplacement de pg_dumpall et de voir par la suite si je simplifie ce projet ou non.

#JeLis pour la première fois https://github.com/postgrespro/pg_probackup

J'ai en même temps découvert https://github.com/postgrespro/ptrack mais je n'ai pas pris le temps de bien comprendre son rôle.

Nouvelle #iteration sur Projet 7 - "Améliorer et mettre à jour le projet restic-pg_dump-docker".

Hasard du calendrier, mon ami Alexandre travaille en ce moment sur un projet nommé restic-ftp-docker.

Quelle différence avec restic-pg_dump-docker ?

Principale différence d'objectif entre ces deux projets :

• restic-ftp-docker sauvegarde via restic le contenu d'un dossier vers un espace FTP.
• restic-pg_dump-docker sauvegarde via restic le contenu d'une base de données PostgreSQL. Le contenu de la base de données est exporté avec la commande standard pg_dump de PostgreSQL. La sauvegarde peut être envoyée vers tous les storages supportés par rclone.

#JaiDécidé de reprendre un maximum d'élément du projet restic-ftp-docker dans restic-pg_dump-docker.

#JeSouhaite proposer une Pull Request à restic-ftp-docker pour étendre ce projet à tous les storages supporté par rclone et ne plus le limité au storage ftp.

Date de la création de cette note : 2024-06-05.

Ce projet est terminé : voir 2024-07-06_1116.

Quel est l'objectif de ce projet ?

Bien que j'aie beaucoup travaillé de décembre 2023 janvier 2024 sur le projet Implémenter un POC de pgBackRest, je souhaite mettre à jour et améliorer le repository restic-pg_dump-docker.

Quelques tâches à réaliser :

• [x] Mettre à jour tous les composants ;
• [x] Publier le Dockerfile de stephaneklein/restic-backup-docker ;
• [ ] Réaliser et publier un screencast ;
• [x] Améliorer le README.md.

Pourquoi je souhaite réaliser ce projet ?

Pourquoi continuer ce projet alors que j'ai travaillé sur pgBackRest qui semble bien mieux ?

Pour plusieurs raisons :

• Je ne peux pas installer pgBackRest dans un « sidecar container Docker » — en tout cas, je n'ai pas trouvé comment réaliser cela 🤷‍♂️. Je dois utiliser un container Docker PostgreSQL qui intègre pgBackRest.
• Pour le moment, je ne comprends pas très bien la taille consommée par les "WAL segments" sauvegardés dans les buckets.
• Pour le moment, je ne sais pas combien de temps prend la restauration d'un backup d'une base de données d'une taille supérieure à un test. Par exemple, combien de temps prend la restauration d'une base de données de 100 Mo 🤔.
• Je ne suis pas rassuré de devoir lancer un cron — supercronic — lancé par tini

Bien que pgBackRest permette un backup en temps "réel" et est sans doute plus rapide que "ma" méthode "restic-pg_dump", pour toutes les raisons listée ci-dessus, je pense que la méthode "restic-pg_dump" est moins complexe à mettre en place et à utiliser.

#JeMeDemande si la fonctionnalité "incremental backups" la version 17 de PostgreSQL sera une solution plus pratique que pgBackRest et la méthode "restic-pg_dump" 🤔.

Repository de ce projet :

https://github.com/stephane-klein/restic-pg_dump-docker

Je vais travailler dans la branche nommée june-2024-working-session

Site officiel : https://pgbackrest.org/

Voir aussi : barman, wal-g.

Dépôt GitHub : https://github.com/wal-g/wal-g

Voir aussi : barman, pgBackRest.

Site officiel : https://pgbarman.org/

Voir aussi : pgBackRest, wal-g.