# PostgreSQL PITR ## Introduction Le PITR ou Point In Time Recovery est une technologie de Backup qui consiste à sauvegarder un Cluster PostgreSQL toutes les minutes pour être capable de le restorer à un moment précis dans le temps. {% hint style="warning" %} Le PITR qui permet de sauvegarder en continu tout un **Cluster PostgreSQL** a une granularité de fonctionnement différente des [databases-backups-pg\_dump](https://docs.muppy.io/guides/postgresql/postgresql-base/backup-restore-et-copy-de-databases/databases-backups-pg_dump "mention") qui permettent de sauvegarder ponctuellement une ou plusieurs bases de données. {% endhint %} ![Granularité PITR vs pg\_dump](https://3772830354-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJQEyyq3uo2ur4VSBiaCB%2Fuploads%2FIxHxBVeG26pKjDWRKbPf%2FWal-g%20Architecture%20Muppy%20PostgreSQLdrawio.drawio%20\(1\).png?alt=media\&token=4201c8be-0248-4d42-a7ad-2df9ffb3800b) Muppy utilise **WAL-G** ( ) pour gérer le **PITR**. Le PITR géré par Muppy fonctionne en sauvegardant le WAL (Write Ahead Log) d'un Cluster dans un dispositif de sauvegarde compatible **AWS S3**. \ AWS S3 est la seule technologie de sauvegarde supportée actuellement par Muppy. La fréquence des sauvegardes étant la minute, les volumes sauvegardés sont conséquents. Muppy active la compression des WAL par défaut. Malgré tout, le volume des sauvegardes PITR peut facilement atteindre des centaines de Go par jour sur des bases actives. En préalable à la mise en place du PITR, vous devez donc disposer d'un **Bucket S3** correctement configuré dans Muppy (voir [s3-buckets](https://docs.muppy.io/guides/configuration/s3-buckets "mention") ). {% hint style="info" %} Le **PITR** est indépendant de la **Replication**. Vous pouvez donc l'utiliser même si vous n'avez qu'un seul **Cluster PostgreSQL**. {% endhint %} ## Le PITR est un backup incrémental Le PITR est une technologie de backup incrémental ; toutes les minutes wal-g sauvegarde les modifications réalisées dans la minute écoulée dans un fichier que nous appellerons **"WAL Segment"**. Le processus de restauration "PITR" nécessite de disposer d'une sauvegarde initiale complète ; un "full backup" que nous appellerons **base backup** ou **Cluster Backup (WAL-G).** Les **Clusters Backups WAL-G** sont restaurés au début de la restauration et servent de base sur laquelle tous les **WAL Segments** (contenant 1 minute de modifications) sont restaurés. La durée de la restauration est strictement proportionnelle au nombre de **WAL Segment** à restaurer. Par exemple, si vous faites un **WAL-G Cluster Backup** hebdomadaire, en cas de restauration, vous pourrez être amené à restaurer une semaine soit environ 10 000 WAL Segments. Inversement, si vous faite un **WAL-G Cluster Backup** quotidien, vous aurez beaucoup moins de WAL Segments à restaurer, mais vous devez prévoir et évaluer l'impact en performance de l'exécution du **WAL-G Cluster Backup** sur vos applications. {% hint style="warning" %} En conclusion, la fréquence des **WAL-G Cluster Backup** est le paramètre clef du PITR. {% endhint %} ## Mise en oeuvre du PITR La mise en oeuvre du PITR passe par les étapes suivantes: * Configuration de WAL-G pour activer les backups des WAL Segments toutes les minutes * Planification et lancement des **Clusters Backups (WAL-G)** (les bases backups) * Consultation et actualisation de la Liste des **Clusters Backups (WAL-G)** * Purge des fichiers de backup PITR * Monitoring du **PITR** * Visualisation des Objets S3 stockés par WAL-G * Restauration **PITR**