Tout à fait gleu, je ne sauvegarde pas pg_xlog mais je sauvegarde les WAL du répertoire d'archive des WAL géré par Postgresql. Pour cela, j'utilise le fichier *backup de pg_xlog pour identifier les WAL archivés a embarquer avec la sauvegarde.
Dans le cas particulier des sauvegardes par snapshots sur VM, où c'est une image disque qui est fait par le système, cela implique que l'ensemble des WAL du répertoire d'archive sont inclus dans le snapshot, ce qui n'est forcement pas problématique.
Philippe

En passant par un nouvel environnement:
     _ Restauration de la VM sur le nouvel environnement
     _ L'instance ne va normalement pas démarrer, il est nécessaire de créer le fichier recovery.conf qui va bien et de la lancer.
     _ Lui mettre à disposition les WAL qu'elle demande (Si la sauvegarde est complète, ces WAL seront dedans).
     _ Une fois opérationnelle, la stopper
     _ Stopper l'ancienne instance, sauvegarder les données si possible (Sauf si pas de place, mais je ne drop jamais de fichier en situation de restauration)
     _ Recopier la grappe de données du nouvel environnement sur l'ancien environnement
     _ Relancer sur l'ancien environnement

En espérant ne rien avoir oublié.
Philippe

Bonjour
Je ne sais pas si dans votre cas c'est possible, mais chez nous le snapshot commence par lancer un de nos outils pour passer l'instance en "start backup", et à la fin du snapshot, le "stop backup" est lancé.
Ensuite lorsque l'on doit repartir sur un snapshot, on rentre dans le cas d'une restauration PITR. Certes nécessitant la création d'un recovery.conf, donc une action manuelle pour redémarrer, mais jusqu'à aujourd'hui tous nos tests ont été concluant sur le sujet.

Bonjour,
La colonne 'usename' de la table pg_stat_activity donne se renseignement:
    select * from pg_stat_activity where datname='mabase';

Bonjour,

Merci 'Gleu' pour cet éclaircissement.

Donc si j'ai bien compris:
     _ bgwriter est un processus qui tourne en tâche de fond et qui est lancé au lancement de l'instance,
     _ Ce processus traite de manière régulière les Checkpoints
          Paramètres: checkpoint_segments, checkpoint_timeout et checkpoint_completion_target,
     _ En plus des checkpoints, bgwriter assure en boucle la descente sur disque de buffers au besoin. Le fait t'il aussi pendant la phase de checkpoint: Je regarderai cela.
          Paramètres: bgwriter_delay, bgwriter_lru_maxpages et bgwriter_lru_multiplier

Optimisations et règles de fonctionnements
     _ Eviter au mieux les écritures de buffers par les backends. Les écritures doivent être prises en charge par le bgwriter, soit en phase de checkpoint soit directement à l'initiative de bgwriter.
     _ Empêcher le déclenchement des checkpoints par dépassement du checkpoint_segments. Le déclenchement doit se faire par checkpoint_timeout.
     _ Il peut être nécessaire d'augmenter le shared_buffers si bgwriter ne suit pas la charge de modifications en base.
     _ Lisser le taux de descentes des buffers sur disque en ajustant les paramètres checkpoint_completion_target et bgwriter*

Etes vous d'accord avec ces explications ?
Avez-vous d'autres points à ajouter concernant le fonctionnement ou le paramétrage ?

Merci à vous
Cdlt

Merci pour les liens très intéressants.

Je suis entièrement d'accord. Mais plus je peux protéger mon instance, plus je garantie une qualité de production.
En tout cas merci pour le retour.