Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à toutes et à tous,
Je commence à appréhender Postgres et ses procédures de sauvegarde / restauration.
Jusqu'à présent, je me contentais d'un simple dump logique mais plus j'avance dans la documentation, plus je me rends compte que cela est insuffisant et que Postgres propose bien plus que ça.
Sur la base de l'image Docker officielle, je suis en train d'écrire des scripts permettant de récupérer une sauvegarde de base ainsi que les fichiers WAL détenus dans un bucket S3 au lancement du container.
Ensuite, via CRON, je compte créer de nouvelles sauvegardes de base, déposées sur ce même bucket S3, de même pour les fichiers WAL via archive_command.
Je compte garder autant de sauvegarde de base que je le peux, en conservant la dernière sauvegarde dans latest.tar.gz et YYYY-MM-DD.tar.gz .
A chaque nouvelle sauvegarde, je viens remplacer latest.tar.gz
Je n'ai pas prévu de créer une arborescence de dossier daté dans le bucket, sauf si Postgres me le contraint.
Lorsque le container démarre, je regarde si un fichier latest.tar.gz existe, le ramène en local si c'est le cas et l'intègre dans $PGDATA.
Je regarde ensuite si des fichiers WAL sont présent, je les ramène également et les intègre dans $PGDATA\pg_wal
Dans ce contexte, je peux avoir des WAL antérieur à la sauvegarde de base.
Ma question porte justement sur la gestion de ces fichiers WAL antérieurs à la sauvegarde de base :
- Est-ce que je me dois de les exclure ?
- Est-ce que Postgres identifie ces WAL et les ignore ?
N'hésitez pas à me dire si cette procédure vous parait alambiquée, dangereuse ou ne respectant pas les "bonnes pratiques".
Aussi, je précise que même s'il existe des outils permettant de simplifier les processus de sauvegarde / restauration, je préfère réaliser un PoC sur du Postgres "nature", sans outils tiers afin de bien en comprendre leur nécessité.
D'avance, je vous remercie pour vos réponse.
Cordialement,
Cauriel
Dernière modification par cauriel (31/10/2020 16:41:32)
Hors ligne
Vous n'êtes pas obligé de les exclure. PostgreSQL va les ignorer. Il sait à partir de quel fichier il doit commencer le rejeu grâce aux fichiers backup_label et pg_control.
Je pense que c'est une excellente idée d'apprendre à faire une sauvegarde et une restauration PITR "à la main", pour comprendre comment cela fonctionne (et donc savoir se débrouiller en cas de problèmes). Je pense aussi que ce serait une grosse erreur de faire son script maison de sauvegarde et qu'il est très fortement préférable d'utiliser un des outils tiers déjà disponibles.
Guillaume.
Hors ligne
Bonjour,
Merci pour votre réponse Gleu, c'est bien ce que je pensais sans en avoir trouvé la trace dans la documentation, je suis certainement passé à côté.
Je passe donc le thread en résolu 
Je pense aussi que ce serait une grosse erreur de faire son script maison de sauvegarde et qu'il est très fortement préférable d'utiliser un des outils tiers déjà disponibles.
Oui, assez d'accord.
Hormis de petites bases personnelles, je ne compte pas sauvegarder d'environnement de production via ce genre de script.
Hors ligne
Pages : 1
