pgBackRest n'est plus maintenu : comment auditer et faire évoluer votre stratégie de backup PostgreSQL

Source originale : After pgBackRest par Christophe Pettus — PostgreSQL expertise blog

La situation en clair

Depuis fin avril 2026, pgBackRest n'est officiellement plus maintenu. David Steele, son créateur et mainteneur principal, a cessé le développement actif du projet. Pour les équipes qui utilisent pgBackRest en production — et elles sont nombreuses — la nouvelle peut sembler alarmante. Elle mérite pourtant une réponse calme et structurée.

Commençons par l'essentiel : rien ne s'est cassé du jour au lendemain. Les binaires installés continuent de fonctionner, les dépôts git restent accessibles, et vos cron jobs ignorent totalement cet état de fait. Vous avez le temps d'analyser la situation et de prendre une décision éclairée.

Ce que vous ne devriez pas faire, en revanche, c'est attendre passivement qu'un fork communautaire émerge et prenne le relais. C'est possible à terme, mais rien de concret n'existe aujourd'hui. Planifier autour de cette hypothèse serait imprudent.

Ce que pgBackRest faisait vraiment

Avant de parler de remplacement, il faut comprendre ce qu'on cherche à remplacer. La réputation de pgBackRest repose sur une combinaison précise de fonctionnalités que peu d'outils réunissent :

• Backup parallèle sur plusieurs cœurs et connexions réseau — courant dans l'écosystème.
• Restore parallèle, y compris pour les backups incrémentaux et différentiels — beaucoup moins répandu.
• Backup incrémental au niveau bloc : pgBackRest trackait les pages de 8 Ko modifiées depuis le dernier backup et ne copiait qu'elles, pas les fichiers de relation entiers. C'est cette fonctionnalité qui rendait les incrémentaux nocturnes viables sur des clusters de plusieurs téraoctets.
• Restore delta : au lieu de vider le répertoire de données et de tout réécrire, pgBackRest comparait les blocs existants avec les blocs de sauvegarde et ne remplaçait que ce qui avait changé. Sur de gros volumes, la différence en temps de restore est considérable.
• Support multi-dépôts avec gestion fine de la rétention par dépôt.
• Chiffrement natif des backups, intégré au pipeline plutôt qu'ajouté en couche.
• Support cloud natif pour S3, Azure Blob Storage et GCS.

La question à se poser n'est pas « quel outil remplace pgBackRest » mais « quelles fonctionnalités de pgBackRest j'utilise réellement ». La réponse détermine votre stratégie de migration.

Auditer votre usage avant de choisir

Avant toute décision technique, menez un audit honnête de votre configuration actuelle. Voici les points à documenter :

1. Inventaire des fonctionnalités actives

Ouvrez votre fichier pgbackrest.conf et identifiez :

• Utilisez-vous --type=incr ou --type=diff en production ?
• Le paramètre delta est-il activé pour vos restores ?
• Avez-vous plusieurs dépôts configurés (repo1, repo2) ?
• Le chiffrement est-il activé (repo1-cipher-type) ?
• Ciblez-vous un stockage objet cloud ?

2. Évaluation des RTO/RPO réels

Reviewez vos métriques de backup :

# Vérifier l'historique des backups
pgbackrest --stanza=main info

# Mesurer la durée des derniers backups full/incr
grep 'completed' /var/log/pgbackrest/main-backup.log | tail -20

Notez les durées de backup et, si vous en avez, les durées de restore lors de vos derniers tests de reprise. Ces chiffres sont votre baseline.

3. Cartographier vos contraintes opérationnelles

• Quelle est votre fenêtre de maintenance acceptable ?
• Votre équipe maîtrise-t-elle WAL-G, Barman ou un autre outil ?
• Avez-vous des contraintes réglementaires sur le chiffrement ou la localisation des données ?

Les alternatives réalistes

Aucun outil ne remplace pgBackRest à l'identique. Chacun couvre un sous-ensemble de ses fonctionnalités.

WAL-G est aujourd'hui l'alternative la plus crédible pour les usages cloud-first. Il supporte S3, GCS et Azure, gère le chiffrement, et ses performances sur les gros volumes sont solides. Ce qu'il ne fait pas : le backup incrémental au niveau bloc et le restore delta. Sur des bases volumineuses, cela se traduit par des fenêtres de backup plus longues et des restores plus lents.

Barman (pgEdge/2ndQuadrant) est mature, bien documenté et activement maintenu. Il excelle dans les environnements multi-serveurs et propose une interface de catalogue riche. Il manque lui aussi du backup block-level natif, et sa gestion du parallélisme est moins agressive que pgBackRest.

pg_basebackup reste l'outil de référence livré avec PostgreSQL. Simple, fiable, sans dépendance externe. Mais il ne fait que des backups full, sans incrémental, sans parallélisme avancé, sans gestion de rétention intégrée. Suffisant pour de petites bases ou comme filet de sécurité secondaire.

Pour les équipes sur infrastructure managée (RDS, CloudSQL, Azure Database), la question se pose différemment : les mécanismes de snapshot du provider remplacent souvent avantageusement un outil tiers, au prix d'une dépendance accrue au vendor.

Ce qu'il faut faire maintenant

🔍 Court terme (cette semaine) : documentez votre configuration pgBackRest actuelle et vérifiez que vos backups tournent normalement. Ne changez rien dans l'urgence.

📋 Moyen terme (1 à 3 mois) : réalisez l'audit décrit ci-dessus. Testez l'outil alternatif le plus adapté à votre profil dans un environnement de staging. Mesurez les écarts de performance par rapport à votre baseline.

🔄 Migration : planifiez une période de double-run — les deux outils en parallèle — avant de basculer définitivement. Validez un restore complet avec le nouvel outil avant de désactiver pgBackRest.

Conclusion

La fin de maintenance de pgBackRest est un signal d'alerte, pas une urgence. La vraie leçon à retenir est plus large : votre stratégie de backup ne devrait jamais reposer sur un seul outil sans plan de continuité. C'est l'occasion de formaliser ce plan si ce n'est pas déjà fait.

Chez MulerTech, nous accompagnons les équipes dans l'audit et la sécurisation de leurs infrastructures de données. Si vous avez des doutes sur la robustesse de votre stratégie de backup PostgreSQL, c'est le bon moment pour en parler.