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
  • Prérequis sur le serveur cible
  • Lancement de la Restauration
  • Déroulement de la Restauration
  1. Guides
  2. PostgreSQL
  3. PostgreSQL PITR

Restauration PITR

Cette page décrit comment reconstruire un Cluster PostgreSQL à un point dans le temps avec le PITR

PreviousObjets S3 stockés par WAL-GNextPostgreSQL Tools

Last updated 3 years ago

Prérequis sur le serveur cible

Pour restaurer un Cluster PostgreSQL avec le PITR, vous devez disposer d'un serveur "cible" sur lequel le Cluster PostgreSQL va être restauré.

Comme Muppy va reconstruire complètement le Cluster, vous n'avez pas besoin d'installer de paquets ou logiciels.

La seule contrainte porte sur la configuration système du serveur cible ; celle-ci doit être identique à celle du serveur. Les partitions disques notamment doivent être strictement identiques !

La Restauration PITR commence par la restauration d'un Cluster Backup (WAL-G). Les clusters backups sont des backups "binaires" du répertoire PostgreSQL du Cluster. Pour que la restauration réussisse l'architecture du stockage doit être identique.

Le serveur cible doit être disponible dans Muppy au statut Managed.

Lancement de la Restauration

Le point de départ de la restauration est un Cluster Backup (WAL-G). Sélectionnez et ouvrez le formulaire du Cluster Backup (WAL-G) qui va servir de point de départ à la restauration et sur lequel tous les WAL vont être restaurés.

Cliquez sur le bouton situé dans le bandeau supérieur du formulaire du Cluster Backup (WAL-G), le wizard suivant apparait:

Le wizard permet de définir les paramètres de restauration suivants:

  1. Le Cluster Backup (WAL-G) qui va servir de base à la restauration des WAL

  2. Le Host sur lequel le cluster va être restauré. Comme nous l'avons déjà expliqué, il suffit que le Host soit au statut Managed et il faut que son architecture système soit identique à celle du serveur qui héberge le cluster restauré.

  3. Le moment dans le temps dont vous voulez restaurer les données. C'est le fameux PITR ! Si vous le laissez vide, le cluster sera restauré dans l'état le plus récent.

  4. Définir si vous voulez restaurer le Cluster dans l'état où il était juste avant le PITR ou juste après.

  5. S'il y a déjà un Cluster (géré par Muppy) sur le serveur cible, le wizard vous l'indiquera avec un message et ne lancera pas la restauration. Ce flag vous permet de forcer la restauration et d'écraser le Cluster existant.

  6. Définir l'état du Cluster une fois que tous les WAL ont été restaurés. Les valeurs possibles sont:

    1. Promote (défaut)

    2. Pause ; actuellement, Pause est réservée à des utilisateurs expérimentés capable de terminer la restauration manuellement.

    3. Shutdown

Tous ces paramètres font l'objet d'une documentation contextuelle relativement détaillée. N'hésitez pas à vous y référer !

Déroulement de la Restauration

Muppy génère un Message walg_restore_cluster. Ouvrez le message pour suivre l'exécution de la restauration et accéder aux logs (pensez à aller à la dernière page des logs).

La restauration PITR a une particularité. Quand l'exécution de la Task walg_restore_cluster est terminée, le Database Cluster restauré est au statut "online,recovery". Mais la restauration n'est pas terminée !!!!

Au statut "online,recovery", le Cluster PostgreSQL est en train de télécharger et d'appliquer les WAL Segments. Le Cluster est déjà disponible en lecture, mais la restauration n'est pas terminée. Elle peut durer encore plusieurs minutes, voir plusieurs heures.

Le statut "online,recovery" est aussi le statut des Clusters Standby dans un RCS. Ils sont eux-aussi en train de récupérer et appliquer des WAL Segments. La différence est la source.

A l'issue du recovery, le Cluster passe automatiquement dans l'état défini par le paramètre Recovery Target Action (#6) du PostgreSQL WAL-G Restoration Wizard. La valeur par défaut Promote permet de créer un cluster autonome au statut online.

Saisissez les paramètres et Cliquez sur le bouton pour lancer la Restauration.

Vous pouvez suivre le recovery en inspectant le log du Cluster PostgreSQL comme indiqué dans le paragraphe .

🐘
PostgreSQL WAL-G / PITR Restore Wizard
Log du Cluster PostgreSQL