muppy.io
  • ⛏️Qu'est ce que muppy.io ?
  • ⚒️Concepts Muppy
  • Quickstarts
    • ✏️Introduction
  • Guides
    • ⛏️Muppy Core
      • Hosts
        • Création et enrôlement d'un Host
          • ✏️Server Types
          • ✏️Configuration réseaux spécifiques
        • ⚒️Host's Users
        • ⚒️Host's Network information
        • ⚒️Host's Metrics
      • Tasks et Fact Collectors
        • ⚒️Exécution des Tasks (Task Runs)
          • ⚒️Exécution asynchrone des Tasks (Launch as Job)
        • ⚒️Synchronisation des Tasks et Scripts
        • ⚒️Liste des Scripts
        • ⚒️Liste des Tasks
        • ⚒️Création de Task "Shell Script"
        • ⚒️Liste des Fact Definitions
      • ⛏️Firewall UFW
        • Désactiver UFW globalement
        • ✏️Page 1
      • SSH Keys
        • Gestion des SSH Keys
        • Gestion des "authorized_keys"
        • Extraction Clef Privée d'un User User
      • ⚒️Systemd Service Units
        • ⚙️Liste des Systemd Units
        • ➕Création de Systemd Units
        • 📰Systemctl status et log
        • ✏️Edition des Systemd Units
    • 🐘PostgreSQL
      • PostgreSQL Base
        • Installation de PostgreSQL
        • Gestion des Clusters
          • Création
          • Configuration
          • Contrôle
          • Administration (basique)
        • Backup, Restore et Copy de Databases
          • Databases Backups (pg_dump)
          • PostgreSQL Backup
          • pg_dump Restore
          • Database Copy
          • pg_restore Callback Task
        • Backups Planifiés
        • Gestion rétention des Backups
      • PostgreSQL Replication
        • Créer un RCS
        • Visualiser un RCS
        • Suivre la Replication
        • Ajouter des Standbys
        • Restructurer un RCS
        • Intégration d'un RCS
        • Reconfigurer un RCS
      • PostgreSQL HA
        • Configuration
        • Activation et Désactivation
        • Monitoring
        • pglookout Heartbeat
      • PostgreSQL PITR
        • Configuration de WAL-G
        • Lancement des Clusters Backups
        • Liste des Clusters Backups (WAL-G)
        • Purge des fichiers de Backup PITR
        • Monitoring du PITR
        • Objets S3 stockés par WAL-G
        • Restauration PITR
      • PostgreSQL Tools
        • pgBadger - log analysis
    • Muppy Pack
      • ⛏️Packs
      • Concepts
      • ⛏️Muppy Cluster
        • Cluster Security
        • PostgreSQL Cluster Resources
      • ⛏️Reverse Proxy
    • ✏️Configuration
      • 👫Gestion des Users Muppy
      • 🏬S3 Buckets
      • 💬Notifications Teams
      • ✏️Notifications Slack
    • ⛏️Odizy
      • Odizy Workflow
        • Test Servers
      • Accéder à vos serveurs
      • Restaurer un backup sur le serveur de staging
      • Activer un serveur Standby
      • ⛏️Configuration LXC CI/CD
      • Activate and Launch remote Code-Server (VS Code from coder.com)
    • ⚒️Kubernetes
      • ⚒️Installer Tailscale
      • ⚒️Installer un cluster microk8s
      • ⚒️Installer PostgrSQL
      • ⚒️Installer les packages d'infrastructures
  • 📡Muppy Enterprise
    • Introduction
    • ⛏️Configuer une Instance Muppy Enterprise
    • 🌡️Monitoring Muppy Enterprise
  • ⛏️Work in progress
    • ⛏️Code Server
    • ⛏️Muppy Development Servers
      • Move Development Server
Powered by GitBook
On this page
  • Purge à partir du serveur PostgreSQL
  • Application de la Configuration
  • Purge à partir de Muppy (via une Muppy Task)
  • Mise en oeuvre
  1. Guides
  2. PostgreSQL
  3. PostgreSQL PITR

Purge des fichiers de Backup PITR

PreviousListe des Clusters Backups (WAL-G)NextMonitoring du PITR

Last updated 3 years ago

WAL-G dispose de commandes permettant de purger les Clusters Backups et WAL Segments liés.

Muppy permet de mettre en oeuvre la purge de 2 manières:

  • A partir du serveur qui héberge le Cluster PostgreSQL sur lequel le PITR est configuré.

  • A partir de Muppy, via une Muppy Task configurée avec un CRON (Préconisation Muppy)

Purge à partir du serveur PostgreSQL

La configuration de la purge est expliquée dans le paragraphe de la page Lancement des Clusters Backups.

Cette configuration de la purge pose le même problème que les backups. Muppy n'est pas informé des backups purgé et vous devez créer exécuter périodiquement une Task d'actualisation des Cluster Backups comme décrit dans .

Le groupe de paramètres Full Backups Configuration présent dans l'onglet Backup / WAL-G du formulaire des Database Clusters permet de planifier la Purge des fichiers de backup quand elle est exécutée à partir du Database Cluster.

Dans ce cas, les commandes de purge de WAL-G sont lancées via le CRONTAB du user postgres.

Lorsque vous cochez Activate WAL-G in CRONTAB, Muppy affiche les groupes de paramètres suivants:

  1. Ces 4 paramètres permettent de:

    • Définir le nombre de Backups et fichiers WAL à conserver ou de désactiver la purge via le CRONTAB si la valeur est 0

  2. Le fichier CRONTAB avec son timestamp collecté à l'issue de la dernière reconfiguration par Muppy. Si la purge est activée, le CRONTAB contient une ligne avec la commande 'delete retain ...'

Muppy n'écrase pas le CRONTAB du user postgres mais injecte un bloc contenant les commandes nécessaires à la purge des Backups WAL-G (Cf. figure précédente).

Ce bloc est généré par un fichier Template Muppy qui est défini avec le paramètre CRONTAB Template.

Le template est utilisé pour planifier les backups et la purge.

Application de la Configuration

Purge à partir de Muppy (via une Muppy Task)

Notre recommandation est d'utiliser une Muppy Task planifiée pour lancer la purge des fichiers de backups générés pas WAL-G.

L'utilisation d'une Muppy Task permet:

  • de pouvoir recevoir des notifications en cas d'erreur et/ou de succès de la purge

  • de disposer des logs d'exécution

  • d'avoir une liste des Cluster Backups (WAL-G) à jour

La Muppy Task walg_backup_delete purge les fichiers de backups et actualise la liste des Clusters Backups (WAL-G) à l'issue de la purge.

Mise en oeuvre

Créez un Task Run avec les paramètres suivants (Cf. figure suivante) :

  1. La Muppy Task walg_backup_delete

  2. Le Host qui héberge le Cluster PostgreSQL dont vous souhaitez purger les backups

  3. Le PostgreSQL Database Cluster dont vous souhaitez purger les backups

  4. Le nombre de Cluster Backups (WAL-G) (et WAL Segments) à conserver (La valeur par défaut est 20).

  5. Par défaut (confirm non coché) la purge est exécutée en mode Dry Run et aucun fichier n'est effacé. Si vous cochez confirm, les fichiers seront effacés.

A l'issue de l'exécution, la Task renvoie un json (#7 sur le schéma suivant) qui contient:

  • data: les lignes renvoyées par la commande sur la console (stdout)

  • walg_backup_list_result: la liste des Cluster Backups actualisée à l'issue de la purge.

En mode Dry Run (confirm=False), le contenu de walg_backup_list_result contient toujours les fichiers de Backups qui n'ont pas été supprimés !

Planifier l'exécution des Purges en indiquant les paramètres heures, minutes et "jour de la semaine" d'une ligne de CRON (Voir )

Une fois que vous avez configuré ou modifié la configuration des Full Backups, cliquez sur le bouton pour mettre à jour le CRONTAB afin d'activer et configurer ou désactiver la purge des fichiers de backups en fonction du paramètre Nb. of Cluster Backups to keep.

Lorsque la purge est réalisée directement via un CRON sur le serveur PostgreSQL, Muppy n'a pas connaissance des backups purgés. La liste des backups doit donc être mise à jour comme indiqué dans le paragraphe

Utilisez le bouton pour planifier l'exécution périodique de la purge

🐘
https://crontab.guru/
Actualisation de la liste des Clusters Backups
Actualisation de la liste des Clusters Backups
Configuration de la purge des fichiers de backup WAL-G à partir du serveur PostgreSQL
Example de Task Run de Purge des Backups et WAL Segments
Lancement via CRONTAB du user postgres