Sauvegarde distante

Une architecture simple et efficace

      Cette page détaille la mise en place d'une sauvegarde locale d'un cluster PostgreSQL avec Barman mais cet outil sous licence GPL édité par 2ndQuadrant est plutôt conçu pour crééer un environnement de sauvegarde centralisé et donc réaliser des sauvegardes distantes.
      Nous allons reprendre cette architecture proposée par la documentation barman :

Une architecture simple et efficace

      Différence par rapport à la sauvegarde locale, nous disposons cette fois de 2 serveurs :
      Tout d'abord, installation de barman-cli, barman et échange de clés ssh entre les utilisateurs barman et postgres : :

-- serveur pgpr10 id uid=0(root) gid=0(root) groupes=0(root) passwd postgres apt-get install barman-cli -- serveur bapr id uid=0(root) gid=0(root) groupes=0(root) apt-get install barman passwd barman su - barman ssh-keygen ssh-copy-id postgres@pgpr10 -- serveur pgpr10 su - postgres ssh-keygen ssh-copy-id barman@bapr -- serveur pgpr10 id uid=0(root) gid=0(root) groupes=0(root) passwd -d postgres -- serveur bapr id uid=0(root) gid=0(root) groupes=0(root) passwd -d barman


      A présent, paramétrage du streaming et de l'archivage des WAL :

-- serveur pgpr10 id uid=108(postgres) gid=114(postgres) groupes=114(postgres),113(ssl-cert) psql select version(); version -------------------------------------------------------------------------------------------------------- PostgreSQL 10.2 (Debian 10.2-1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 7.3.0-1) 7.3.0, 64-bit (1 ligne) show wal_level; wal_level ----------- replica (1 ligne) show max_replication_slots; max_replication_slots ----------------------- 10 (1 ligne) show max_wal_senders; max_wal_senders ----------------- 10 (1 ligne) show archive_command; archive_command ----------------- (disabled) (1 ligne) alter system set archive_command = 'rsync -a %p barman@bapr:/var/lib/barman/apptra001/incoming/%f'; ALTER SYSTEM show archive_mode; archive_mode -------------- off (1 ligne) alter system set archive_mode=on; ALTER SYSTEM show listen_addresses; listen_addresses ------------------ localhost (1 ligne) alter system set listen_addresses='192.168.56.220'; ALTER SYSTEM \q exit pg_ctlcluster 10 apptra001 restart


      En dehors de archive_command envoyant les fichiers WAL archivés vers bapr au lieu de localhost et de l'écoute sur l'adressse IPv4 logique de la machine, rien à signaler par rapport à la sauvegarde locale.
      Il faut disposer d'un superutilisateur autorisé notamment à transmettre les informations WAL. Nous pourrions utiliser postgres mais nous allons créer un utilisateur dédié appelé remotesuper en musclant sa méthode d'authentification au passage :

-- serveur pgpr10 su - postgres psql set password_encryption='SCRAM-SHA-256'; SET create role remotesuper with login superuser password 'RJoindaAimablDefndersmyHckgrp98'; CREATE ROLE \du Liste des rôles Nom du rôle | Attributs | Membre de -------------+---------------------------------------------------------------------------------+----------- postgres | Superutilisateur, Créer un rôle, Créer une base, Réplication, Contournement RLS | {} remotesuper | Superutilisateur

      Autorisation des connexions de l'utilisateur remotesuper à la base postgres et pour la réplication après authentification par mot de passe (uniquement par la méthode scram-sha-256) depuis le serveur bapr (adresse ipv4 logique 192.168.56.222) dans /etc/postgresql/10/apptra001/pg_hba.conf :

-- serveur pgpr10 vi /etc/postgresql/10/apptra001/pg_hba.conf host postgres remotesuper 192.168.56.222/32 scram-sha-256 host replication remotesuper 192.168.56.222/32 scram-sha-256 pg_ctlcluster 10 apptra001 reload


      C'est fini pour la partie "postgres". À présent la partie "barman" en commançant par le stockage du mot de passe de remotesuper dans un fichier dédié à l'accès restreint:

-- serveur bapr id uid=108(barman) gid=113(barman) groupes=113(barman) vi /var/lib/barman/.pgpass pgpr10:5432:postgres:remotesuper:RJoindaAimablDefndersmyHckgrp98 pgpr10:5432:replication:remotesuper:RJoindaAimablDefndersmyHckgrp98 chmod 600 /var/lib/barman/.pgpass

      Place à présent à la configuration de barman. Le fichier de configuraiton va être renseigné de manière à garantir une fenêtre de recover de 5 jours, c'est à dire qu'il sera toujours possible de faire revenir les bases du cluster en arrière de 5 jours avec ce que contient l’espace Barman. Avec une sauvegarde planifiée de manière hebdomadaire, le nombre de sauvegardes présentes en ligne sera au maximum de 2 :

-- serveur bapr id uid=0(root) gid=0(root) groupes=0(root) vi /etc/barman.d/01-apptra001.conf [apptra001] description = "Sauvegarde apptra001" ssh_command = ssh postgres@pgpr10 retention_policy = RECOVERY WINDOW OF 5 days compression = gzip reuse_backup = link minimum_redundancy = 1 last_backup_maximum_age = '8 days' recovery_options = 'get-wal' conninfo = port=5432 host=pgpr10 user=remotesuper dbname=postgres archiver = on streaming_conninfo = port=5432 host=pgpr10 user=remotesuper streaming_archiver = on streaming_archiver_name = barman_receive_wal slot_name = barman chown barman /etc/barman.d/01-apptra001.conf su - barman barman receive-wal --create-slot apptra001 Creating physical replication slot 'barman' on server 'apptra001' Replication slot 'barman' created barman check apptra001 ... barman backup apptra001 barman check apptra001 Server apptra001: PostgreSQL: OK is_superuser: OK PostgreSQL streaming: OK wal_level: OK replication slot: OK directories: OK retention policy settings: OK backup maximum age: OK (interval provided: 8 days, latest backup age: 56 seconds) compression settings: OK failed backups: OK (there are 0 failed backups) minimum redundancy requirements: OK (have 1 backups, expected at least 1) ssh: OK (PostgreSQL server) not in recovery: OK archive_mode: OK archive_command: OK continuous archiving: OK pg_receivexlog: OK pg_receivexlog compatible: OK receive-wal running: OK archiver errors: OK crontab -e 0 20 * * 0 barman backup all 2>&1 > /dev/null


      Tout est OK. En fait, le slot n'est pas réellement nécessaire puisque nous archivons de toute façon chaque WAL via rsync/ssh mais il ne fait pas de mal.
      Le RPO (recovery point objective, perte de données maximale admissible) avec une telle architecture est proche de 0. Nous pouvons toujours perdre quelques transactions validées car nous n'attendons pas la confirmation par Barman qu'il a bien pris en compte une information de journalisation pour considérer qu'elle est validée.
      Il serait possible d'imposer le streaming WAL synchrone vers Barman afin de passer à un RPO de 0 mais je le déconseille pour l'instant. Il est en effet préférable de disposer d'au moins 2 destinations pour le streaming WAL synchrone sous peine de compromettre la disponibilité. De plus, activer le streaming WAL synchrone peut avoir un impact sur les performances donc il faut évaluer le besoin et les moyens à attribuer au cas par cas.

Mise à jour : 13/02/2018