pgbackrest/pgbackrestSolution de sauvegarde et de restauration parallèle pour PostgreSQL avec chiffrement, restauration différentielle et prise en charge du stockage d'objets multi-cloud pour la reprise après sinistre en entreprise.
pgBackRest est une solution fiable de sauvegarde et de restauration pour PostgreSQL qui s'adapte facilement aux plus grandes bases de données et charges de travail.
pgBackRest v2.59.1 est la version stable actuelle. Les notes de version sont disponibles sur la page Releases.
Veuillez nous accorder une étoile sur GitHub si vous aimez pgBackRest !
17 août 2026 - pgBackRest 2.59.1 publié
20 juillet 2026 - Nouvelle archive de distribution
20 juillet 2026 - pgBackRest 2.59.0 publié
La compression est généralement le goulot d'étranglement lors des opérations de sauvegarde. pgBackRest résout ce problème grâce au traitement parallèle et à des algorithmes de compression plus efficaces tels que lz4 et zstd.
Un protocole personnalisé permet à pgBackRest de sauvegarder, restaurer et archiver localement ou à distance via TLS/SSH avec une configuration minimale. Une interface d'interrogation de PostgreSQL est également fournie via la couche protocole, de sorte qu'un accès distant à PostgreSQL n'est jamais requis, ce qui renforce la sécurité.
Les dépôts multiples permettent, par exemple, un dépôt local avec une rétention minimale pour des restaurations rapides et un dépôt distant avec une rétention plus longue pour la redondance et l'accès à l'échelle de l'entreprise.
Les sauvegardes complètes, différentielles et incrémentielles sont prises en charge. pgBackRest n'est pas sensible aux problèmes de résolution temporelle de rsync, ce qui rend les sauvegardes différentielles et incrémentielles sûres sans avoir à calculer la somme de contrôle de chaque fichier. Les sauvegardes au niveau bloc économisent de l'espace en ne copiant que les parties des fichiers qui ont changé.
Des politiques de rétention peuvent être définies pour les sauvegardes complètes et différentielles afin de couvrir n'importe quelle période. L'archive WAL peut être conservée pour toutes les sauvegardes ou strictement pour les sauvegardes les plus récentes. Dans ce dernier cas, les WAL nécessaires pour rendre les sauvegardes plus anciennes cohérentes seront conservés dans l'archive.
Des sommes de contrôle sont calculées pour chaque fichier de la sauvegarde et revérifiées lors d'une restauration ou d'une vérification. Après avoir fini de copier les fichiers, la sauvegarde attend que chaque segment WAL requis pour rendre la sauvegarde cohérente atteigne le dépôt.
Les sauvegardes du dépôt peuvent être stockées dans le même format qu'un cluster PostgreSQL standard (y compris les tablespaces). Si la compression est désactivée et que les liens physiques sont activés, il est possible de créer un instantané d'une sauvegarde du dépôt et de démarrer un cluster PostgreSQL directement sur l'instantané. Cela est avantageux pour les bases de données à l'échelle du téraoctet dont la restauration de manière traditionnelle prend du temps.
Toutes les opérations utilisent fsync au niveau fichier et répertoire pour garantir la durabilité.
Si les sommes de contrôle de pages sont activées, pgBackRest validera les sommes de contrôle de chaque fichier copié lors d'une sauvegarde. Toutes les sommes de contrôle de pages sont validées lors d'une sauvegarde complète, et les sommes de contrôle des fichiers modifiés sont validées lors des sauvegardes différentielles et incrémentielles.
Les échecs de validation n'arrêtent pas le processus de sauvegarde, mais des avertissements détaillant exactement quelles pages ont échoué à la validation sont affichés sur la console et dans le journal des fichiers.
Cette fonctionnalité permet de détecter rapidement la corruption au niveau des pages, avant que les sauvegardes contenant des copies valides des données n'aient expiré.
Une sauvegarde interrompue peut être reprise à partir du point où elle s'est arrêtée. Les fichiers déjà copiés sont comparés aux sommes de contrôle du manifeste pour garantir l'intégrité. Comme cette opération peut se dérouler entièrement sur l'hôte du dépôt, elle réduit la charge sur l'hôte PostgreSQL et fait gagner du temps, car le calcul des sommes de contrôle est plus rapide que la compression et la retransmission des données.
La compression et les calculs de sommes de contrôle sont effectués en flux pendant que les fichiers sont copiés vers le dépôt, que le dépôt soit situé localement ou à distance.
Si le dépôt se trouve sur un hôte de dépôt, la compression est effectuée sur l'hôte PostgreSQL et les fichiers sont transmis dans un format compressé puis simplement stockés sur l'hôte de dépôt. Lorsque la compression est désactivée, un niveau de compression plus faible est utilisé pour utiliser efficacement la bande passante disponible tout en minimisant le coût en CPU.
Le manifeste contient les sommes de contrôle de chaque fichier de la sauvegarde, de sorte que lors d'une restauration, il est possible d'utiliser ces sommes de contrôle pour accélérer considérablement le traitement. Lors d'une restauration delta, les fichiers absents de la sauvegarde sont d'abord supprimés, puis les sommes de contrôle sont générées pour les fichiers restants. Les fichiers qui correspondent à la sauvegarde sont laissés en place et le reste des fichiers est restauré comme d'habitude. Le traitement parallèle peut entraîner une réduction spectaculaire des temps de restauration.
Des commandes dédiées sont incluses pour envoyer les WAL vers l'archive et les récupérer depuis l'archive. Les deux commandes prennent en charge le parallélisme pour accélérer le traitement et s'exécutent de manière asynchrone pour offrir le temps de réponse le plus rapide possible à PostgreSQL.
L'envoi WAL détecte automatiquement les segments WAL envoyés plusieurs fois et déduplique lorsque le segment est identique ; sinon, une erreur est levée. L'envoi WAL asynchrone permet de décharger le transfert vers un autre processus qui compresse les segments WAL en parallèle pour un débit maximal. Cette fonctionnalité peut être cruciale pour les bases de données ayant un volume d'écriture extrêmement élevé.
La récupération WAL asynchrone maintient une file d'attente locale de segments WAL décompressés et prêts à être rejoués. Cela réduit le temps nécessaire pour fournir les WAL à PostgreSQL, ce qui maximise la vitesse de rejeu. Les connexions et stockages à latence plus élevée (tels que S3) en bénéficient le plus.
Les commandes d'envoi et de récupération garantissent toutes deux que la base de données et le dépôt correspondent en comparant les versions de PostgreSQL et les identifiants système. Cela élimine pratiquement toute possibilité de mauvaise configuration de l'emplacement de l'archive WAL.
Les tablespaces sont entièrement pris en charge et, lors de la restauration, ils peuvent être remappés vers n'importe quel emplacement. Il est également possible de remapper tous les tablespaces vers un seul emplacement avec une seule commande, ce qui est utile pour les restaurations de développement.
Les liens de fichiers et de répertoires sont pris en charge pour tout fichier ou répertoire du cluster PostgreSQL. Lors de la restauration, il est possible de restaurer tous les liens vers leurs emplacements d'origine, de remapper certains ou tous les liens, ou de restaurer certains ou tous les liens comme des fichiers ou répertoires normaux dans le répertoire du cluster.
Les dépôts pgBackRest peuvent être situés dans des magasins d'objets compatibles S3, Azure et GCS, ce qui permet une capacité et une rétention pratiquement illimitées.
pgBackRest peut chiffrer le dépôt pour sécuriser les sauvegardes où qu'elles soient stockées.
Lorsque le dépôt est stocké sur un stockage d'objets versionné, pgBackRest peut lire le dépôt tel qu'il était à un moment donné. Si les sauvegardes sont supprimées ou corrompues accidentellement, par un logiciel malveillant ou par un rançongiciel, une heure cible peut être utilisée pour récupérer les données d'avant le sinistre.
Le versionnage est pris en charge par les magasins d'objets compatibles S3, Azure et GCS. Le verrouillage d'objets pour S3 et la suppression réversible (soft delete) pour GCS ou Azure peuvent offrir une protection supplémentaire contre la falsification.
pgBackRest prend en charge dix versions de PostgreSQL : les cinq versions prises en charge et les cinq dernières versions en fin de vie. Cela laisse amplement le temps de passer à une version prise en charge.
pgBackRest s'efforce d'être facile à configurer et à utiliser :
pgBackRest n'existerait pas sans le parrainage : les nouvelles fonctionnalités, les corrections de bogues, les revues de contributions, le support communautaire et la maintenance demandent tous un temps considérable. Veuillez envisager un parrainage si vous utilisez pgBackRest dans votre entreprise.
Nos sponsors : AWS, Supabase, pgEdge, Tiger Data, Percona, Eon, Xata, Dalibo, Data Egret.
Nous sommes reconnaissants envers nos sponsors qui investissent dans une infrastructure open source qui profite à toute la communauté PostgreSQL.
Anciens sponsors : Crunchy Data, Resonate.
Les contributions à pgBackRest sont toujours les bienvenues ! Veuillez consulter nos Directives de contribution pour plus de détails sur la façon de contribuer avec des fonctionnalités, des améliorations ou des signalements de problèmes.
pgBackRest est totalement gratuit et open source sous licence MIT. Vous pouvez l'utiliser à des fins personnelles ou commerciales sans aucune restriction. Les rapports de bogues sont pris très au sérieux et seront traités aussi rapidement que possible. Veuillez signaler les bogues ici.
La création d'une politique de reprise après sinistre robuste avec des stratégies de réplication et de sauvegarde appropriées peut être une tâche très complexe et décourageante. Vous constaterez peut-être que vous avez besoin d'aide pendant la phase d'architecture et d'un support continu pour garantir le bon fonctionnement de votre entreprise.
Nos sponsors proposent des produits et services incluant le support pgBackRest et peuvent vous aider dans vos besoins de reprise après sinistre.
