pgBackRest : sauvegarde PostgreSQL et PITR sérieux

Le scénario revient à chaque audit. Une base PostgreSQL de plusieurs centaines de gigaoctets, un cron qui lance pg_dump toutes les nuits, et la conviction tranquille que la sauvegarde est faite. Puis on pose deux questions. Combien de temps prend le dump quand la base est sous charge ? Et surtout : à quel moment peut-on restaurer ? La réponse à la seconde glace le sang : à hier minuit, au mieux, en perdant tout ce qui a été écrit depuis. Si l'incident tombe à 17 h, c'est dix-sept heures de transactions évaporées.

pg_dump produit une sauvegarde logique : un export SQL cohérent à l'instant où il démarre. Pratique pour migrer une base, dupliquer un schéma, sortir une table. En production sérieuse, c'est insuffisant pour trois raisons. Il s'exécute dans une transaction longue qui peut gêner le vacuum sur une base active, un effet de bord que détaille tout travail d'optimisation des performances PostgreSQL, il ne capture qu'un instant figé donc votre RPO (Recovery Point Objective) ne descend jamais sous la fréquence du dump, et restaurer une grosse base depuis un dump SQL signifie rejouer chaque INSERT et reconstruire chaque index, ce qui se compte en heures. La sauvegarde physique répond à ces trois points, et pgBackRest est l'outil qui la fait proprement.

Une sauvegarde physique copie les fichiers de données de PostgreSQL tels qu'ils sont sur le disque, pas une représentation logique. pgBackRest gère trois types de backup qui s'enchaînent. Le full copie l'intégralité du répertoire de données, c'est la base de tout. Le differential ne copie que ce qui a changé depuis le dernier full. L'incremental ne copie que ce qui a changé depuis le dernier backup, quel que soit son type.

La vraie avancée, c'est l'incrémental par blocs (block incremental), introduit en version 2.46. Au lieu de recopier un fichier entier dès qu'un octet bouge, pgBackRest ne stocke que les blocs modifiés à l'intérieur du fichier, regroupés en super blocs compressés et chiffrés qu'on peut récupérer indépendamment. Sur les patterns OLTP où les écritures se concentrent sur quelques grosses tables, le gain est massif : la doc Crunchy Data montre un backup incrémental de 943 Ko avec block incremental activé, contre 52,8 Mo sans, soit un facteur 50 sur la taille. Un garde-fou quand même : éviter les longues chaînes de block incremental, qui dégradent les performances de restauration. La discipline reste un full régulier qui borne la chaîne.

À tout ça s'ajoutent les fonctions qui font la différence à l'échelle : compression intégrée (lz4, zstd, gzip), parallélisme sur le backup comme sur le restore, chiffrement client, et une politique de rétention qui expire automatiquement les vieux backups. Sur une base multi-téraoctets, le parallélisme à lui seul réduit la fenêtre de sauvegarde de moitié ou plus par rapport à une approche séquentielle. pgBackRest sait aussi prendre le backup depuis un standby, ce qui décharge le primary de l'I/O de sauvegarde, un atout direct sur une stack PostgreSQL haute disponibilité avec Patroni où les replicas sont déjà là.

Le backup de base n'est que la moitié du dispositif. L'autre moitié, c'est l'archivage continu des WAL (Write-Ahead Log), le journal où PostgreSQL écrit chaque modification avant de l'appliquer. PostgreSQL pousse chaque segment WAL terminé vers le dépôt via le paramètre archive_command, et pgBackRest l'archive à côté des backups de base.

La configuration côté postgresql.conf tient en deux lignes :

archive_mode = on
archive_command = 'pgbackrest --stanza=prod archive-push %p'

Ce flux WAL continu débloque le Point-In-Time Recovery, le PITR. Au lieu de ne pouvoir restaurer qu'à l'instant d'un backup, on restaure le dernier full puis on rejoue les WAL jusqu'à un point précis : un horodatage, un identifiant de transaction, un LSN. Concrètement, on remonte la base à l'état d'avant le DROP TABLE malheureux de 14 h 32, en perdant zéro transaction des autres tables. C'est exactement le mécanisme de récupération continue documenté par PostgreSQL, et c'est lui qui fait passer un RPO de plusieurs heures à quelques secondes.

La restauration PITR se déclare au moment du restore :

pgbackrest --stanza=prod \
  --type=time --target="2026-07-12 14:30:00" \
  restore

Restaurer une base de plusieurs téraoctets en repartant de zéro, c'est long, et pendant ce temps le service est à terre. Le restore delta change la donne. Avec l'option --delta, pgBackRest compare ce qui est déjà présent sur le disque avec le contenu du backup en s'appuyant sur les checksums, supprime les fichiers absents du backup, laisse en place ceux qui correspondent, et ne restaure que le reste. Sur un cluster où une partie des données est intacte, on ne recopie que le différentiel, pas l'intégralité.

Couplé au block incremental, l'effet est net : la même doc Crunchy Data mesure un restore delta qui ne recopie que 3,5 Mo du fichier de table principal, contre 30,4 Mo sans la fonction, parce qu'on récupère des blocs individuels au lieu de fichiers entiers. Sur un dépôt distant à forte latence comme S3, ce gain est encore plus marqué : moins de données à transférer, restauration plus rapide, RTO (Recovery Time Objective) qui fond.

Reste le point que tout le monde repousse : la vérification. pgBackRest calcule un checksum pour chaque fichier du backup et les revérifie au restore comme avec la commande verify, et il valide les checksums de page de PostgreSQL pendant le backup quand ils sont activés. Mais un checksum vert ne prouve qu'une chose : le fichier n'est pas corrompu. Il ne prouve pas que la base remonte, que l'application repart, que vos données métier sont cohérentes. Ça, seule une restauration jouée en condition réelle le prouve. La règle qu'on applique : un restore complet sur un environnement isolé à intervalle régulier, chronométré, avec validation applicative. Un backup jamais restauré n'est pas une sauvegarde, c'est une supposition, exactement la même discipline que pour un plan de reprise d'activité éprouvé.

pgBackRest gère plusieurs dépôts en parallèle, et c'est la base d'une stratégie sérieuse. La configuration classique : un dépôt local rapide pour les restaurations courantes, un dépôt distant sur object store (S3, Azure, GCS, SFTP) pour la copie hors site. Le même backup part vers les deux, vous avez une copie proche pour le RTO et une copie distante pour survivre à la perte du site.

Sur l'object store, activez l'immuabilité : un bucket avec object lock en mode compliance interdit la suppression et la modification d'un objet pendant la durée de rétention définie, y compris par un compte compromis. C'est la protection concrète contre le ransomware, qui cible en priorité les sauvegardes avant de chiffrer la prod. Un backup qu'un attaquant peut effacer n'est pas une sauvegarde de sécurité. La même logique d'immuabilité vaut côté infra, qu'il s'agisse de BorgBackup pour sauvegarder PostgreSQL sur des dépôts append-only ou d'un stockage objet S3 piloté par restic et rclone. Le principe est constant : la sauvegarde doit survivre à la compromission de ce qu'elle protège.

Sur le plan technique, le face-à-face est tranché. pgBackRest, écrit en C, vise la vitesse brute avec son parallélisme et son incrémental par blocs ; sur les bases volumineuses à fenêtre de sauvegarde serrée, il garde l'avantage. Barman, écrit en Python et porté par EDB, est pensé pour la sauvegarde centralisée à distance de plusieurs serveurs et fait de l'incrémental au niveau fichier, moins fin que les blocs de pgBackRest.

Le projet, lui, a traversé une alerte sérieuse au printemps 2026, et l'histoire mérite d'être racontée parce qu'elle dit quelque chose d'important sur le choix d'un outil de sauvegarde. Le 27 avril 2026, le dépôt pgBackRest a été archivé et passé en lecture seule. Le mainteneur a cité la perte de sponsoring après la revente de Crunchy Data et l'absence de modèle de financement viable : plus de correctifs, plus de patchs de sécurité, plus de fonctionnalités. Pendant quelques semaines, miser sur l'outil pour un nouveau déploiement était effectivement un pari risqué.

Sauf que l'écosystème PostgreSQL a réagi. Le 18 mai 2026, le développement a repris, financé cette fois par une coalition de sponsors (AWS, Supabase, pgEdge, Tiger Data, Percona en coordination et Eon) plutôt que par un acteur unique. David Steele, créateur et mainteneur principal, est revenu sur le projet. Le choix du modèle multi-sponsors est délibéré : qu'un rachat ou le retrait d'une seule entreprise ne puisse plus casser la continuité, ce qui était précisément la faille de l'épisode précédent. pgBackRest est de nouveau maintenu et redevient un choix par défaut solide en 2026.

La leçon ne s'efface pas pour autant. Un projet open source critique porté par un seul sponsor est fragile, et l'archivage d'avril l'a démontré en grandeur réelle. Ce qui compte au moment de poser le dernier rempart d'une base de prod, c'est moins la qualité technique d'un outil à un instant donné que la robustesse de sa gouvernance dans la durée. Le retour de pgBackRest sous gouvernance multi-sponsors est exactement la garantie qu'on cherche.

Pour un parc PostgreSQL existant qui tourne déjà sous pgBackRest, rien ne bouge : l'outil fait le job, le full plus diff quotidien plus archivage WAL continu reste une stratégie solide, et la restauration testée prime sur le nom de l'outil.

Pour un nouveau dispositif en 2026, pgBackRest redevient un défaut recommandable : performance brute, incrémental par blocs, et désormais une gouvernance multi-sponsors qui sécurise la continuité. Barman garde son terrain quand on veut piloter la sauvegarde de plusieurs serveurs depuis un hôte de backup dédié. Le réflexe à conserver dans tous les cas : avant d'adosser le dernier rempart d'une base de prod à un outil, on regarde son modèle de gouvernance autant que ses qualités techniques. C'est ce qui sépare un choix solide d'un pari.

Et quel que soit l'outil, le seul critère qui compte ne change pas : un RPO faible exige un archivage WAL continu, et une sauvegarde n'existe que si sa restauration a été jouée en condition réelle, chronométrée, validée. Le reste, c'est de la configuration. Si vos backups Postgres n'ont pas été restaurés pour de vrai depuis six mois, vous ne savez pas s'ils valent quelque chose.

Quand un audit révèle une stratégie de sauvegarde Postgres rafistolée, dumps logiques en guise de PRA et restauration jamais testée, on reprend tout : type de backup, archivage WAL, rétention, immuabilité de l'object store, PITR éprouvé, RPO et RTO contractualisés. C'est ce qu'on fait au quotidien sur les bases qu'on opère. Si votre dispositif de sauvegarde tient sur de la chance, on peut auditer votre stratégie et la mettre au niveau.

• pgBackRest, guide utilisateur officiel : backup full, differential, incremental, archivage WAL, PITR, restore delta et configuration des dépôts.
• pgBackRest, référence de configuration : options de compression, chiffrement, rétention, repo multiples et restore delta par checksums.
• PostgreSQL, Continuous Archiving and PITR : mécanique officielle de l'archivage WAL continu et de la récupération à un point dans le temps.
• pgBackRest File Bundling and Block Incremental Backup, Crunchy Data : block incremental depuis la 2.46, super blocs, mesures de gain sur la taille de backup et le restore delta.
• pgBackRest, news officielle du projet : archivage du 27 avril 2026 puis reprise du développement le 18 mai 2026 sous coalition de sponsors (AWS, Supabase, pgEdge, Tiger Data, Percona, Eon).
• Backrest's back, alright !, Percona Community : refinancement du projet par une coalition multi-sponsors, retour de David Steele et logique de gouvernance résistante à un rachat unique.
• After pgBackRest, Christophe Pettus : jalon de l'épisode d'archivage d'avril 2026, écrit avant le sauvetage, recommandation de ne pas migrer dans la précipitation.