Fin 2012, j’ai présenté « pgbarman », une solution de sauvegarde et récupération pour PostgreSQL et décrit son installation. Pgbarman fournit un ensemble de commandes vous permettant la mise en œuvre de sauvegardes vers un serveur dédié. Le principal intérêt est à mon sens la gestion d’un catalogue de vos sauvegardes et la génération de commandes destinées à une reconstruction locale ou sur un serveur tiers.

Je vais maintenant parler de la gestion des sauvegardes et décrire la mise en œuvre d’une reconstruction (PITR) .

La gestion des sauvegardes

Avec Pgbarman nous avons à notre disposition un fichier de configuration et des commandes où nous trouvons les paramètres de gestion de la rétention des  sauvegardes. Depuis la version 1.2  deux politiques de rétention peuvent être appliquées :

  • une politique de rétention basée sur le temps
  • une politique de rétention basée sur le nombre de sauvegarde.

L’exemple de fichier de configuration de Pgbarman nous montre les paramétrages possibles.

;; ; Minimum number of required backups (redundancy)
;; ; minimum_redundancy = 1
;;
;; ; Examples of retention policies
;;
;; ; Retention policy (disabled)
;; ; retention_policy =
;; ; Retention policy (based on redundancy)
;; ; retention_policy = REDUNDANCY 2
;; ; Retention policy (based on recovery window)
;; ; retention_policy = RECOVERY WINDOW OF 4 WEEKS

N.B. : le paramètre minimum_redundancy = 1 empêchera la suppression de la dernière sauvegarde et protègera d’un effacement involontaire…..

Il est possible de voir l’effet de ce paramétrage avec les commandes suivantes :
La commande Barman status qui nous donne un résumé de l’état des sauvegardes :

barman@vmpgdeb1:/etc/barman$ barman status dbi
Server dbi:
    description: dbi PostgreSQL Database
    PostgreSQL version: 9.1.8
    PostgreSQL Data directory: /u01/pgdata/dbi
    archive_command: rsync -a %p barman@vmpgdeb1:/u03/pg/backup/dbi/incoming/%f
    archive_status: last shipped WAL segment 0000000100000000000000D3
    current_xlog: 0000000100000000000000D3
    Retention policies: enforced (mode: auto, retention: REDUNDANCY 4, WAL retention: main)
    No. of available backups: 5
    first available backup: 20130927T173313
    last available backup: 20131010T093548

La commande Barman list-backup qui nous donne la liste détaillée des sauvegardes :

barman list-backup dbi
dbi 20131010T093548 - Thu Oct 10 09:36:02 2013 - Size: 215.0 MiB - WAL Size: 0 B
dbi 20131002T114643 - Wed Oct  2 11:46:53 2013 - Size: 197.0 MiB - WAL Size: 1.0 GiB
dbi 20130929T113103 - Sun Sep 29 11:31:09 2013 - Size: 107.0 MiB - WAL Size: 915.0 MiB
dbi 20130927T174926 - Fri Sep 27 17:51:55 2013 - Size: 107.0 MiB - WAL Size: 6.0 MiB
dbi 20130927T173313 - Fri Sep 27 17:45:59 2013 - Size: 126.0 MiB - WAL Size: 82.0 MiB - OBSOLETE

Comme on peut le voir la politique de rétention est à REDUNDANCY 4.
Nous avons 5 sauvegardes disponibles, c’est pourquoi Pgbarman considère la sauvegarde du  « Sep 27 17:45:59 2013 » comme étant obsolète.
Par conséquence, la prochaine application de la commande cron la purgera :

barman cron
Processing xlog segments for dbi
    0000000100000000000000D3
Deleting backup 20130927T173313 for server dbi
Delete associated WAL segments:
    00000001000000000000001F
    000000010000000000000020
    000000010000000000000020.00000020.backup
    000000010000000000000021
    ......
    000000010000000000000037
    000000010000000000000038
Done

 

barman list-backup dbi
dbi 20131010T093548 - Thu Oct 10 09:36:02 2013 - Size: 215.0 MiB - WAL Size: 16.0 MiB
dbi 20131002T114643 - Wed Oct  2 11:46:53 2013 - Size: 197.0 MiB - WAL Size: 1.0 GiB
dbi 20130929T113103 - Sun Sep 29 11:31:09 2013 - Size: 107.0 MiB - WAL Size: 915.0 MiB
dbi 20130927T174926 - Fri Sep 27 17:51:55 2013 - Size: 107.0 MiB - WAL Size: 6.0 MiB

Il est par ailleurs possible de supprimer une sauvegarde intermédiaire avec la commande delete. Un exemple :

barman list-backup dbi
dbi 20131010T103012 - Thu Oct 10 10:30:22 2013 - Size: 215.0 MiB - WAL Size: 0 B
dbi 20131010T093548 - Thu Oct 10 09:36:02 2013 - Size: 215.0 MiB - WAL Size: 16.0 MiB
dbi 20131002T114643 - Wed Oct  2 11:46:53 2013 - Size: 197.0 MiB - WAL Size: 1.0 GiB
dbi 20130929T113103 - Sun Sep 29 11:31:09 2013 - Size: 107.0 MiB - WAL Size: 915.0 MiB
dbi 20130927T174926 - Fri Sep 27 17:51:55 2013 - Size: 107.0 MiB - WAL Size: 6.0 MiB - OBSOLETEbarman delete dbi 20131010T093548
Deleting backup 20131010T093548 for server dbi
Donebarman list-backup dbi
dbi 20131010T103012 - Thu Oct 10 10:30:22 2013 - Size: 215.0 MiB - WAL Size: 0 B
dbi 20131002T114643 - Wed Oct  2 11:46:53 2013 - Size: 197.0 MiB - WAL Size: 1.0 GiB
dbi 20130929T113103 - Sun Sep 29 11:31:09 2013 - Size: 107.0 MiB - WAL Size: 915.0 MiB
dbi 20130927T174926 - Fri Sep 27 17:51:55 2013 - Size: 107.0 MiB - WAL Size: 6.0 MiB

Comme vous pouvez le constater la notion d’obsolescence de la dernière sauvegarde n’est pas liée au nombre de sauvegarde réalisée mais au nombre résident sur disque.

;

Reconstruction avec retour à une date donnée. ( PITR )

Description de la situation: Nous avons une base dbi sur le serveur vmpgdeb2 sauvegardée sur notre serveur de sauvegarde avec pgbarman.
Nous avons un projet de montée de version de cette base et nous voulons tester la procédure. Pour cela nous allons reconstruire sur la machine vmpgdeb3 une base test à partir d’une sauvegarde de la base au 9 octobre 17:00.

La commande de récupération sera la suivante :

barman recover --remote-ssh-command=''ssh postgres@vmpgdeb3''--target-time ''2013-10-09 17:00:00.000'' dbi 20131002T114643 /u02/pg/data/testdb

Il faudra préalablement autoriser la connexion au serveur vmpgdeb3 et donner les droits de création sur le répertoire /u02/pg/data à l’utilisateur Postgres.
Exécution de la commande qui est plutôt une commande de restoration que de reconstruction :

barman recover --remote-ssh-command=''ssh postgres@vmpgdeb3''--target-time ''2013-10-09 17:00:00.000'' dbi 20131002T114643 /u02/pg/data/testdbStarting remote restore for server dbi using backup 20131002T114643
Destination directory: /u02/pg/data/testdb
Doing PITR. Recovery target time: '2013-10-09 17:00:00'
Copying the base backup.
Copying required wal segments.
Generating recovery.conf
The archive_command was set to 'false' to prevent data losses.Your PostgreSQL server has been successfully prepared for recovery!Please review network and archive related settings in the PostgreSQL
configuration file before starting the just recovered instance.

Le résultat sur le serveur vmpgdeb3 est :

  1. la création d’un répertoire contenant la base
  2. la création dans ce répertoire, en plus des fichiers de la base, du répertoire barman_xlog contenant l’ensemble des fichiers WAL nécessaires à la reconstruction.
  3. La sauvegarde du fichier postgresql.conf sous le nom postgresql.conf.origin
  4. la création d’un fichier recovery.conf ou nous trouverons les commandes de recovery.

Contenu de recovery.conf :

cat recovery.conf
restore_command = ‘cp barman_xlog/%f %p’
recovery_end_command = ‘rm -fr barman_xlog’
recovery_target_time = ‘2013-10-09 17:00:00.000’

Modification de postgresql.conf:

diff postgresql.conf.origin postgresql.conf
183c183,184
< archive_command = 'rsync -a %p barman@vmpgdeb1:/u03/pg/backup/dbi/incoming/%f'    # command to use to archive a logfile segment
---
> #BARMAN# archive_command = 'rsync -a %p barman@vmpgdeb1:/u03/pg/backup/dbi/incoming/%f'    # command to use to archive a logfile segment
> archive_command = false

Avant de lancer la récupération, nous devons modifier les paramètres propres à notre environnement de travail, à savoir :

  • Ajout du cluster dans le fichier postgresql.cnf de notre gestionnaire d’environnement dmkpg
  • Création d’un répertoire d’administration de la base
  • Modification du port de connexion et de la destination du logging

On peut ensuite, une fois l’environnement positionné, démarrer le cluster de db par la commande :

pg_ctl start
server starting

Le processus de récupération démarre immédiatement et s’interrompt lorsqu’il a atteint la dernière transaction complète avant le point de restoration, dans notre cas, la base ayant été arrêtée entre le 6 et le 9 octobre. Le restore n’a pas pu se poursuivre au-delà de la dernière transaction complète enregistrée :

last completed transaction was at log time 2013-10-06 17:19:26.555007+02
2013-10-10 12:03:15 CEST [2597]: [93-1] user=,db= LOG:  restored log file "0000000100000000000000D1" from archive

Un examen des WAL montre que la base a produit des archives depuis le 6 octobre, mais uniquement parce que le paramètre archive_timeout = 3600 était actif ou parce que le cluster de base avait redémarré :

-rw------- 1 barman postgres 16777216 Oct  9 11:47 /u03/pg/backup/dbi/wals/0000000100000000/0000000100000000000000CA
-rw------- 1 barman postgres 16777216 Oct  9 12:47 /u03/pg/backup/dbi/wals/0000000100000000/0000000100000000000000CB
-rw------- 1 barman postgres 16777216 Oct  9 13:47 /u03/pg/backup/dbi/wals/0000000100000000/0000000100000000000000CC
-rw------- 1 barman postgres 16777216 Oct  9 14:47 /u03/pg/backup/dbi/wals/0000000100000000/0000000100000000000000CD
-rw------- 1 barman postgres 16777216 Oct  9 15:47 /u03/pg/backup/dbi/wals/0000000100000000/0000000100000000000000CE
-rw------- 1 barman postgres 16777216 Oct  9 16:24 /u03/pg/backup/dbi/wals/0000000100000000/0000000100000000000000CF

Une fois le « recover » fini, le moteur de postgres renomme le fichier recovery.conf en recovery.done et ouvre la base avec une new timeline et produit des fichiers WAL avec cette nouvelle timeline ce qui donne :

-rw-------  1 postgres postgres 16777216 Oct 10 12:03 0000000200000000000000D1
-rw-------  1 postgres postgres 16777216 Oct 10 12:07 0000000200000000000000D2
-rw-------  1 postgres postgres 16777216 Oct 10 12:11 0000000200000000000000D3
-rw-------  1 postgres postgres 16777216 Oct 10 12:11 0000000200000000000000D4

La base est immédiatement disponible en fin de récupération.

Conclusion

Pgbarman est une solution simple et efficace de sauvegarde de vos bases PostgreSQL, il n’existe pas encore de commandes permettant de mettre en œuvre une réplication de base à partir de Pgbarman. Le chemin restant à faire ne semblant pas très grand, l’équipe de développement de 2nd Quadrant y pense et est ouverte au proposition de sponsoring d’une telle fonctionnalité.