DEV Community

ZINSOU Trinité
ZINSOU Trinité

Posted on

Configurer des sauvegardes incrémentales avec PostgreSql - Restauration (Partie 3)

#postgres #backup #database

🧭 Introduction

Mettre en place des sauvegardes, c’est essentiel. Mais savoir les restaurer efficacement en cas de besoin, c’est encore plus crucial. C’est ici que le PITR (Point In Time Recovery) entre en jeu, une fonctionnalitĂ© puissante offerte par PostgreSQL et parfaitement gĂ©rĂ©e par Barman.

Que ce soit pour corriger une erreur humaine, revenir avant un dĂ©ploiement ratĂ© ou analyser l’état de la base Ă  un instant prĂ©cis, Barman permet de ramener PostgreSQL dans le passĂ©, en rejouant uniquement les modifications jusqu’à un point bien dĂ©fini.

Dans ce chapitre, nous allons explorer :

  • Ce qu’est concrĂštement le PITR,

  • Les prĂ©requis pour qu’il fonctionne,

  • Et surtout, comment l’utiliser pas Ă  pas avec Barman, de maniĂšre fiable.

PrĂȘt Ă  voyager dans le temps avec PostgreSQL ? C’est par ici 👇

đŸ•°ïž C’est quoi le PITR (Point-In-Time Recovery) ?

Le Point-In-Time Recovery, ou PITR, est une fonctionnalité puissante de PostgreSQL qui permet de restaurer une base de données à un instant précis dans le passé.

C’est un peu comme une machine Ă  remonter le temps đŸ•łïžđŸ•’.

Imaginons qu’un bug ou une erreur humaine ait corrompu des donnĂ©es ce matin Ă  10h30. GrĂące au PITR, vous pouvez restaurer la base exactement comme elle Ă©tait Ă  09h29, juste avant le problĂšme.

Pour que cela fonctionne, PostgreSQL enregistre toutes les Ă©criture sur la base de donnĂ©es dans des fichiers appelĂ©s WALs (Write Ahead Logs). Ces fichiers contiennent l’historique des modifications apportĂ©es Ă  la base.

Barman exploite ces fichiers pour rejouer l’histoire de la base jusqu’à l’instant choisi, Ă  partir d’une sauvegarde complĂšte. Il effectue ainsi un rĂ©tropĂ©dalage jusqu’à un instant dĂ©sirĂ© bien pris en compte par les sauvegardes existantes

🎯 RPO et RTO : Les deux piliers d’une bonne stratĂ©gie de sauvegarde/restauration

Quand on parle de continuitĂ© d’activitĂ© et de plan de reprise aprĂšs sinistre (disaster recovery), deux notions sont essentielles Ă  comprendre avant mĂȘme de parler de sauvegarde ou d’outil comme Barman :

📌 Recovery Point Objective (RPO)

Le RPO, ou objectif de point de reprise, reprĂ©sente la quantitĂ© maximale de donnĂ©es que l'on peut se permettre de perdre en cas d’incident.

👉 Exemple :

Si vous acceptez de perdre au maximum 5 minutes de données, votre RPO est de 5 minutes. Cela implique que vos sauvegardes (ou la capture de vos WAL) doivent se faire au moins toutes les 5 minutes.

⏱ Recovery Time Objective (RTO)

Le RTO, ou objectif de temps de reprise, dĂ©signe la durĂ©e maximale acceptable d’indisponibilitĂ© du service aprĂšs un incident.

👉 Exemple :

Si vous estimez qu’une interruption de service de 30 minutes est tolĂ©rable, alors votre RTO est de 30 minutes. Cela implique que vos outils et mĂ©canisme de restauration (comme Barman et les automatisations que vous mettrez en place) doivent ĂȘtre capables de restorer et remettre le service en ligne dans ce dĂ©lai.

⚖ Trouver le bon Ă©quilibre entre idĂ©al et rĂ©alitĂ©

On aimerait tous avoir un RPO = 0 (aucune perte de donnĂ©es) et un RTO = 0 (aucun temps d’arrĂȘt).

Mais dans la vraie vie, il faut souvent faire un compromis entre le coût et la criticité du service.

Par exemple :

  • Pour un site vitrine, un RPO/RTO de plusieurs heures peut ĂȘtre tolĂ©rĂ©.

  • Pour une application bancaire, chaque seconde compte : le RPO/RTO doit ĂȘtre quasi nul.

💡 RPO et RTO avec PostgreSQL et Barman

Bonne nouvelle : avec un stack open source bien configurĂ©, il est possible de s’approcher de trĂšs bonnes performances :

  • RPO = 0 🎯

    GrĂące Ă  la rĂ©plication en streaming synchrone de PostgreSQL, vos donnĂ©es peuvent ĂȘtre protĂ©gĂ©es sans perte.

  • RTO minimal ⏱

    En combinant Barman pour les sauvegardes et repmgr pour la haute disponibilité, on peut atteindre un redémarrage quasi instantané en cas de problÚme.

🧰 PrĂ©requis pour une restauration avec PITR

Avant de tenter une restauration point-in-time, quelques Ă©lĂ©ments doivent ĂȘtre en place pour que tout se passe bien :

1. Sauvegarde valide disponible

Vous devez avoir au moins une sauvegarde complÚte dans Barman. Elle servira de point de départ pour la restauration.

2. Archivage WAL activé

Le PITR repose sur la capacitĂ© Ă  rejouer les WAL (Write Ahead Logs) jusqu’à un instant prĂ©cis. Assurez-vous que l’archivage fonctionne correctement et que les fichiers sont bien prĂ©sents dans le rĂ©pertoire wals de Barman.

3. Espace disque suffisant

La restauration va crĂ©er une nouvelle copie de la base. Il est essentiel d’avoir suffisamment d’espace libre sur le serveur cible.

4. Horodatage ou XID de restauration

Pour déclencher un PITR, vous devez spécifier le point de restauration, soit :

* une date/heure ('2025-04-11 16:00:00'),

* un identifiant de transaction (XID),

* ou simplement la fin de la sauvegarde (si vous ne rejouez pas les WAL).

5. Environnement de test (optionnel mais recommandé)

Avant de lancer une restauration en production, il est fortement conseillé de tester la restauration dans un environnement isolé.

🔄 RĂ©cupĂ©ration des donnĂ©es avec Barman (cas pratique)

Nous allons crĂ©er une table au niveau de notre base de donnĂ©es test et faire plusieurs manipulations afin d’éprouver notre systĂšme de sauvegarde.On va donc ajouter une table Ă  notre base de donnĂ©es et y ajouter quelques lignes(tu peux te servir de ce script😉):

--- creation d'une table articles
CREATE TABLE articles (
  id SERIAL PRIMARY KEY,
  title TEXT,
  content TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

--- insertion de 20 lignes dans la table articles

INSERT INTO articles (title, content)
SELECT
  'Titre de l’article ' || i,
  'Lorem ipsum dolor sit amet, consectetur adipiscing elit. 
   Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. 
   Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.'
FROM generate_series(1, 20) AS s(i);
Enter fullscreen mode Exit fullscreen mode

A cette Ă©tape on va refaire une sauvegarde incrĂ©mentale de notre base donnĂ©e avant de simuler un incident, une suppression involontaire de donnĂ©es par exemple toujours Ă  l’aide de la commande barman backup pg(ici pg est le nom de notre serveur de base de donnĂ©es dans notre configuration barman), voici le retour Ă  mon niveau:

# sur le serveur barman
$ barman backup pg
Starting backup using rsync-concurrent method for server pg in /var/lib/barman/pg/base/20250415T201516
Backup start at LSN: 0/14000028 (000000010000000000000014, 00000028)
Starting backup copy via rsync/SSH for 20250415T201516
Copy done (time: 2 seconds)
Asking PostgreSQL server to finalize the backup.
Backup size: 38.9 MiB. Actual size on disk: 4.8 MiB (-87.55% deduplication ratio).
Backup end at LSN: 0/14000100 (000000010000000000000014, 00000100)
Backup completed (start time: 2025-04-15 20:15:16.336556, elapsed time: 4 seconds)
Processing xlog segments from file archival for pg
    000000010000000000000013
    000000010000000000000014
    000000010000000000000014.00000028.backup
Enter fullscreen mode Exit fullscreen mode

Note bien la date de fin de sauvegarde (start time+ temps ecoulé ou accesible avec barman show-backup pg id_backup ). Elle te servira de référence pour définir ton --target-time lors de la restauration.A présent simulons la perte de données:

--- suppression des articles d'id pairs
DELETE FROM articles WHERE id % 2 = 0;

--- vérifier que les éléments ont bien été supprimés
SELECT COUNT(id) FROM article; 

/*
--------------------------------------------
                OUTPUT
--------------------------------------------
*/
 count 
-------
    10
(1 row)
Enter fullscreen mode Exit fullscreen mode

đŸ’„ Tous les articles avec un identifiant pair etant dĂ©sormais supprimĂ©s (cet incident intervient peu de temps aprĂšs ma derniĂšre sauvegarde). C’est le moment idĂ©al pour utiliser la rĂ©cupĂ©ration incrĂ©mentale et revenir Ă  l’état initial. Avant de restorer nos donnĂ©es nous allons refaire une nouvelle sauvegarde et arreter notre serveur postgresql:

# sur le serveur barman
$ barman backup pg
Starting backup using rsync-concurrent method for server pg in /var/lib/barman/pg/base/20250415T201754
Backup start at LSN: 0/17000028 (000000010000000000000017, 00000028)
Starting backup copy via rsync/SSH for 20250415T201754
Copy done (time: 2 seconds)
Asking PostgreSQL server to finalize the backup.
Backup size: 38.9 MiB. Actual size on disk: 129.7 KiB (-99.67% deduplication ratio).
Backup end at LSN: 0/17000100 (000000010000000000000017, 00000100)
Backup completed (start time: 2025-04-15 20:17:55.167843, elapsed time: 4 seconds)
Processing xlog segments from file archival for pg
    000000010000000000000016
    000000010000000000000017
    000000010000000000000017.00000028.backup

$ barman list-backup pg
pg 20250415T201754 - Tue Apr 15 20:17:58 2025 - Size: 54.9 MiB - WAL Size: 0 B
pg 20250415T201516 - Tue Apr 15 20:15:19 2025 - Size: 54.9 MiB - WAL Size: 48.0 MiB
pg 20250413T113210 - Sun Apr 13 11:32:14 2025 - Size: 54.8 MiB - WAL Size: 32.0 MiB

# sur le serveur postgres
$ sudo service postgresql stop
Enter fullscreen mode Exit fullscreen mode

A cette Ă©tape deux sauvegardes encadren notre incident, celles d’ids 20250415T201516 et 20250415T201754. La premiĂšre est celle avec d’avant incident qui nous servira donc pour notre PITR.

La commande de restoration Ă  taper sur le serveur barman est la suivante:

$ barman recover --remote-ssh-command "ssh postgres@192.168.58.11" --target-time="2025-04-15 20:17:58.270833+00:00" pg 20250415T201754 /var/lib/postgresql/12/main
Starting remote restore for server pg using backup 20250415T201754
Destination directory: /var/lib/postgresql/12/main
Remote command: ssh postgres@192.168.58.11
Doing PITR. Recovery target time: '2025-04-15 20:17:58.270833+00:00'
Using safe horizon time for smart rsync copy: 2025-04-15 20:17:54.690087+00:00
Copying the base backup.
Copying required WAL segments.
Generating recovery configuration
Identify dangerous settings in destination directory.

IMPORTANT
These settings have been modified to prevent data losses

postgresql.conf line 755: archive_command = false

WARNING
You are required to review the following options as potentially dangerous

postgresql.conf line 41: data_directory = '/var/lib/postgresql/12/main'     # use data in another directory
postgresql.conf line 43: hba_file = '/etc/postgresql/12/main/pg_hba.conf'   # host-based authentication file
postgresql.conf line 45: ident_file = '/etc/postgresql/12/main/pg_ident.conf'   # ident configuration file
postgresql.conf line 49: external_pid_file = '/var/run/postgresql/12-main.pid'          # write an extra PID file
postgresql.conf line 66: unix_socket_directories = '/var/run/postgresql'    # comma-separated list of directories
postgresql.conf line 102: ssl_cert_file = '/etc/ssl/certs/ssl-cert-snakeoil.pem'
postgresql.conf line 104: ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
postgresql.conf line 740: include_dir = 'conf.d'            # include files ending in '.conf' from

Recovery completed (start time: 2025-04-16 15:14:41.903013, elapsed time: 8 seconds)

Your PostgreSQL server has been successfully prepared for recovery!
Enter fullscreen mode Exit fullscreen mode

Les options de cette commande sont: --remote-ssh-command une commande ssh vers le serveur postgres, --target-time la date Ă  laquelle restorĂ©e les donnĂ©es qui doit etre xxxxxxxxxxxxxx, server_name pour le nom du serveur, backup_id le nom du backup et destination_directory pour le dossier qui doit accepter les sauvegardes. Tu pourrais avoir plus d’options avec barman recover -h.

La recupĂ©ration peut se faire dans n’importe quel dossier Ă  part celui de base de postgres Ă  condition de reconfiguer postgres pour pointer sur le dossier considĂ©rĂ©. On peut aprĂšs avoir Ă  nouveau accĂšs Ă  nos donnĂ©es rĂ©cupĂ©rĂ©es:

--- vérifier que les éléments ont bien été supprimés
SELECT COUNT(id) FROM article; 

/*
--------------------------------------------
                OUTPUT
--------------------------------------------
*/
 count 
-------
    20
(1 row)
Enter fullscreen mode Exit fullscreen mode

🏁 Conclusion

Les erreurs humaines, les corruptions logicielles ou les incidents matériels ne sont pas une question de "si", mais de "quand". Dans ce contexte, la capacité à revenir à un état antérieur précis de ta base PostgreSQL est essentielle.

Avec Barman et la fonctionnalitĂ© de Point-In-Time Recovery (PITR), tu disposes d’un outil fiable, robuste et puissant pour rĂ©pondre aux impĂ©ratifs de continuitĂ© d’activitĂ©. En combinant les sauvegardes complĂštes aux fichiers WAL archivĂ©s, tu peux restaurer ta base Ă  la seconde prĂšs, juste avant un incident.

Plus encore, tu l’as vu : ce processus peut s’automatiser, se tester, s’industrialiser; autant d’atouts pour renforcer la rĂ©silience de ton architecture PostgreSQL.

Top comments (0)