2

PostgreSQL : Comparatif entre Barman et pgBackRest

twitterlinkedinmail

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 :

twitterlinkedinmail

Rémi VIDIER

2 commentaires

  1. Bonjour
    J’utilise pgbackrest par contre j’ai un problème pour restaurer un backup expiré ? Qui a était copié avant qu’il soit supprimé.
    En d’autres termes comment faire un peu comme catalog start with ?
    D’avance merci
    Cordialement

  2. Bonjour Mahdi,
    Pour restaurer une sauvegarde expirée, et donc plus dans le référentiel pgbackrest, il faut faire une restauration manuelle.
    Les grandes étapes sont :
    – copier la sauvegarde dans le dossier de destination
    – décompresser les fichiers (si la sauvegarde est compressée)
    – configurer le fichier recovery.conf (ou postgresql.conf) en fonction de la version de postgres
    – démarrer l’instance
    /!\ Attention, pour pouvoir restaurer une sauvegarde physique (barman, pgbackrest ou autre), il faut a MINIMA avoir les WAL généré pendant la sauvegarde. Sinon cette sauvegarde ne sera pas consistante.
    Bonne journée

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.