Blog - comments

Hi goog article can we install avdf firewall with flat network if it's possible please let me know ?

Thilina
First, thank you for your interrest in this blog.Yes, the byte code will be interpreted each time bu...
BIEHLER Stephane
Pretty sure this is wrong:> already said that JVMs interprets the generated byte code - that's true...
Gs
Michael, great article, however, I would disagree on DRS/Host Affinity. You are legally only requir...
David Bradshaw
Hi lauri, db_file_multiblock_read_count is still used in exadata smartscan because it defines the si...
Blog Open Source Team Pgbarman : gestion de sauvegarde et récupération PostgreSQL

dbi services Blog

Welcome to the dbi services Blog! This IT blog focuses on database, middleware, and OS technologies such as Oracle, Microsoft SQL Server & SharePoint, EMC Documentum, MySQL, PostgreSQL, Sybase, Unix/Linux, etc. The dbi services blog represents the view of our consultants, not necessarily that of dbi services. Feel free to comment on our blog postings.

  • Home
    Home This is where you can find all the blog posts throughout the site.
  • Categories
    Categories Displays a list of categories from this blog.
  • Tags
    Tags Displays a list of tags that have been used in the blog.
  • Bloggers
    Bloggers Search for your favorite blogger from this site.

Pgbarman : gestion de sauvegarde et récupération PostgreSQL

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 - OBSOLETE
barman delete dbi 20131010T093548
Deleting backup 20131010T093548 for server dbi
Done
barman 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é.

 

Rate this blog entry:
3

Comments

  • No comments made yet. Be the first to submit a comment

Leave your comment

Guest Wednesday, 22 October 2014
AddThis Social Bookmark Button
Deutsch (DE-CH-AT)   French (Fr)

Contact

Contact us now!

Send us your request!

Our workshops

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

Expert insight from insiders!

Fixed Price Services

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

A safe investment: our IT services at fixed prices!

Your flexible SLA

dbi FlexService SLA - ISO 20000 certified.

dbi FlexService SLA ISO 20000

ISO 20000 certified & freely customizable!

dbi services Newsletter