Restauration, recover maximal avec pgBackRest

      Pour ce scenario, nous allons supposer que nous disposons d'une sauvegarde pgBackRest 2.x dans un environnement PostgreSQL 11 sur Debian 10 et que nous voulons perdre le moins possible d'informations validées :

-- utilisateur postgres, une activite existe dans une table temoin avec une ligne inseree par seconde psql -p 5432 \set AUTOCOMMIT on create table temoin(col timestamp primary key); CREATE TABLE insert into temoin values(clock_timestamp()); INSERT 0 1 \watch 1 ... -- utilisateur root, crash ! rm -fr /var/lib/postgresql/11/apptra001/* -- session de l'utilisateur postgres ... ven. 26 juil. 2019 16:51:55 CEST (chaque 1s) INSERT 0 1 ATTENTION: arrêt de la connexion à cause de l'arrêt brutal d'un autre processus serveur -- utilisateur postgres, de quelles sauvegardes disposons-nous ? pgbackrest info stanza: apptra001 status: ok cipher: none db (current) wal archive min/max (11-1): 000000010000000000000002/000000010000000000000004 full backup: 20190726-162157F timestamp start/stop: 2019-07-26 16:21:57 / 2019-07-26 16:22:43 wal start/stop: 000000010000000000000002 / 000000010000000000000002 database size: 31.6MB, backup size: 31.6MB repository size: 4.2MB, repository backup size: 4.2MB -- utilisateur postgres, restore sans option particuliere pgbackrest --log-level-console=info --stanza=apptra001 restore ... -- utilisateur postgres, on regarde le contenu de recovery.conf cat /var/lib/postgresql/11/apptra001/recovery.conf restore_command = 'pgbackrest --log-level-console=info --stanza=apptra001 archive-get %f "%p"' -- utilisateur root, on redemarre le cluster pg_ctlcluster 11 apptra001 start -- utilisateur postgres, on regarde le fichier de log du cluster et on interroge la table temoin tail -50 /var/log/postgresql/postgresql-11-apptra001.log ... 2019-07-26 16:54:09.492 P00 INFO: unable to find 00000002.history in the archive 2019-07-26 16:54:09.492 P00 INFO: archive-get command end: completed successfully (4ms) 2019-07-26 16:54:09.493 CEST [1334] LOG: identifiant d'un timeline nouvellement sélectionné : 2 2019-07-26 16:54:09.557 CEST [1334] LOG: restauration terminée de l'archive 2019-07-26 16:54:09.567 P00 INFO: archive-get command begin 2.10: [00000001.history, pg_wal/RECOVERYHISTORY] --log-level-console=info --pg1-path=/var/lib/postgresql/11/apptra001 --repo1-path=/var/lib/pgbackrest --stanza=apptra001 2019-07-26 16:54:09.571 P00 INFO: unable to find 00000001.history in the archive 2019-07-26 16:54:09.571 P00 INFO: archive-get command end: completed successfully (4ms) 2019-07-26 16:54:09.626 CEST [1352] [inconnu]@[inconnu] LOG: paquet de démarrage incomplet 2019-07-26 16:54:09.680 CEST [1333] LOG: le système de bases de données est prêt pour accepter les connexions psql -p 5432 select max(col) from temoin; max --------------------------- 2019-07-26 16:42:41.96993


      Un autre outil de sauvegarde, Barman, permet de perdre peu, voire pas, d'information validée grâce au streaming du WAL courant. Cette fonctionnalité n'est pas intégrée dans pgBackRest et nous avons perdu un peu plus de 9 minutes d'activité lors de cette session de restauration.
      Nous n'avons pas eu de chance, c'est presque la perte maximale avec un paramètre archive_timeout fixé à 600s (10 minutes). C'est un point à considérer en choisissant pgBackRest : une hot standby est nécessaire pour garantir un RPO de 0. Il faut cependant tenir compte du caractères artificiel du test. L'intervalle réel entre 2 archivages de WAL via archive_command est souvent bien inférieur à 10 minutes sur un cluster à l'activité soutenue.
      Dernier point, une nouvelle timeline (incarnation dans le vocabulaire Oracle Database) a été ouverte et je recommande toujours d'effectuer une sauvegarde au début de chaque timeline pour simplifier les restaurations.

Mise à jour : 26/07/2019