Forums PostgreSQL.fr

barthymus

Membre

Stratégie de back-up.

Bonjour à tous !

Je suis actuellement en train d'étudier la mise en place de base PostgreSQL sur nos serveurs pour remplacer certaines bases Oracle.
Ces bases necessiteront la même qualité de backupage qu'offre par exemple Oracle.
C'est à dire... La possibilité de revenir un moment donnée, mais également en cas de crash, d'un basculement... etc...

En gros, on va répondre, PITR et mode Standby. Mais j'ai un peu du mal à voir comment conjointement ces deux systêmes fonctionnent. J'ai vraiment du mal à trouver une vraie procédure complète à suivre. De plus, entre les différents types de réplications, lesquels s'adaptent à un modele PITR ?

Pour ceux qui utilisent au quotidien un système de backup, qu'utilisez vous ?

Merci beaucoup pour vos infos !

rjuju

Administrateur

Re : Stratégie de back-up.

Bonjour,

le mode standby est en fait un serveur en perpétuelle restauration, à l'aide du PITR. Vous pouvez déjà lire la documentation officielle pour avoir plus d'information:

http://docs.postgresqlfr.org/9.1/contin … iving.html
http://docs.postgresqlfr.org/9.1/recovery-config.html

Cette sauvegarde s'appuie sur une image du répertoire PGDATA et de tous les wal générés depuis. Les wal peuvent être utilisés et pour le standby (réplication native) et pour une future restauration.

Pour le choix d'un système, les 2 méthodes (PITR et pg_dump) sont complémentaire. Un dump peut permettre de ne restaurer qu'une partie de l'instance par exemple, alors qu'une restauration PITR restaurera l'intégralité du serveur. Si vous en avez la possibilité (temps de sauvegarde et espace disque), utilisez les deux.

---

Julien.
https://rjuju.github.io/

barthymus

Membre

Re : Stratégie de back-up.

Donc en faites, si on fait les choses proprement, il faut séparer les notions back up et réplication ?
En gros, je met en place sur le serveur à backupé les notions de PITR et pg_dump...
Puis j'installe un serveur de standby pour la réplication ?
Mais le PITR et la réplication se basent tout deux sur les Wals non ? Ils ne va pas avoir de conflits ?

Avec ceux deux système conjoints, j'aurais à la fois : Reprise a un temps donné d'une image précise et Restaure en cas de crash non ?
J'ai lu qu'il existait des outils qui permettait de faire certaines actions de backup mais existe t'il un outil qui réunirait a la fois PITR et Replication ?
Qu'en ai t'il de Slony, la réplication Maitre esclave qu'il propose est elle interessante sur le plan d'une logique PITR ?

Merci beaucoup !

rjuju

Administrateur

Re : Stratégie de back-up.

Sauvegarder les données sur un serveur externe est toujours une bonne chose, en cas de crash des disques par exemple.

La réplication ne rentrera pas en conflit avec les archives wals, car le serveur standby ne fera que les récupérer et n'en archivera pas (sauf si celui ci est promu en tant que maître, mais dans ce cas il y aura un changement de timeline, qui implique des noms de wals différents). Cela permet un gain de place, les wals sont archivés sur le serveur de sauvegarde, et copiés en local sur le serveur en standby lorsqu'ils sont nécessaires (depuis la version 9.0, il est possible de streamer ces informations entre le maître et l'esclave directement).

Comme dit précédemment, le dump permet une restauration partielle, contrairement à la restauration PITR. Particulièrement utile en cas de drop table malheureux par exemple, sans bloquer l'instance entière durant la récupération.

La réplication ne nécessite pas un "outil" à proprement parler, on la met en place et elle continue toute seule. La seule chose intéressante à faire est de superviser celle-ci, pour vérifier que tout se passe bien.

La réplication slony est plus compliquée à mettre en place, et sera moins performante que la réplication native. Elle est principalement utilisée pour une réplication partielle, ou une réplication entre versions majeures différentes de postgres, ce qui est impossible avec la réplication native.

---

Julien.
https://rjuju.github.io/