Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je suis en train de me poser (enfin) les bonnes questions concernant la sauvegarde de ma base.
Actuellement, je sauvegarde les fichiers de config (postgreql.conf, etc...) et par ailleurs j'utilise pg_dump pour sauvegarder mes tables. Tous les scripts que j'ai pour recréer la base depuis le début peuvent me servir en cas de problème, mais sont-ils toujours à jour...
Je compte donc envisager le problème sous l'angle suivant :
- pouvoir restaurer une table si jamais elle disparait (un drop malheureux) => pour cela il faut que je sauvegarde les tables uniquement ;
- pouvoir restaurer la base si j'ai un crash : pour cela il faut que je sauvegarde les schémas et les rôles, mais sans les données.
J'ai vu que je pouvais utiliser pg_dumpall, mais si je fais 1 sauvegarde pour les tablespaces, une pour les schémas, et une pour les rôles, est-ce que ça parait cohérent?
Ce que j'ai du mal à comprendre, c'est si je dois repartir de 0 pour recréer la base, est-ce que je dois faire comme ci-dessous :
- je recrée éventuellement une instance avec initdb ;
- je récupère les anciens fichiers de configuration comme pg_hba.conf et postgresql.conf ;
- je relance le script qui me recrée les tablespaces ;
- je relance la création de la base par createdb mabase -D montablespace ;
- je relance le script qui crée les schémas ;
- je relance le script qui crée les rôles ;
- je recrée les tables que j'ai sauvegardées par pg_dump ;
Merci d'avance pour votre aide
Hors ligne
Bonjour,
mélange la sauvegarde pitr avec un pgbump ça suffira. ( en admettant que tu es un serveur pour receptionner tout ça 
)
et ça dépend de la taille de ta base, et sa vitesse évolution.
Hors ligne
Ma base fait 400 Go, elle grossit régulièrement mais pas trop en volume, disons dans les 30 Mo par jour.
Vous me conseillez d'utiliser pg_start_backup() mais la question est "combien de temps cela prend-il?" et quel volume.
Si je dois compter le volume équivalent, je ne l'ai pas...c'est pour cela que les sauvegardes des tables par pg_dump et par ailleurs de la structure par pgdump_all me convenaient bien.
Nous avons par ailleurs un logiciel qui tourne sur le serveur et qui fait une sauvegarde du système de fichiers, mais je ne suis pas sûr que si j'ai un crash à l'instant T et que la sauvegarde date de T-3h je puisse remonter la base même en recopiant tout les systèmes de fichiers concernés.
Dernière modification par yoyostras (23/06/2011 11:14:07)
Hors ligne
bah votre base sera corrompu donc démarrera pas facilement voir pas du tout ( jamais testé, a voir avec mar ou gleu )
mais un pgdump doit prendre un sacré temps non ?
vu que vous faites une sauvegarde des fichier le relier a du pitr est le mieux vu que vous faites déjà la moitié du boulot.
et le temps que ça prend ? beaucoup moins qu'un pgdump.
Hors ligne
Bonjour,
L'idée avec le PITR, c'est de faire une sauvegarde complète de la base (avec pg_start_backup) de manière régulière (mais pas tous les jours). Ensuite, vous sauvegarderez tous les jours les archives des journaux de transactions.
Si la base crash, vous pourrez alors reconstruire votre base en prenant la sauvegarde de T-3h et vous indiquez à PostgreSQL (via un fichier recovery.conf) qu'il trouvera les archives des journaux de transactions à tel endroit. Il s'en servira pour appliquer l'ensemble des modifications à votre base restaurée et la ramènera à l'instant T. Sous réserve évidemment que les fichiers soient disponibles.
J'appuie sur le conseil de kenrio qui est de relier votre outil de sauvegarde de fichiers avec le PITR. Ensuite, pour la sauvegarde des archives, vous n'aurez pas un volume très important à sauvegarder, comparativement à la volumétrie de la base.
Pour de plus amples informations sur la mise en oeuvre, je ne peux que vous renvoyer vers le manuel rigolo: PITR.
Thomas Reiss
Hors ligne
Perso, je conseille souvent un "pg_dumpall -g" pour récupérer la définition des objets globaux (bases, utilisateurs, tablespaces) et je fais un "pg_dump -Fc" pour chaque base. Simple et très efficace.
La sauvegarde PITR est intéressante mais plus complexe à mettre en place.
Ce que j'ai du mal à comprendre, c'est si je dois repartir de 0 pour recréer la base, est-ce que je dois faire comme ci-dessous :
Attention, toujours restaurer les utilisateurs avant les objets (sinon PostgreSQL ne pourra pas restaurer les propriétaires et les droits).
Guillaume.
Hors ligne
J'ai testé le cas où je dois (ou veux) remonter ma base sur une autre machine.
J'ai donc effectué une sauvegarde des schemas/roles/tablespaces par pgdump_all et j'ai une sauvegarde régulière du contenu de mes tables par pg_dump -Fc (2 fois par mois) qui est assez longue, mais c'est une base volumineuse.
Par ailleurs je sauvegarde les fichiers pg_hba.conf et postgresql.conf et le fichier .pgpass.
J'ai donc installé une version de PostgreSQL sur la nouvelle machine, puis recopié les fichiers pg_hba.conf et postgresql.conf, puis lancé le serveur postgreSQL.
J'ai ensuite recréé les tablespaces (là il faut soit avoir le même répertoire cible que sur la 1ere machine, soit les faire correspondre à d'autres répertoires) : c'est un peu fastidieux s'il y a beaucoup de tablespaces, mais dans mon cas j'en ai 2.
J'ai ensuite recréé la base, puis rejouer les scripts obtenus par pgdump_all et permettant de créer les objets.
Enfin j'ai restauré les tables par pg_restore.
Dit comme ça, cela parait très fastidieux, mais ça me permet d'avoir tout ce qu'il faut pour reconstruire une base ailleurs si jamais il y a un crash du disque où la base est stockée.
J'ai quand même une question :
je sauvegarde les schémas par la commande pg_dumpall -v -U postgres -p 5433 -i -s > sauvegarde_schemas.sql
puis les roles par la commande pg_dumpall -v -U postgres -p 5433 -i -r > sauvegarde_roles.sql
Mais lorsque je rejoue le fichier sauvegarde_schemas.sql, il me crée les roles, et je n'ai pas besoin de relancer le fichier sauvegarde_roles.sql? C'est normal?
Hors ligne
Oui. pg_dumpall sauvegarde les objets globaux, même si vous utilisez l'option -s. Donc, forcément, à la restauration, si vous commencez par les schémas, vous aurez aussi les rôles.
Guillaume.
Hors ligne
Pages : 1
