pgBackRest
Sauvegarde et restauration PostgreSQL fiables

Introduction

pgBackRest est une solution fiable de sauvegarde et de restauration pour PostgreSQL qui s'adapte de manière transparente aux bases de données et aux charges de travail les plus volumineuses.

pgBackRest v2.59.2 est la version stable actuelle. Les notes de version sont disponibles sur la page Releases.

N'hésitez pas à nous attribuer une étoile sur GitHub si vous aimez pgBackRest !

Actualités

27 septembre 2026 - pgBackRest 2.59.2 publié

17 août 2026 - pgBackRest 2.59.1 publié

20 juillet 2026 - Nouvelle archive de distribution

Fonctionnalités

Sauvegarde et restauration parallèles

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.

Fonctionnement local ou distant

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 protocolaire, de sorte que l'accès distant à PostgreSQL n'est jamais nécessaire, ce qui renforce la sécurité.

Dépôts multiples

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.

Sauvegardes complètes, différentielles et incrémentielles (au niveau fichier ou bloc)

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é.

Rotation des sauvegardes et expiration de l'archive

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.

Intégrité des sauvegardes

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 les liens physiques 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é.

Sommes de contrôle des pages

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 sur la console et dans le journal de fichiers.

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.

Reprise de sauvegarde

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 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 fait gagner du temps, le calcul des sommes de contrôle étant plus rapide que la compression et la retransmission des données.

Compression et sommes de contrôle en flux

La compression et le calcul des sommes de contrôle sont effectués en flux pendant la copie des fichiers 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 et les fichiers sont transmis dans un format compressé puis simplement stockés sur l'hôte du dépôt. Lorsque la compression est désactivée, un niveau de compression inférieur est utilisé afin d'exploiter efficacement la bande passante disponible tout en minimisant le coût CPU.

Restauration delta

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.

Envoi et récupération WAL parallèles et asynchrones

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 à volume d'écriture extrêmement élevé.

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 le stockage à latence plus élevée (comme S3) en bénéficient le plus.

Les commandes push et get 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.

Prise en charge des tablespaces et des liens

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.