PostgreSQL PITR
Muppy gère le Point In Time Recovery de vos Clusters.
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.
Le PITR qui permet de sauvegarder en continu tout un Cluster PostgreSQL a une granularité de fonctionnement différente des Databases Backups (pg_dump) qui permettent de sauvegarder ponctuellement une ou plusieurs bases de données.
.png?alt=media&token=4201c8be-0248-4d42-a7ad-2df9ffb3800b)
Granularité PITR vs pg_dump
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 ).
Le PITR est indépendant de la Replication. Vous pouvez donc l'utiliser même si vous n'avez qu'un seul Cluster PostgreSQL.
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.
En conclusion, la fréquence des WAL-G Cluster Backup est le paramètre clef 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
Last modified 1yr ago