pgBackRest est mort : vos sauvegardes PostgreSQL sont-elles vraiment sûres ?

pgBackRest est mort : vos sauvegardes PostgreSQL sont-elles vraiment sûres ?

C'est l'annonce que personne ne voulait voir tomber : David Steele, unique mainteneur de pgBackRest depuis treize ans, a officiellement cessé tout travail sur le projet. Plus de maintenance, plus de correctifs, plus de revues de pull requests. pgBackRest est aujourd'hui un projet abandonné.

Si vous utilisez pgBackRest en production — et c'est probable, tant l'outil s'est imposé comme la référence absolue pour les sauvegardes PostgreSQL — vous avez une fenêtre d'action. Voici comment l'utiliser.

Source originale : pgBackRest is dead. Now what? par Lætitia Avrot

Ce qui s'est passé

Crunchy Data, l'entreprise qui sponsorisait pgBackRest et employait David Steele, a été rachetée. David a passé plusieurs mois à chercher un poste lui permettant de continuer à travailler sur le projet, et à prospecter des sponsors indépendants. Sans succès. Il a besoin de vivre, le projet nécessite un effort soutenu qu'il ne peut plus fournir gratuitement. C'est aussi simple que cela.

Ce n'est pas une défaillance de David — c'est une défaillance systémique du modèle de financement de l'open source. Un outil utilisé par des milliers d'équipes en production, maintenu à bout de bras par une poignée de personnes, sans garantie de pérennité financière. Le résultat était prévisible.

Audit immédiat : ce que vous devez vérifier maintenant

Avant de migrer vers quoi que ce soit, commencez par mesurer précisément votre exposition. Voici une checklist opérationnelle à exécuter cette semaine.

1. Vérifier l'intégrité de vos archives WAL

# Vérifier que les WAL sont bien archivés et lisibles
pgbackrest --stanza=mon-stanza --log-level-console=info check

# Lister les sauvegardes disponibles et leur statut
pgbackrest --stanza=mon-stanza info

Si check échoue ou si la dernière sauvegarde remonte à plus de 24h, vous avez un problème immédiat à traiter avant même d'envisager une migration.

2. Exécuter un restore drill

Une sauvegarde que vous n'avez jamais restaurée n'existe pas. C'est la règle numéro un. Si votre équipe ne fait pas de restore drill régulier, c'est le moment de commencer — indépendamment de la situation pgBackRest.

# Restauration complète sur un environnement de test
pgbackrest --stanza=mon-stanza --pg1-path=/var/lib/postgresql/test restore

# PITR : restaurer jusqu'à un point dans le temps précis
pgbackrest --stanza=mon-stanza \
  --pg1-path=/var/lib/postgresql/test \
  --type=time \
  "--target=2026-04-27 10:00:00" restore

Idéalement, automatisez ces drills en CI/CD. Un job hebdomadaire qui restaure sur un environnement éphémère et valide l'intégrité des données est un filet de sécurité concret.

3. Identifier votre version en production

pgBackRest ne recevra plus de correctifs de sécurité. Notez votre version actuelle et surveillez les CVE PostgreSQL qui pourraient affecter les outils de backup.

pgbackrest version

Comparaison des alternatives

Trois outils principaux s'offrent à vous. Voici une comparaison factuelle.

Barman est le successeur naturel le plus proche de pgBackRest en termes de fonctionnalités. Il est maintenu par EDB (EnterpriseDB), une entreprise solide avec un modèle commercial clair. La migration demande du temps, mais la parité fonctionnelle est réelle.

WAL-G est plus léger, orienté cloud-native, et particulièrement adapté aux environnements containerisés. Sa configuration est plus simple, mais il est moins riche pour les scénarios multi-serveurs.

pg_basebackup est l'outil officiel livré avec PostgreSQL. Il convient pour des sauvegardes simples sans déduplication ni archivage WAL automatisé. À réserver aux environnements peu critiques ou comme couche de base.

Conteneurisation avec Docker

Si votre PostgreSQL tourne sous Docker, la migration vers WAL-G s'intègre proprement via un sidecar ou un job cron :

# docker-compose.yml — exemple avec WAL-G
services:
  postgres:
    image: postgres:16
    environment:
      WALG_S3_PREFIX: s3://mon-bucket/backups
      AWS_ACCESS_KEY_ID: ${AWS_ACCESS_KEY_ID}
      AWS_SECRET_ACCESS_KEY: ${AWS_SECRET_ACCESS_KEY}
  
  backup:
    image: mon-image-walg
    depends_on: [postgres]
    command: >
      sh -c "while true; do
        wal-g backup-push /var/lib/postgresql/data;
        sleep 86400;
      done"

Plan d'action priorisé

Court terme (cette semaine)

• Exécuter la checklist d'audit ci-dessus
• Vérifier que vos sauvegardes actuelles sont restaurables
• Geler les mises à jour de pgBackRest (risque de régression sans maintenance)

Moyen terme (1 à 3 mois)

• Évaluer Barman ou WAL-G selon votre infrastructure
• Mettre en place des restore drills automatisés en CI
• Documenter votre RTO et RPO cibles pour guider le choix d'outil

Long terme

• Migrer intégralement vers l'alternative retenue
• Contribuer au projet retenu ou envisager de rejoindre un effort de fork/transfert de mainteneur pour pgBackRest si la communauté s'organise en ce sens

Conclusion

pgBackRest restera dans la mémoire collective des DBAs comme un outil d'une qualité exceptionnelle, construit par une équipe minuscule avec une rigueur remarquable. Mais un outil sans mainteneur actif est un risque opérationnel que vous ne pouvez pas ignorer, surtout sur des données critiques.

La bonne nouvelle : vous avez du temps pour agir méthodiquement. pgBackRest continue de fonctionner tel quel — il ne va pas s'effondrer demain. Mais chaque jour sans plan de migration est un jour de risque supplémentaire.

Commencez par l'audit. Vérifiez que vos sauvegardes sont restaurables aujourd'hui. Le reste suivra.