PostgreSQL : Comparatif entre Barman et pgBackRest

Il existe plusieurs types de sauvegardes sur PostgreSQL :

• Logique :
  • Export (pg_dump, pg_dumpall)
• Physique :
  • A froid : (copie de tous les dossiers, instance éteinte)
  • A chaud : (copie de tous les dossiers et des wals, instance ouverte)

Vocabulaire :
	RPO (Recovery Point Objective) : Perte de Données Maximale Admissible
	RTO (Recovery Time Objective) : Durée Maximale d’Interruption Admissible

Avec un RPO faible, la perte de données admissible est très faible, voire nulle. Il faudra alors utiliser une solution de type sauvegarde à chaud, PITR, réplication (synchrone ou asynchrone).
Avec un RTO faible, la durée d’interruption de service doit être faible. Pour cela il faut une procédure avec le moins d’actions et le moins d’acteurs possible. Il faudra utiliser la réplication et les solutions de haute disponibilité. Ou dans le cas de perte de données, utiliser une solution de PITR.
Récemment j’ai dû faire un comparatif de deux outils de sauvegardes PostgresQL, qui sont Barman et pgBackRest. Ces deux outils que nous étudierons permettent de faire des sauvegardes physiques à chaud et du Point In Time Recovery (PITR, Restauration à un point précis dans le temps).

Présentation des outils :

Barman (version 2.09) :

Barman (Backup And Restore MANager) est un outil développé en Python, compatible uniquement avec les environnements Linux/Unix. Il est principalement maintenu par la société 2ndQuadrant Italia.

pgBackRest (version 2.19) :

pgBackRest est un outil de gestion de sauvegardes PITR écrit en perl, par David Steele de Crunchy Data. Il est maintenu par Crunchy Data, une migration en C est en cours.

Comparatif fonctionnel :

GÉNÉRALITÉS	BARMAN	PGBACKREST
GitHub	https://github.com/2ndquadrant-it/barman	https://github.com/pgbackrest/pgbackrest
Fait par	2ndquadrant	Crunchy Data
Langage	Python	C / Perl (Migration en C)
Installation	yum / apt-get / apt install	yum / apt-get / apt install
Prérequis	Python >= 3.4 + modules perl + librairies rsync >= 3.0.4 (optionnel pour PostgreSQL >= 9.2)	rsync

FONCTIONNALITÉS	BARMAN	PGBACKREST
Architectures possible	client/serveur et mode local	client/serveur et mode local
Catalogue centralisé	Oui	Oui
Multithreadé	Oui	Oui
Permet de lancer des scripts automatiquement	Oui	Non
Configuration	Configuration centralisée	Configuration répartie sur tous les serveurs
Gestion et Administration	Gestion et administration centralisées (sur le serveur barman)	Commandes d’utilisation réparties : backup depuis le serveur, restauration depuis le client
Gestion du stockage Cloud	Oui (Amazon S3 Compatible Object Storage)	Oui (Amazon S3 Compatible Object Storage)
Chiffrement des sauvegardes	Non	Oui (chiffrage/déchiffrage par le serveur Postgres)

SAUVEGARDE	BARMAN	PGBACKREST
Sauvegarde Full	Oui	Oui
Sauvegarde Différentielle	Non	Oui
Sauvegarde Incrémentale	Oui (rsync + hardlink)	Oui (checksum)
Gestion de la rétention	count et/ou nombre de jours (fenêtre de restauration)	count (au niveau full, différentielle et WALs). Permet de réduire la rétention des WALs. (Exemple : fenêtre de PITR de 7 jours et on garde les full des 4 dernières semaines)
Compression des backups	Non	Oui, choix du niveau de compression
Compression réseau1	Oui	Oui, si les backups ne sont pas compressés
Supporte les backups concurrents	Oui	Oui
Interruption d’une sauvegarde	Oui	Oui
Reprise d’une sauvegarde en échec	Non	Oui
Gestion des clusters	Non, sauvegarde à faire sur les deux nœuds ou choix du nœud à sauvegarder à changer manuellement	Oui, sauvegarde le nœud master (par défaut) ou le nœud standby. Détection du rôle des nœuds automatique (utile dans le cas de HA)
Liste des sauvegardes	Oui	Oui
Détails des sauvegardes	Oui	Oui

1 La compression réseau consiste à compresser les fichiers pour réduire la bande passante utilisée pour le transfert réseau. Les fichiers sont décompressés à la fin du transfert. (i.e. pas de gain de volumétrie sur le stockage).

WALs	BARMAN	PGBACKREST
Archivage des WALS	Par streaming et/ou par l’archive_comand	L’archive_command est modifiée pour utiliser la commande “pgbackrest archive-push”. L’envoi peut être synchrone ou asynchrone. Dans ce second cas, les WALs sont copiés sur un autre FS (local ou NFS). Un autre processus pgbackrest les envoie ensuite sur le serveur de sauvegarde. Ce mode permet aussi une restauration plus rapide.
Compression des WALs	Oui	Oui
Purge des WALs	Fait lors de la purge des anciens backups	Fait par « pgbackrest expire » ou en auto lors d’un backup. Les wals liés à une sauvegarde ne peuvent pas être supprimés.
Récupération des WALs pour la recovery (restore ou standby)	barman get-wal	pgbackrest archive-get

RESTAURATION	BARMAN	PGBACKREST
Restauration inplace	Oui	Oui
Restauration sur serveur autre ou à une autre destination	Oui	Oui
Restauration PITR	Oui	Oui
Choix du backup sur lequel la restauration doit s’appuyer	Oui	Non, par défaut prend le dernier backup
Choix des bases à restaurer	Non	Oui

Synthèse générale :

Les deux outils comparés lors de ces tests ont chacun leurs avantages et leurs inconvénients.

Barman

Les avantages :

• Streaming des wals
• Faible charge (CPU et RAM)
• Rétention en nombre de jours
• Stockage des backups vers Amazon S3 Compatible Object Storage
• Choisit le bon backup sur lequel s’appuyer pour restaurer

Les limites :

• Pas de compression des sauvegardes
• Pas de sauvegarde différentielle
• Pas de gestion des clusters de haute disponibilité
• Restauration plus lente
• Pas de reprise de sauvegarde en échec
• Restauration de l’instance uniquement

pgBackRest

Les avantages :

• Compression des sauvegardes
• Sauvegardes Full / Différentielle / Incrémentale
• Gestion différenciée de la rétention (Full / Différentielle / Wals)
• Restauration plus rapide
• Gestion des clusters de haute disponibilité
• Choix des bases à restaurer
• Stockage des backups vers Amazon S3 Compatible Object Storage
• Chiffrement des sauvegardes (utile notamment pour les sauvegardes vers le cloud)

Les limites :

• Charge CPU plus élevée (compression, chiffrement)
• Pas de streaming des wals
• Ne sait pas choisir le bon backup sur lequel s’appuyer pour restaurer (prend le dernier par défaut)

Conclusion :

Le choix d’un outil dépend du contexte dans lequel il sera utilisé. En fonction de ce dernier, il faudra privilégier certaines fonctionnalités, ce qui orientera la décision. Chaque contexte étant différent, j’espère que ce comparatif permettra de vous aider dans le choix de votre outil de sauvegarde de vos instances Postgres.
Il peut être intéressant de réaliser des tests en conditions proches du réel. Et surtout, pensez à tester vos sauvegardes et procédures régulièrement.

Sources :

https://www.pgbarman.org
https://www.pgbackrest.org
Dalibo

Continuez votre lecture sur le blog :

• PostgreSQL 17 : des sauvegardes incrémentales avec pg_basebackup (Emmanuel RAMI) [Non classéPostgreSQL]
• PGO : la suite (Sarah FAVEERE) [PostgreSQL]
• SQL Server 2022 Backup / Restore via un bucket S3 sous AWS (Louis PROU) [AWSSQL Server]
• PGO : opérateurs kubernetes pour PostgreSQL, la suite ! (David Baffaleuf) [ContainerDevopsPostgreSQL]
• Sauvegardes SQL Server dans un Azure Blob Storage (Vincent Delabre) [AzureSQL Server]