Vous n'êtes pas identifié(e).
Pages : 1
rebonjour...
j'effectue un pg_start_backup (toto) => Ok
lorsque je fais mon pg_stop_backup ... voici les messages d'erreur :
Mabase=# SELECT pg_stop_backup ();
NOTICE: pg_stop_backup cleanup done, waiting for required WAL segments to be archived
WARNING: pg_stop_backup still waiting for all required WAL segments to be archived (60 seconds elapsed)
HINT: Check that your archive_command is executing properly. pg_stop_backup can be canceled safely, but the database backup will not be usable without all the WAL segments.
et ça continue jusqu'à ce que je cancelle...
Il semblerait que ce soit un problème dans mon archive_command, mais je ne vois pas pourquoi... pouvez-vous m'aider
Voici mon prostgresql.conf :
archive_command = 'cp %f /srv/pgsql/backup/%p'
archive_timeout = 360 # force a logfile segment switch after this
Hors ligne
Il faut inverser les paramètres dans votre archive_commande :
cp %p /srv/pgsql/backup/%f
Julien.
https://rjuju.github.io/
Hors ligne
Merci rjuju...
après modification des valeurs du archive_command, le problème persistait et en regardant la log j'ai vu qu'il manquait de la place sur le l'arborescence cible... nous avons corrigé et c'est bon maintenant !
Hors ligne
je suis en train de tester une restauration de database...
Le contexte : 1 instance avec deux databases TOTO (80 gigas) et TITI (200 Méga)
Hier soir :
pg_start_backup
cp de mes repertoire 'base' (fichier base.tar.gz ) et du répertoir x_log (xlog.tar.gz) donc 2 fichiers...
pg_stop_backup
Ce matin => Drop de la base toto
Cet aprèm => Je voudrais restaurer avant le drop de TITI donc la plus petite base => ok
1°) Dans la doc postgrès, ils parlent de : pg_create_restore_point()... je n'ai pas compris pourquoi... faut-il l'exécuter en même temps que start-cp-et stop backup afin d'avoir un point d'ancrage ?
2°) Mon instance TITI étant ma base la plus petite, j'aimerai ne pas dropper mon repertoire 'base' (pour ensuite le remplacer par mon 'base.tar.gz') mais garder mon répertoire 'base' et juste rejouer les wal qui sont archivées... est-ce possible ?
Pouvez-vous m'aider
Hors ligne
dans le paragraphe (ce maton => ...) C'était drop de la base TITI que je voulais écrire (donc de la plus petite )
Hors ligne
1) Non, c'est utile uniquement si vous prévoyez une future restauration.
2) Non ce n'est pas possible.
Pour les sauvegarde niveau système de fichier, il faut copier toute l'arborescence, pas uniquement le répertoire base et pg_xlog. Si vous avez des tablespace il faut également les sauvegarder.
Il faut aussi comprendre que ce mode de restauration n'est pas possible pour un base spécifique mais se fait au niveau de l'instance. C'est également une sauvegarde destinée à une reprise sur incident, par pour de la restauration ponctuelle et sélective. Si vous avez toute l'arboresence du répertoire data d'hier (à la suite du pg_start_backup) ainsi que tous les wal qui ont été générés jusqu'au drop de la base TITI, vous pourrez la récupérer, mais cela veut dire que vous perdrez tout ce qui a pu être fait sur la base TOTO (ou n'importe quelle autre base) entre le drop et le moment ou vous faîtes la restauration.
Si vous ne voulez pas ce comportement, le seul moyen est de créer un nouveau serveur et faire la restauration du data, rejouer les wal jusqu'un peu avant le drop de TITI, puis dumper la base TITI pour la restaurer sur votre vraie instance.
Dernière modification par rjuju (24/05/2012 16:28:54)
Julien.
https://rjuju.github.io/
Hors ligne
Merci rjuju pour vos explications...
Je trouve cela néanmoins pas très souple... car recharger complètement un environnement et ensuite rejouer les wal archivés pour par exemple, un drop malheureux sur une table, est très lourd a gérer...
Y aura t'il dans les versions suivantes de postgres quelques améliorations sur ce genre de problème ?
Hors ligne
Non, car les wals sont communs à une instance. Même si un jour ils passent par database cela sera toujours problématique pour une seule table.
Si vous voulez une sauvegarde plus souple, il faut faire des dumps réguliers en mode custom, et la vous pourrez restaurer uniquement le ou les objets voulus. Mais bien sur en cas de drop d'une table vous ne pourrez restaurer une table qu'au moment du drop et perdrez ce qu'il y a eu entre temps.
Maintenant un drop malheureux n'est pas censé arriver fréquemment, sauf si tous les utilisateurs ont le droit de dropper des bases ou tables, auquel cas il faudrait revoir la politique de sécurité pour éviter cela.
Julien.
https://rjuju.github.io/
Hors ligne
Ok pour le drop malheureux... c'est vrai que cela n'arrive pas tous les jours... jusqu'au jour où !
Bref, mon problème sur les dumps réguliers est que ma database fait 90 Gigas... et donc nous préférerions une formule comme start-cp-stop backup avec les wal à rejouer...
Je reprends ma question 1 : ais-je bien compris si je dis que Le pg_create_restore_point() pourrait donc être effectué disons toutes les heures, pendant la journée de travail... en cas de restauration je pourrai ensuite choisir le point de synchro voulu ?
Hors ligne
Oui, c'est le but de pg_create_restore_point(). Mais encore une fois cela remettra votre serveur au même état qu'au moment de l'appel, et donc tout ce qui a été fait après sera perdu. Cette fonction sert juste a définir un point dans le temps facilement retrouvable.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
