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 de sauvegarde et de restauration fiable pour PostgreSQL qui s'adapte de manière transparente aux bases de données et aux charges de travail les plus volumineuses.
pgBackRest v2.60.0 est la version stable actuelle. Les notes de version se trouvent sur la page Releases.
N'hésitez pas à nous attribuer une étoile sur GitHub si vous aimez pgBackRest !
18 octobre 2026 - pgBackRest 2.60.0 publié
4 octobre 2026 - Sous-clés de chiffrement et sels faibles
4 octobre 2026 - pgBackRest 2.59.3 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 permettant d'interroger PostgreSQL est également fournie via la couche de protocole, de sorte que l'accès distant à PostgreSQL n'est jamais nécessaire, ce qui renforce la sécurité.
Les dépôts multiples permettent, par exemple, d'avoir 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 peuvent être effectuées depuis un standby afin de réduire la charge sur le primaire. Seuls les quelques fichiers qui ne sont pas répliqués sont copiés depuis le primaire.
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 nécessiter le calcul de somme de contrôle pour 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 cohérentes les sauvegardes plus anciennes 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. Une fois la copie des fichiers terminée, la sauvegarde attend que chaque segment WAL nécessaire pour la rendre 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 prendre un instantané d'une sauvegarde dans le dépôt et de démarrer un cluster PostgreSQL directement sur cet instantané. Cela est avantageux pour les bases de données de l'ordre du téraoctet dont la restauration traditionnelle prend beaucoup de temps.
Toutes les opérations utilisent fsync au niveau des fichiers et des répertoires pour garantir la durabilité.
Si les sommes de contrôle des 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 des pages sont validées lors d'une sauvegarde complète, et les sommes de contrôle des fichiers qui ont changé sont validées lors des sauvegardes différentielles et incrémentielles.
Les échecs de validation n'interrompent pas le processus de sauvegarde, mais des avertissements détaillant exactement quelles pages ont échoué à la validation sont affichés dans la console et dans le journal de fichiers. Par défaut, la restauration échoue lorsque la sauvegarde présente des sommes de contrôle de pages invalides, et l'expiration ne laissera pas une sauvegarde avec des sommes de contrôle de pages invalides comme sauvegarde la plus ancienne.
Cette fonctionnalité permet de détecter précocement une corruption au niveau des pages, avant que les sauvegardes contenant des copies valides des données n'expirent.
Une sauvegarde interrompue peut être reprise à partir du point où elle a été arrêtée. Les fichiers déjà copiés sont comparés aux sommes de contrôle du manifeste afin de garantir leur 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 permet de gagner du temps, le calcul des sommes de contrôle étant plus rapide que la compression et la retransmission des données.
La compression et le calcul des sommes de contrôle sont effectués en flux pendant que les fichiers sont copiés vers le dépôt, que celui-ci 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, les fichiers sont transmis sous forme compressée et simplement stockés sur l'hôte du dépôt. Lorsque la compression est désactivée, un niveau de compression plus faible est utilisé afin d'exploiter efficacement la bande passante disponible tout en réduisant au minimum le coût CPU.
Les petits fichiers sont combinés en lots dans le dépôt afin de créer moins de fichiers lors de la sauvegarde. Cela est particulièrement efficace sur les stockages objet.
Le manifeste contient les sommes de contrôle de chaque fichier de la sauvegarde, ce qui permet, lors d'une restauration, d'utiliser ces sommes de contrôle pour accélérer considérablement le traitement. Lors d'une restauration delta, tous 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 correspondant à 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 afin d'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 les déduplique lorsque le segment est identique, sinon une erreur est levée. L'envoi WAL asynchrone permet de déléguer le transfert à un autre processus qui compresse les segments WAL en parallèle pour un débit maximal. Cela peut être une fonctionnalité critique pour les bases de données à très fort volume d'écriture.
La récupération WAL asynchrone maintient une file 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 (comme S3) en bénéficient le plus.
