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 :
- la création d’un répertoire contenant la base
- 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.
- La sauvegarde du fichier postgresql.conf sous le nom postgresql.conf.origin
- 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é.