L'état actuel de la gestion des sauvegardes open source pour PostgreSQL

Il existe de nombreuses façons d'aborder la prise de sauvegardes d'un cluster PostgreSQL. Il existe plusieurs articles et blogs qui présentent les différentes technologies par lesquelles nous pouvons enregistrer nos précieuses données dans PostgreSQL. Il existe des solutions de sauvegarde logique, une sauvegarde physique au niveau du système d'exploitation, au niveau du système de fichiers, etc. Ici, dans ce blog, nous n'allons pas couvrir la partie théorique qui est couverte de manière adéquate par divers blogs et articles ainsi que par la documentation officielle.

Ce blog se concentre sur l'état des différents outils et solutions disponibles et s'efforce de présenter une comparaison approfondie basée sur des expériences réelles. Cet article ne cherche en aucun cas à promouvoir un produit en particulier, j'aime beaucoup tous les outils, solutions et technologies décrits dans ce blog. L'objectif est ici de noter leurs forces, leurs faiblesses et de guider l'utilisateur final vers l'outil le plus adapté à son environnement, son infrastructure et ses besoins spécifiques. Voici un bel article décrivant les outils de sauvegarde pour PostgreSQL à différents niveaux.

Je ne décrirai pas comment utiliser les différents outils de ce blog, car ces informations sont documentées dans le blog ci-dessus et également dans la documentation officielle ainsi que dans d'autres ressources sur le net. Mais je décrirai les avantages et les inconvénients tels que je les ai vécus dans la pratique. Dans ce blog, nous traitons exclusivement des sauvegardes physiques PostgreSQL classiques basées sur PITR et dépendantes de :

• pg_basebackup ou pg_start_backup()/pg_stop_backup
• copie physique
• archivage des WAL ou réplication en continu

Il existe plusieurs produits et solutions de qualité, certains sont open source et gratuits tandis que d'autres sont commerciaux. A ma connaissance, ce sont :

• pgbarman par 2ndquadrant (gratuit)
• pgbackrest (gratuit)
• pg_probackup par Postgres Professional (gratuit)
• BART par EDB (commercial)

Je n'ai pas eu la chance d'essayer BART car il fonctionne sur des versions de Linux que je n'utilise pas. Dans ce blog, j'inclurai mes propres pensées et impressions tout en interagissant avec les auteurs/communautés/mainteneurs respectifs de chaque solution car il s'agit d'un aspect très important qui est généralement sous-estimé au début. Un peu de terminologie afin de mieux comprendre les différents termes de chacun des outils :

pgbarman

Pgbarman ou simplement barman est le plus ancien de ces outils. La dernière version est la 2.6 (publiée alors que j'avais ce blog en préparation ! Ce qui est une excellente nouvelle).

Pgbarman prend en charge la sauvegarde de base via deux méthodes :

• pg_basebackup (backup_method=postgres)
• rsync (backup_method=rsync)

et transfert WAL via :

• Archivage WAL
  • via rsync
  • via barman-wal-archive / put-wal
• WAL via la réplication en continu avec le slot de réplication
  • Asynchrone
  • Synchrone

Cela nous donne 8 combinaisons prêtes à l'emploi grâce auxquelles nous pouvons utiliser barman. Chacun a ses avantages et ses inconvénients.

Sauvegarde de base via pg_basebackup (backup_method =postgres)

Avantages :

• la méthode la plus récente/moderne
• s'appuie sur la technologie de base PostgreSQL éprouvée
• recommandé par la documentation officielle

Inconvénients :

• pas de sauvegarde incrémentielle
• pas de sauvegarde parallèle
• pas de compression réseau
• pas de déduplication des données
• aucune limite de bande passante réseau

Sauvegarde de base via rsync (backup_method =rsync)

Avantages :

• ancien et éprouvé
• Sauvegarde incrémentielle
• déduplication des données
• compression réseau
• sauvegarde parallèle
• limite de bande passante réseau

Inconvénients :

• pas la méthode recommandée (par les auteurs)

Transfert WAL via archivage WAL (via rsync)

Avantages :

• plus simple à configurer

Inconvénients :

• Aucun RPO=0 (zéro perte de données)
• aucun moyen de récupérer après des pannes de réseau longues et persistantes

Transfert WAL via archivage WAL (via barman-wal-archive / put-wal)

Avantages :

• la méthode la plus récente et recommandée (introduite dans la version 2.6)
• plus fiable/sûr que rsync

Inconvénients :

• Aucun RPO=0 (zéro perte de données)
• toujours aucun moyen de récupérer après des pannes de réseau longues et persistantes

Transfert WAL via WAL streaming avec slot de réplication (via pg_receivewal)

Avantages :

• plus moderne (et recommandé)
• RPO=0 (zéro perte de données) en mode synchrone

Inconvénients :

• toujours associé à l'emplacement de réplication. Peut augmenter en cas de panne du réseau

Ainsi, alors que pg_basebackup (méthode postgres) semble être l'avenir de pgbarman, en réalité, toutes les fonctionnalités sophistiquées sont fournies avec la méthode rsync. Alors énumérons toutes les fonctionnalités de Barman plus en détail :

• Opération à distance (sauvegardes/restaurations)
• Sauvegardes incrémentielles. L'une des grandes fonctionnalités de barman, les sauvegardes incrémentielles sont basées sur la comparaison au niveau des fichiers des fichiers de la base de données avec ceux de la dernière sauvegarde du catalogue. Dans barman, le terme "différentiel" fait référence à un concept différent :selon la terminologie barman, une sauvegarde différentielle est la dernière sauvegarde + les modifications individuelles depuis la dernière sauvegarde. Les documents de Barman indiquent qu'ils fournissent des sauvegardes différentielles via des WAL. Les sauvegardes incrémentielles de Barman fonctionnent au niveau du fichier, ce qui signifie que si un fichier est modifié, le fichier entier est transféré. C'est comme pgbackrest et contrairement à d'autres offres comme pg_probackup ou BART qui prennent en charge les sauvegardes différentielles/incrémentielles au niveau des blocs. Les sauvegardes incrémentielles Barman sont spécifiées via :reuse_backup =lien ou copie. En définissant la « copie », nous obtenons une réduction du temps de sauvegarde puisque seuls les fichiers modifiés sont transférés et sauvegardés, mais toujours pas de réduction d'espace puisque les fichiers inchangés sont copiés à partir de la sauvegarde précédente. En définissant « lien », les fichiers inchangés sont liés en dur (non copiés) à partir de la dernière sauvegarde. De cette façon, nous réalisons à la fois une réduction de temps et une réduction d'espace. Je ne veux en aucun cas apporter plus de confusion à ce sujet, mais en réalité, les sauvegardes incrémentielles de barman sont directement comparables aux sauvegardes incrémentielles de pgbackrest, puisque barman traite (via un lien ou une copie) une sauvegarde incrémentielle efficacement comme une sauvegarde complète. Ainsi, dans les deux systèmes, une sauvegarde incrémentielle traite des fichiers qui ont été modifiés depuis la dernière sauvegarde. Cependant, en ce qui concerne les sauvegardes différentielles, cela signifie une chose différente dans chacun des systèmes susmentionnés, comme nous le verrons ci-dessous.
• Sauvegarde depuis le mode veille. Barman offre la possibilité d'effectuer la majeure partie des opérations de sauvegarde de base à partir d'une veille, libérant ainsi le primaire de la charge d'E/S ajoutée. Cependant, notez que les WAL doivent toujours provenir du primaire. Peu importe que vous utilisiez archive_command ou le streaming WAL via des slots de réplication, vous ne pouvez pas encore (au moment d'écrire ces lignes avec barman étant sur la version 2.6) décharger cette tâche en veille.
• tâches parallèles pour la sauvegarde et la restauration
• Un ensemble riche et complet de paramètres de conservation basés sur :
  • Redondance (nombre de sauvegardes à conserver)
  • Fenêtre de récupération (combien de temps dans le passé les sauvegardes doivent-elles être conservées)
  À mon avis, du point de vue de l'utilisateur, ce qui précède est excellent. L'utilisateur peut définir reuse_backup =link et une fenêtre de récupération et laisser barman (son travail cron) s'occuper du reste. Pas de sauvegardes diff/incr/full, etc. à s'inquiéter, à planifier ou à gérer. Le système (barman) fait ce qu'il faut de manière transparente.
• Programmer vos propres scripts de hook pré/post événement.
• Remappage des tablespaces

Ce sont les meilleurs atouts du barman. Et vraiment, c'est presque plus que ce que le DBA moyen demanderait à un outil de sauvegarde et de récupération. Cependant, certains points pourraient être améliorés :

• La liste de diffusion n'est pas très active et les responsables écrivent ou répondent rarement aux questions
• Aucune fonctionnalité pour reprendre une sauvegarde ayant échoué/interrompue
• Les slots de réplication ou l'utilisation de rsync/barman-wal-archive pour l'archivage ne pardonnent pas en cas de défaillance du réseau ou d'autres défaillances du site de sauvegarde. Dans les deux cas, si la panne de réseau est suffisamment longue et que les modifications apportées à la base de données valent beaucoup de fichiers WAL, le primaire souffrira de "pas d'espace disponible sur l'appareil" et finira par planter. (pas une bonne chose). Ce qui est prometteur ici, c'est que barman fournit désormais un moyen alternatif (à rsync) de transférer des WAL afin qu'une protection supplémentaire contre, par exemple, L'épuisement de l'espace pg_wal pourrait être implémenté à l'avenir, ce qui, avec la reprise de sauvegarde, rendrait vraiment le barman parfait, du moins pour moi.

pgdossier

Pgbackrest est la tendance actuelle parmi les outils de sauvegarde open source, principalement en raison de son efficacité à faire face à de très gros volumes de données et du soin extrême que ses créateurs ont mis dans la validation des sauvegardes via des sommes de contrôle. Au moment d'écrire ces lignes, c'est sur la version v2.09, et les docs se trouvent ici. Le guide de l'utilisateur est peut-être légèrement obsolète, mais le reste de la documentation est très à jour et précis. Pgbackrest s'appuie sur l'archivage WAL en utilisant sa propre archive_command et son propre mécanisme de transfert de fichiers qui est meilleur et plus sûr que rsync. Donc, pgbackrest est assez avancé car il ne donne pas le plus grand nombre de choix que propose barman. Puisqu'il n'y a pas de mode synchrone impliqué, naturellement pgbackrest ne garantit pas RPO=0 (zéro perte de données). Décrivons les concepts de pgbackrest :

• Une sauvegarde peut être :
  • Complet. Une sauvegarde complète copie l'intégralité du cluster de bases de données.
  • Différentiel (diff). Une sauvegarde différentielle copie uniquement les fichiers qui ont été modifiés depuis la dernière sauvegarde complète. Pour une restauration réussie, la sauvegarde différentielle et la sauvegarde complète précédente doivent être valides.
  • Incrémentiel (incr). Une sauvegarde incrémentielle copie uniquement les fichiers qui ont été modifiés depuis la dernière sauvegarde (qui peut être une sauvegarde complète, différentielle ou même incrémentielle). Comme pour la sauvegarde différentielle, pour réussir une restauration, toutes les sauvegardes précédentes requises (y compris cette sauvegarde, la dernière diff et la précédente complète) doivent être valides.
• Une strophe est la définition de tous les paramètres requis d'un cluster PostgreSQL. Un serveur PostgreSQL normal a sa propre strophe, tandis que les serveurs de sauvegarde auront une strophe pour chaque cluster PostgreSQL qu'ils sauvegardent.
• Une configuration est l'endroit où les informations sur les strophes sont conservées (généralement /etc/pgbackrest.conf)
• Un référentiel est l'endroit où pgbackrest conserve les WAL et les sauvegardes

L'utilisateur est encouragé à suivre la documentation comme le suggère la documentation elle-même, de haut en bas. Les fonctionnalités les plus importantes de pgbackrest sont :

• Sauvegarde et restauration parallèles
• Aucun accès SQL direct au serveur PostgreSQL n'est nécessaire
• Fonctionnement local/à distance
• Rétention basée sur :
  • rétention de sauvegarde complète (nombre de sauvegardes complètes à conserver)
  • rétention des sauvegardes diff (nombre de sauvegardes diff à conserver)
  Les sauvegardes incrémentielles n'ont pas leur propre rétention et expirent dès qu'une sauvegarde précédente expire. Ainsi, l'utilisateur peut définir un calendrier pour effectuer des sauvegardes complètes et un ensemble continu de sauvegardes différentielles entre elles.
• Sauvegarde depuis le mode veille. Certains fichiers doivent toujours provenir du serveur principal, mais la copie en bloc a lieu sur le serveur de secours. Les WAL doivent toujours provenir du primaire.
• Intégrité des sauvegardes. Les personnes derrière pgbackrest sont extrêmement prudentes en ce qui concerne l'intégrité des sauvegardes. Chaque fichier fait l'objet d'une somme de contrôle au moment de la sauvegarde et est également vérifié après la restauration pour s'assurer qu'aucun bogue matériel ou logiciel problématique ne peut entraîner une restauration défectueuse. De plus, si les sommes de contrôle au niveau de la page sont activées sur le cluster PostgreSQL, elles sont également calculées pour chaque fichier. De plus, des sommes de contrôle sont calculées pour chaque fichier WAL.
• Si la compression est désactivée et que les liens physiques sont activés, il est possible d'afficher le cluster directement à partir du catalogue. Ceci est extrêmement important pour les grandes bases de données de plusieurs To.
• Reprise d'un retour raté/interrompu. Très pratique en cas de réseaux peu fiables.
• Restauration delta :restauration ultra rapide pour les bases de données volumineuses, sans nettoyer l'ensemble du cluster.
• Push WAL asynchrone et parallèle vers le serveur de sauvegarde. C'est l'un des points forts de pgbackrest. L'archiveur PostgreSQL copie uniquement dans le spool via archive-push et le lourd travail de transfert et de traitement se produit dans un processus pgbackrest séparé. Cela permet des transferts WAL massifs tout en garantissant de faibles temps de réponse PostgreSQL.
• Remappage des tablespaces
• Assistance Amazon S3
• Prise en charge de la taille maximale de la file d'attente WAL. Lorsque le site de sauvegarde est en panne ou que le réseau est défaillant, l'utilisation de cette option donnera l'impression que l'archivage a réussi, permettant à PostgreSQL de supprimer les WAL empêchant de remplir pg_wal, et ainsi de sauver le serveur pgsql d'un éventuel PANIC.

Par conséquent, pgbackrest met l'accent sur la validation des données et les performances, il n'est donc pas surprenant qu'il soit utilisé par les installations PostgreSQL les plus importantes et les plus fréquentées. Cependant, il y a une chose qui pourrait être améliorée :

• Il serait vraiment pratique d'avoir une option plus "libérale" en ce qui concerne la rétention, c'est-à-dire de fournir un moyen de spécifier de manière déclarative une période de rétention, puis de laisser pgbackrest gérer les sauvegardes complètes/diff/incr selon les besoins.

pg_probackup

Pg_proback est un autre outil prometteur pour les sauvegardes. Il est à l'origine basé sur pg_arman. L'accent est mis sur les performances de la sauvegarde. Il est basé sur des catalogues et des instances, très similaires au reste des outils que nous avons. Ses principales fonctionnalités incluent :

• Compatibilité étendue au niveau de la sauvegarde allant de :
  • Sauvegardes complètes
  • Incrémental de trois types :
    • Sauvegarde PAGE. Changements de niveau trouvés via l'analyse WAL. Nécessite un accès complet à la séquence WAL ininterrompue depuis la sauvegarde précédente.
    • Sauvegarde DELTA. Seules les pages modifiées sont copiées dans la sauvegarde. Indépendant de l'archivage WAL, place une certaine charge sur le serveur.
    • Sauvegarde PTRACK. Nécessite un correctif spécial pgsql core. Fonctionne en maintenant un bitmap à la volée dès que les pages sont modifiées. Sauvegarde très rapide avec une charge minimale sur le serveur.
• Les sauvegardes peuvent également être divisées en :
  • Sauvegardes autonomes. Ceux-ci n'ont aucune exigence sur WAL en dehors de la sauvegarde. Pas de PITR.
  • Sauvegardes d'archives. Ceux-ci s'appuient sur l'archivage continu et prennent en charge le PITR.
• modèle multithread (contrairement à barman, pgbackrest et bien sûr PostgreSQL lui-même qui suivent un modèle multiprocessus)
• Cohérence des données et validation à la demande sans restauration
• Sauvegarde à partir d'un serveur de secours sans accès au serveur principal.
• Une spécification de stratégie de rétention expressive où la redondance peut être utilisée de manière ET avec fenêtre. La fusion des sauvegardes (via la fusion) est prise en charge en convertissant les sauvegardes incrémentielles précédentes en sauvegardes complètes afin de libérer de l'espace et de fournir une méthode pour une rotation de sauvegarde fluide.

Ainsi, pg_probackup fournit un ensemble de fonctionnalités intéressantes mettant l'accent sur les performances, ce qui profiterait aux grandes installations. Cependant, il manque encore certaines choses, à savoir :

• Aucune version officielle ne prend en charge les sauvegardes à distance. Cela signifie que pg_probackup doit s'exécuter sur le même hôte que le cluster pgsql. (Il existe une branche de développement qui s'occupe de la sauvegarde à partir d'un site distant ainsi que de l'archivage sur un serveur de sauvegarde distant)
• Aucune prise en charge en cas d'échec de reprise de sauvegarde.

Nous pouvons résumer les paragraphes ci-dessus avec une matrice de fonctionnalités comme ci-dessous.

ClusterControl

ClusterControl fournit la fonctionnalité permettant soit de générer une sauvegarde immédiate, soit d'en planifier une, et d'automatiser la tâche de manière simple et rapide.

Nous pouvons choisir entre deux méthodes de sauvegarde, pgdump (logique) et pg_basebackup (binaire). Nous pouvons également spécifier où stocker les sauvegardes (sur le serveur de base de données, sur le serveur ClusterControl ou dans le cloud), le niveau de compression et le cryptage.

De plus, avec ClusterControl, nous pouvons utiliser la fonction de récupération ponctuelle et la vérification de la sauvegarde pour valider la sauvegarde générée.