Guide utilisateur (Debian/Ubuntu)
Introduction
Ce guide utilisateur est conçu pour être suivi séquentiellement, du début à la fin — chaque section dépend de la précédente. Par exemple, la section Restauration repose sur la configuration effectuée dans la section Démarrage rapide . Une fois pgBackRest en fonctionnement, il est possible de sauter des sections, mais il est recommandé de suivre le guide dans l’ordre lors de la première utilisation.
Bien que les exemples de ce guide soient destinés à Debian/Ubuntu et à PostgreSQL 17, il devrait être relativement facile de les appliquer à toute distribution Unix et toute version de PostgreSQL. Les seules commandes spécifiques au système d’exploitation sont celles permettant de créer, démarrer, arrêter et supprimer des clusters PostgreSQL. Les commandes pgBackRest seront identiques sur tout système Unix, bien que l’emplacement de l’exécutable puisse varier. Bien que pgBackRest cherche à fonctionner de manière cohérente sur les différentes versions de PostgreSQL, certaines différences subtiles entre versions de PostgreSQL peuvent apparaître dans ce guide lors de l’illustration de certains exemples, par exemple les chemins ou noms de fichiers de PostgreSQL, ainsi que les paramètres.
Informations de configuration et documentation pour PostgreSQL sont disponibles dans le Manuel de PostgreSQL.
Une approche quelque peu originale est adoptée pour la documentation dans ce guide utilisateur. Chaque commande est exécutée sur une machine virtuelle au moment où la documentation est générée à partir de la source XML. Cela signifie que vous pouvez avoir une confiance élevée quant au bon fonctionnement des commandes, dans l’ordre présenté. La sortie est capturée et affichée sous la commande lorsque cela est pertinent. Si la sortie n’est pas incluse, c’est parce qu’elle a été jugée sans intérêt ou qu’elle aurait pu distraire du récit.
Toutes les commandes doivent être exécutées en tant qu’utilisateur non privilégié disposant des droits sudo pour les utilisateurs root et postgres. Il est également possible d’exécuter les commandes directement en tant que leurs utilisateurs respectifs sans modification, auquel cas les commandes sudo peuvent être omises.
Concepts
Les concepts suivants sont définis en tant qu’ils sont pertinents pour pgBackRest, PostgreSQL et ce guide utilisateur.
sauvegarde
Une sauvegarde est une copie cohérente d’un cluster de base de données pouvant être restaurée pour récupérer après une panne matérielle, effectuer une restauration à un instant donné ou mettre en place un serveur secondaire nouveau.
Sauvegarde complète : pgBackRest copie l’intégralité du contenu du cluster de base de données vers la sauvegarde. La première sauvegarde du cluster de base de données est toujours une sauvegarde complète. pgBackRest est toujours en mesure de restaurer directement une sauvegarde complète. La sauvegarde complète ne dépend d’aucun fichier en dehors d’elle-même pour assurer sa cohérence.
Sauvegarde différentielle : pgBackRest copie uniquement les fichiers du cluster de base de données modifiés depuis la dernière sauvegarde complète. Pour restaurer une sauvegarde différentielle, pgBackRest copie tous les fichiers de celle-ci ainsi que les fichiers inchangés requis de la sauvegarde complète précédente. Une sauvegarde différentielle occupe moins d’espace disque qu’une sauvegarde complète, mais elle et la sauvegarde complète doivent chacune être valides pour permettre la restauration.
Sauvegarde incrémentielle : pgBackRest copie uniquement les fichiers du cluster de base de données ayant changé depuis la dernière sauvegarde (qui peut être une autre sauvegarde incrémentielle, une sauvegarde différentielle ou une sauvegarde complète). Comme une sauvegarde incrémentielle ne comprend que les fichiers modifiés depuis la sauvegarde précédente, elle est généralement bien plus petite que les sauvegardes complètes ou différentielles. Comme pour la sauvegarde différentielle, la sauvegarde incrémentielle dépend d’autres sauvegardes pour être valide lors d’une restauration. Étant donné qu’une sauvegarde incrémentielle ne contient que les fichiers modifiés depuis la dernière sauvegarde, toutes les sauvegardes incrémentielles antérieures jusqu’à la dernière sauvegarde différentielle, la dernière sauvegarde différentielle et la dernière sauvegarde complète doivent être valides afin de pouvoir restaurer la sauvegarde incrémentielle. Si aucune sauvegarde différentielle n’existe, alors toutes les sauvegardes incrémentielles antérieures jusqu’à la dernière sauvegarde complète, qui doit exister, ainsi que la sauvegarde complète elle-même doivent être valides pour restaurer la sauvegarde incrémentielle.
restauration
Une restauration est l’opération de copie d’une sauvegarde sur un système où elle sera lancée en tant que cluster de base de données en cours d’exécution. Une restauration nécessite les fichiers de sauvegarde et un ou plusieurs segments WAL afin de fonctionner correctement.
Journaux d’écriture anticipée (WAL)
Le WAL est le mécanisme utilisé par PostgreSQL pour garantir qu’aucun changement validé n’est perdu. Les transactions sont écrites séquentiellement dans le WAL, et une transaction est considérée comme validée lorsque ces écritures sont écrites sur le disque. Par la suite, un processus en arrière-plan écrit les modifications dans les fichiers du cluster de base de données principal (également appelés heap). En cas de panne, le WAL est rejoué afin de rendre la base de données cohérente.
Les journaux d’écriture (WAL) sont conceptuellement infinis, mais en pratique ils sont divisés en fichiers individuels de 16 Mo appelés segments. Les segments WAL suivent la convention de nommage 0000000100000A1E000000FE, où les huit premiers chiffres hexadécimaux représentent la timeline et les seize chiffres suivants constituent le numéro de séquence logique (LSN).
Chiffrement
Le chiffrement est le processus de conversion des données dans un format illisible à moins qu’un mot de passe approprié (appelé également phrase secrète) ne soit fourni.
pgBackRest chiffrera le dépôt en fonction d’un mot de passe fourni par l’utilisateur, empêchant ainsi tout accès non autorisé aux données stockées dans le dépôt.
Mise à jour de pgBackRest
Mise à jour de pgBackRest de la version v2.x à la v2.y
La mise à niveau depuis la version v2.x vers la version v2.y est directe. Le format du dépôt n’a pas changé, aussi, pour la plupart des installations, il s’agit simplement d’installer les binaires de la nouvelle version. Il est également possible de revenir à une version antérieure si vous n’avez pas utilisé de fonctionnalités nouvelles non prises en charge par la version plus ancienne.
IMPORTANT :
Les versions locales et distantes de pgBackRest doivent correspondre exactement, elles doivent donc être mises à jour ensemble. En cas de désaccord, l’archivage des WAL et les sauvegardes ne fonctionneront pas jusqu’à ce que les versions soient synchronisées. Dans ce cas, l’erreur suivante sera signalée : [ProtocolError] expected value '2.x' for greeting key 'version' but got '2.y'.
Construction
Installer pgBackRest à partir d’un paquet est préférable à la compilation à partir des sources. Consultez Installation pour plus d’informations sur les paquets.
Lors de la compilation à partir des sources, il est préférable d’utiliser une machine de compilation plutôt que de compiler directement sur la production. La plupart des outils nécessaires à la compilation ne devraient généralement pas être installés en production. pgBackRest se compose d’un seul exécutable, ce qui facilite sa copie sur une nouvelle machine une fois compilé.
build ⇒ Télécharger la version 2.59.1 de pgBackRest vers le chemin /build
build ⇒ Installer les dépendances de compilation
build ⇒ Configurer et compiler pgBackRest
build ⇒ Exécuter éventuellement des tests de fumée pour vérifier que pgBackRest a été correctement construit
Installation
Un nouvel hôte nommé pg-primary est créé pour contenir le cluster de démonstration et exécuter les exemples pgBackRest.
Installer pgBackRest à partir d’un paquet est préférable à la compilation à partir des sources. Lors de l’installation à partir d’un paquet, les autres instructions de cette section sont généralement inutiles, mais il se peut qu’un paquet omette de créer un répertoire ou applique des permissions incorrectes. Dans ce cas, il peut être nécessaire de créer manuellement les répertoires ou de mettre à jour les permissions.
Les paquets Debian/Ubuntu pour pgBackRest sont disponibles sur apt.PostgreSQL.org .
Si des paquets ne sont pas fournis pour votre distribution/version, vous pouvez compiler à partir des sources puis procéder à l’installation manuelle comme indiqué ici.
pg-primary ⇒ Installer les dépendances
pg-primary ⇒ Copier le binaire pgBackRest depuis l’hôte de compilation
pgBackRest nécessite des répertoires pour les journaux et la configuration, ainsi qu’un fichier de configuration.
pg-primary ⇒ Créer le fichier de configuration et les répertoires pgBackRest
pgBackRest doit maintenant être correctement installé, mais il est préférable de le vérifier. Si des dépendances ont été omises, une erreur sera générée lors de l’exécution de pgBackRest en ligne de commande.
pg-primary ⇒ Vérifiez que l’installation s’est déroulée correctement
Démarrage rapide
La section Début rapide abordera la configuration basique de pgBackRest et de PostgreSQL, et présentera les commandes backup, restore et info.
Configurer un cluster de démonstration
La création du cluster de démonstration est facultative mais fortement recommandée, en particulier pour les nouveaux utilisateurs, car les commandes d’exemple du guide utilisateur font référence au cluster de démonstration ; les exemples supposent que le cluster de démonstration s’exécute sur le port par défaut (c’est-à-dire 5432). Le cluster ne sera pas lancé avant une section ultérieure, car il reste encore certaines configurations à effectuer.
pg-primary ⇒ Créer le cluster de démonstration
Configurer une stanza de cluster
Une stanza est la configuration d’un cluster de base de données PostgreSQL qui définit son emplacement, la manière dont il sera sauvegardé, les options d’archivage, etc. La plupart des serveurs de base de données n’ont qu’un seul cluster PostgreSQL et donc une seule stanza, tandis que les serveurs de sauvegarde ont une stanza pour chaque cluster de base de données à sauvegarder.
Il est tentant de nommer la stanza en fonction du cluster principal, mais un nom plus pertinent décrit les bases de données contenues dans le cluster. Étant donné que le nom de la stanza sera utilisé pour le principal et toutes les répliques, il est préférable de choisir un nom qui décrit la fonction réelle du cluster, par exemple app ou dw, plutôt que le nom local du cluster, comme main ou prod.
Le nom « demo » décrit avec précision le but de ce cluster, ce qui en fait également un bon nom de stanza.
pgBackRest doit connaître l’emplacement du répertoire de données de base du cluster PostgreSQL. Le chemin peut être demandé directement à PostgreSQL, mais dans un scénario de récupération, le processus PostgreSQL ne sera pas disponible. Lors des sauvegardes, la valeur fournie à pgBackRest sera comparée au chemin sur lequel PostgreSQL est en cours d’exécution, et elles doivent être identiques, sinon la sauvegarde retournera une erreur. Assurez-vous que pg-path est exactement égal à la valeur data_directory rapportée par PostgreSQL.
Par défaut, Debian/Ubuntu stocke les clusters dans /var/lib/postgresql/[version]/[cluster], ce qui facilite la détermination du chemin correct du répertoire de données.
Lors de la création du fichier /etc/pgbackrest/pgbackrest.conf, le propriétaire de la base de données (généralement postgres) doit être autorisé en lecture.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure le répertoire de données du cluster PostgreSQL
Les fichiers de configuration de pgBackRest suivent une convention semblable à celle des fichiers INI sous Windows. Les sections sont indiquées par du texte entre crochets, et les paires clé/valeur sont contenues dans chaque section. Les lignes commençant par # sont ignorées et peuvent être utilisées comme commentaires, mais les commentaires en fin de ligne suivant une valeur sur la même ligne ne sont pas pris en charge. Les guillemets ne sont pas pris en charge, et les espaces sont supprimés des clés et des valeurs. Les sections seront fusionnées si elles apparaissent plus d’une fois.
Il existe plusieurs façons de charger les fichiers de configuration de pgBackRest :
configetconfig-include-pathsont par défaut : le fichier de configuration par défaut sera chargé, s’il existe, et les fichiers*.confdans le chemin d’inclusion de configuration par défaut seront ajoutés, s’ils existent.configest spécifié : seul le fichier de configuration indiqué sera chargé et doit exister.config-include-pathest spécifié : les fichiers*.confdans le chemin d’inclusion de configuration seront chargés et le chemin doit exister. Le fichier de configuration par défaut sera chargé s’il existe. Si l’on souhaite charger uniquement les fichiers dans le chemin d’inclusion de configuration spécifié, l’option--no-configpeut également être passée.configetconfig-include-pathsont spécifiés : en utilisant les valeurs spécifiées par l’utilisateur, le fichier de configuration sera chargé et les fichiers*.confdans le chemin d’inclusion de configuration seront ajoutés. Les fichiers doivent exister.config-pathest spécifié : ce paramètre remplacera le chemin de base pour l’emplacement par défaut du fichier de configuration et/ou le chemin de base du paramètre de chemin d’inclusion de configuration par défaut, sauf si l’option config et/ou config-include-path est explicitement définie.
Les fichiers sont concaténés comme s’ils formaient un seul grand fichier, et chaque fichier doit être valide individuellement. Cela signifie que les sections doivent être spécifiées dans chaque fichier là où elles sont nécessaires pour stocker une paire clé/valeur. L’ordre n’a pas d’importance, mais une priorité s’applique selon les sections. La priorité (de la plus élevée à la plus faible) est :
- [stanza:command]
- [stanza]
- [global:command]
- [global]
NOTE :
--config, --config-include-path et --config-path sont des options uniquement disponibles en ligne de commande.
pgBackRest peut également être configuré à l’aide de variables d’environnement (exemple ci-dessous) ; ces variables s’appliquent aux commandes telles que backup , restore et archive-push .
pg-primary ⇒ Configure log-path en utilisant l’environnement
Créer le dépôt
Le dépôt est l’emplacement où pgBackRest stocke les sauvegardes et les archives des segments WAL.
Il peut être difficile de prévoir à l’avance l’espace nécessaire. La meilleure approche consiste à effectuer quelques sauvegardes, puis à noter la taille des différents types de sauvegardes (pleines, incrémentielles, différentielles) et à mesurer la quantité de WAL générée par jour. Cela vous donnera une idée générale de l’espace requis, bien que les besoins évoluent probablement au fil du temps avec l’évolution de votre base de données.
Pour cette démonstration, le dépôt sera stocké sur le même hôte que le serveur PostgreSQL. Il s’agit de la configuration la plus simple et elle est utile dans les cas où un logiciel de sauvegarde traditionnel est utilisé pour sauvegarder l’hôte de la base de données.
pg-primary ⇒ Créer le dépôt pgBackRest
Le chemin du dépôt doit être configuré afin que pgBackRest sache où le trouver.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez le chemin du dépôt pgBackRest
Plusieurs dépôts peuvent également être configurés. Consultez Dépôts multiples pour plus de détails.
Configurer la sauvegarde archivée
La sauvegarde d’un cluster PostgreSQL en cours d’exécution nécessite que l’archivage du WAL soit activé. %p est le mécanisme utilisé par PostgreSQL pour spécifier l’emplacement du segment WAL à archiver. Notez qu’au moins un segment WAL sera créé pendant le processus de sauvegarde, même si aucune écriture explicite n’est effectuée sur le cluster.
pg-primary:/etc/postgresql/17/demo/postgresql.conf ⇒ Configurez les paramètres d’archive
Le cluster PostgreSQL doit être redémarré après avoir apporté ces modifications et avant d’effectuer une sauvegarde.
pg-primary ⇒ Redémarrer le cluster de démonstration
Le paramètre hot_standby est activé par défaut et doit rester ainsi sur chaque cluster. Un cluster peut être restauré ultérieurement en réplica, par exemple un principal reconstruit en réplica après une bascule, et un réplica n’acceptera pas de connexions en lecture seule sans ce paramètre.
Lorsqu’il est prévu qu’un segment WAL mette plus de 60 secondes (valeur par défaut) à atteindre le dépôt pgBackRest, l’option archive-timeout de pgBackRest doit être augmentée. Notez que cette option n’est pas identique à l’option archive_timeout de PostgreSQL, qui est utilisée pour forcer un basculement de segment WAL ; elle est utile pour les bases de données présentant des périodes prolongées d’inactivité. Pour plus d’informations sur l’option archive_timeout de PostgreSQL, consultez PostgreSQL Write Ahead Log
.
La commande archive-push peut être configurée avec ses propres options. Par exemple, un niveau de compression plus faible peut être défini afin d’accélérer l’archivage sans affecter le niveau de compression utilisé pour les sauvegardes.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurer archive-push pour utiliser un niveau de compression plus faible
Cette configuration technique peut être utilisée pour toute commande et peut même cibler une stanza spécifique, par exemple demo:archive-push.
Configurer la rétention
pgBackRest expire les sauvegardes en fonction des options de rétention.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez la rétention à 2 sauvegardes complètes
Plus d’informations sur la rétention sont disponibles dans la section Retention .
Configurer le chiffrement du dépôt
Le dépôt sera configuré avec un type de chiffrement et une clé afin de démontrer le chiffrement. Le chiffrement est toujours effectué côté client, même si le type de dépôt (par exemple S3 ou autre magasin d’objets) prend en charge le chiffrement.
Il est important d’utiliser une phrase secrète longue et aléatoire pour la clé de chiffrement. Une bonne manière de la générer consiste à exécuter : openssl rand -base64 48.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez le chiffrement du dépôt pgBackRest
NOTE :
Les paramètres de chiffrement sont placés dans la section [global], ci-dessus, afin que la commande info puisse lire toutes les stanzas. Sans l’option stanza, la commande info ne lit les paramètres de chiffrement que dans la section [global], de sorte que les paramètres de chiffrement configurés par stanza nécessitent l’option stanza pour lire une stanza chiffrée.
Une fois que le dépôt a été configuré et que le stanza a été créé et vérifié, les paramètres de chiffrement du dépôt ne peuvent pas être modifiés.
Créer la stanza
La commande stanza-create doit être exécutée pour initialiser la stanza. Il est recommandé d’exécuter la commande check après stanza-create afin de vérifier que l’archivage et les sauvegardes sont correctement configurés.
pg-primary ⇒ Créer la stanza et vérifier la configuration
Vérifier la configuration
La commande check vérifie que pgBackRest et le paramètre archive_command sont correctement configurés pour l’archivage et les sauvegardes du stanza spécifié. Elle tente de vérifier tous les dépôts et bases de données configurés pour l’hôte sur lequel la commande est exécutée. Elle détecte les mauvaises configurations, en particulier celles relatives à l’archivage, qui entraînent des sauvegardes incomplètes car des segments WAL requis n’ont pas atteint l’archive. La commande peut être exécutée sur l’hôte PostgreSQL ou sur l’hôte dépôt. Elle peut également être exécutée sur l’hôte de basculement, toutefois, comme les opérations pg_switch_xlog()/pg_switch_wal() ne peuvent pas être effectuées sur le basculement, la commande ne testera que la configuration du dépôt.
Notez que pg_create_restore_point('pgBackRest Archive Check') et pg_switch_xlog()/pg_switch_wal() sont appelés pour forcer PostgreSQL à archiver un segment WAL.
pg-primary ⇒ Vérifier la configuration
Optimisation des performances
pgBackRest dispose de plusieurs options de performance qui ne sont pas activées par défaut afin de préserver la compatibilité descendante du dépôt. Toutefois, lors de la création d’un nouveau dépôt, les options suivantes sont recommandées. Elles peuvent également être utilisées sur un dépôt existant, à condition de noter que les versions plus anciennes de pgBackRest ne seront pas en mesure de lire le dépôt. Cette incompatibilité dépend de la date d’introduction de la fonctionnalité, comme indiqué dans la liste ci-dessous.
compress-type- détermine l’algorithme de compression utilisé par les commandesbackupetarchive-push. La valeur par défaut estgz(Gzip), maiszst(Zstandard) est recommandé car il est bien plus rapide et offre une compression similaire àgz.zstest pris en charge par l’optioncompress-typedepuis v2.27 . Voir Type de compression pour plus de détails.repo-bundle- combine les petits fichiers lors de la sauvegarde afin de économiser de l’espace et d’améliorer la vitesse des commandesbackupetrestore, notamment sur des magasins d’objets tels que S3. L’optionrepo-bundlea été introduite dans v2.39 . Voir Regroupement de fichiers pour plus de détails.repo-block- stocke uniquement les parties des fichiers qui ont changé plutôt que le fichier entier lors desdiff/incrbackup. Cela permet d’économiser de l’espace et d’accroître la vitesse de labackup. L’optionrepo-blocka été introduite dans v2.46 , mais une version d’au moins v2.52.1 est recommandée. Voir Incrémentation par bloc pour plus de détails.
D’autres options de performance ne sont pas activées par défaut car elles nécessitent une configuration supplémentaire ou car la valeur par défaut est sûre (mais non optimale). Ces options sont disponibles dans toutes les versions v2 de pgBackRest.
process-max- détermine le nombre de processus utilisés pour les commandes. La valeur par défaut est 1, qui est presque jamais appropriée. Chaque commande utiliseprocess-maxde manière différente ; reportez-vous à la documentation de chaque commande pour plus de détails sur son utilisation.archive-async- archive les fichiers WAL dans le dépôt par lots, ce qui accroît considérablement la vitesse d’archivage. Il n’est pas activé par défaut car il nécessite la création d’un chemin d’épissage. Consultez Archivage asynchrone pour plus de détails.backup-standby- effectue la sauvegarde sur une instance secondaire plutôt que sur l’instance principale afin de réduire la charge sur cette dernière. Il n’est pas activé par défaut car il nécessite une configuration supplémentaire et la présence d’une ou plusieurs instances secondaires. Consultez Sauvegarde depuis une instance secondaire pour plus de détails.
Effectuer une sauvegarde
Par défaut, pgBackRest attend la prochaine vérification planifiée avant de démarrer une sauvegarde. Selon les paramètres checkpoint_timeout et checkpoint_segments dans PostgreSQL, il peut s’écouler assez de temps avant qu’une vérification ne soit terminée et que la sauvegarde puisse commencer. En général, il est préférable de définir start-fast=y afin que la sauvegarde démarre immédiatement. Cela force une vérification, mais comme les sauvegardes sont généralement exécutées une fois par jour, une vérification supplémentaire n’a pas d’impact notable sur les performances. Toutefois, sur des clusters très chargés, il peut être préférable de passer --start-fast en ligne de commande au besoin.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure la reprise rapide de la sauvegarde
Pour effectuer une sauvegarde du cluster PostgreSQL, exécutez pgBackRest avec la commande backup.
pg-primary ⇒ Effectuer une sauvegarde du cluster de démonstration
Par défaut, pgBackRest tente d’exécuter une sauvegarde incrémentielle. Toutefois, une sauvegarde incrémentielle doit être basée sur une sauvegarde complète, et comme aucune sauvegarde complète n’existait, pgBackRest a exécuté une sauvegarde complète à la place.
L’option type peut être utilisée pour spécifier une sauvegarde complète ou une sauvegarde différentielle.
pg-primary ⇒ Sauvegarde différentielle du cluster demo
Cette fois-ci, aucun avertissement n’a été affiché car une sauvegarde complète existait déjà. Bien qu’une sauvegarde incrémentielle puisse être basée sur une sauvegarde complète ou une sauvegarde différentielle, une sauvegarde différentielle doit obligatoirement être basée sur une sauvegarde complète. Une sauvegarde complète peut être effectuée en exécutant la commande backup avec --type=full.
Pendant une sauvegarde en ligne, pgBackRest attend que les segments WAL nécessaires à la cohérence de la sauvegarde soient archivés. Cette durée d’attente est régulée par l’option pgBackRest archive-timeout qui vaut 60 secondes par défaut. Si l’archivage d’un segment individuel est connu pour prendre plus de temps, cette option doit être augmentée.
Planifier une sauvegarde
Les sauvegardes peuvent être planifiées à l’aide d’utilitaires tels que cron.
Dans l’exemple suivant, deux tâches cron sont configurées pour s’exécuter ; les sauvegardes complètes sont planifiées à 6 h 30 tous les dimanches, tandis que les sauvegardes différentielles sont planifiées à 6 h 30 du lundi au samedi. Si ce fichier crontab est installé pour la première fois en milieu de semaine, pgBackRest exécutera une sauvegarde complète lors de la première exécution de la tâche différentielle, suivie d’une sauvegarde différentielle le lendemain.
Une fois les sauvegardes planifiées, il est important de configurer la rétention afin que les sauvegardes soient expirées selon un calendrier régulier, voir Retention .
Informations de sauvegarde
Utilisez la commande info pour obtenir des informations sur les sauvegardes.
pg-primary ⇒ Obtenir les informations sur le cluster de démonstration
La commande info s’applique à une seule stanza ou à toutes les stanzas. La sortie texte est la valeur par défaut et fournit un résumé lisible par l’humain des sauvegardes pour la ou les stanzas demandées. Ce format peut évoluer à tout moment dans une version.
Pour une sortie lisible par machine, utilisez --output=json. La sortie JSON contient bien plus d’informations que la sortie texte et est maintenue stable, sauf en cas de bug.
Pour accélérer l’exécution, restreindre la sortie à l’information de progression uniquement en spécifiant --detail-level=progress. Notez que cela ignore toutes les vérifications sauf la disponibilité de la stanza.
Chaque stanza dispose d’une section distincte et il est possible de limiter la sortie à une seule stanza à l’aide de l’option --stanza. La stanza ‘status’ indique brièvement l’état de santé de la stanza. Si cette valeur est ‘ok’, pgBackRest fonctionne normalement. Si plusieurs dépôts sont configurés, une valeur de ‘mixed’ indique que la stanza n’est pas dans un état sain sur un ou plusieurs dépôts ; dans ce cas, l’état de la stanza sera détaillé par dépôt. Dans les cas où une erreur s’est produite sur un dépôt sans correspondre à un code d’erreur connu, un code d’erreur de ‘other’ sera utilisé et les détails complets de l’erreur seront fournis. La ‘wal archive min/max’ affiche le WAL minimum et maximum actuellement stockés dans l’archive et, dans le cas de plusieurs dépôts, sera rapportée sur l’ensemble des dépôts sauf si l’option --repo est définie. Notez qu’il peut y avoir des lacunes dues aux politiques de rétention des archives ou à d’autres raisons.
Les messages ‘backup/expire running’ et/ou ‘restore running’ s’affichent aux côtés des informations ‘status’ si l’une quelconque de ces commandes est actuellement en cours d’exécution sur l’hôte. La progression par répertoire sera également indiquée dans la sortie texte, et un tableau ‘repo’ sera inclus dans la sortie JSON.
Les sauvegardes sont affichées du plus ancien au plus récent. La sauvegarde la plus ancienne sera toujours une sauvegarde complète (indiquée par un F à la fin de l’étiquette), mais la sauvegarde la plus récente peut être complète, différentielle (se terminant par D) ou incrémentielle (se terminant par I).
Le ‘timestamp start/stop’ définit la période pendant laquelle la sauvegarde a été exécutée. Le ‘timestamp stop’ peut être utilisé pour déterminer la sauvegarde à utiliser lors d’une restauration à un instant donné. Plus d’informations sur la restauration à un instant donné sont disponibles dans la section Restauration à un instant donné
.
Le ‘wal start/stop’ définit la plage de WAL nécessaire pour rendre la base de données cohérente lors d’une restauration. La commande backup s’assurera que cette plage de WAL se trouve dans l’archive avant de se terminer.
La ‘database size’ correspond à la taille totale non compressée de la base de données, tandis que la ‘database backup size’ représente la quantité de données à sauvegarder réellement ; elles sont identiques pour les sauvegardes complètes.
Le ‘repo’ indique dans quel dépôt se trouve cette sauvegarde. Le ‘backup set size’ inclut tous les fichiers de cette sauvegarde ainsi que toutes les sauvegardes référencées dans le dépôt nécessaires à la restauration de la base de données à partir de cette sauvegarde, tandis que le ‘backup size’ inclut uniquement les fichiers de cette sauvegarde (ceux-ci seront également identiques pour les sauvegardes complètes). Les tailles des dépôts reflètent les tailles des fichiers compressés si la compression est activée dans pgBackRest.
Le ‘backup reference total’ résume la liste des sauvegardes supplémentaires nécessaires pour effectuer la restauration de cette sauvegarde. Utilisez l’option --set pour afficher la liste complète de référence.
Restaurer une sauvegarde
Les sauvegardes peuvent vous protéger contre plusieurs scénarios de catastrophe, dont les plus fréquents sont les pannes matérielles et la corruption des données. La méthode la plus simple pour simuler une corruption de données consiste à supprimer un fichier important du cluster PostgreSQL.
pg-primary ⇒ Arrêtez le cluster de démonstration et supprimez le fichier pg_control
Le démarrage du cluster sans ce fichier important entraînera une erreur.
pg-primary ⇒ Tentative de démarrage du cluster démo corrompu
Pour restaurer une sauvegarde du cluster PostgreSQL, exécutez pgBackRest avec la commande restore. Le cluster doit être arrêté (dans ce cas, il est déjà arrêté) et tous les fichiers doivent être supprimés du répertoire de données PostgreSQL.
pg-primary ⇒ Supprimer les anciens fichiers du cluster de démonstration
pg-primary ⇒ Effectuer la restauration du cluster de démonstration et démarrer PostgreSQL
Cette fois, le cluster a démarré correctement car la restauration a remplacé le fichier pg_control manquant.
Plus d’informations sur la commande restore sont disponibles dans la section Restauration
.
Surveillance
La surveillance est une composante essentielle de tout système de production. De nombreuses outils sont disponibles, et pgBackRest peut être surveillé sur l’un d’entre eux avec un peu d’effort.
pgBackRest peut produire des informations sur le dépôt au format JSON, qui inclut la liste de toutes les sauvegardes pour chaque stanza ainsi que les informations sur l’archive WAL.
En PostgreSQL
La commande PostgreSQL COPY permet de charger les informations de pgBackRest dans une table. L’exemple suivant encapsule cette logique dans une fonction pouvant être utilisée pour effectuer des requêtes en temps réel.
pg-primary ⇒ Charger la fonction d’information pgBackRest pour PostgreSQL
À présent, la fonction monitor.pgbackrest_info() peut être utilisée pour déterminer l’heure de la dernière sauvegarde réussie et le WAL archivé pour une stanza.
pg-primary ⇒ Interroger l’heure de la dernière sauvegarde réussie et des journaux WAL archivés
Utilisation de jq
jq est un utilitaire en ligne de commande permettant d’extraire facilement des données depuis des fichiers JSON.
pg-primary ⇒ Installer l’utilitaire jq
À présent, jq peut être utilisé pour interroger l’heure de la dernière sauvegarde réussie pour un stanza.
pg-primary ⇒ Requête le moment de la dernière sauvegarde réussie
Ou le dernier WAL archivé.
pg-primary ⇒ Requête du dernier WAL archivé
NOTE :
Cette syntaxe nécessite jq v1.5.
NOTE :
jq peut arrondir des nombres élevés tels que les identifiants système. Testez vos requêtes avec soin.
sauvegarde
Lorsque plusieurs dépôts sont configurés, pgBackRest effectuera la sauvegarde vers le dépôt de priorité la plus élevée (par exemple repo1) sauf si l’option --repo est spécifiée.
pgBackRest ne dispose pas de planificateur intégré, il est donc préférable de l’exécuter depuis cron ou un autre mécanisme de planification.
Consultez Effectuer une sauvegarde pour plus de détails et d’exemples.
Regroupement de fichiers
Regrouper les fichiers dans le dépôt permet de gagner du temps lors de la sauvegarde et de libérer de l’espace dans le dépôt. Cet avantage est particulièrement marqué lorsque le dépôt est stocké sur un magasin d’objets comme S3 ou sur des systèmes de fichiers à grandes tailles de bloc. Le temps de création par fichier est plus élevé sur les magasins d’objets, et des fichiers très petits peuvent coûter autant à stocker qu’un fichier plus volumineux.
La fonctionnalité de regroupement de fichiers est activée avec l’option repo-bundle.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure repo1-bundle
Une sauvegarde complète sans regroupement de fichiers comportera plus de 1000 fichiers dans le chemin de sauvegarde, mais avec le regroupement, le nombre total de fichiers est fortement réduit. Un avantage supplémentaire est que les fichiers de taille nulle ne sont pas stockés (sauf dans le manifeste), contrairement à une sauvegarde normale où chaque fichier de taille nulle est stocké individuellement.
pg-primary ⇒ Effectuer une sauvegarde complète
pg-primary ⇒ Vérifier le total des fichiers
Les options repo-bundle-size et repo-bundle-limit peuvent être utilisées pour le réglage, bien que les valeurs par défaut soient optimales dans la plupart des cas.
Bien que le regroupement de fichiers soit généralement plus efficace, le désavantage réside dans la difficulté d’accès manuel aux fichiers depuis le dépôt. Il peut ne pas être adapté aux stockages à déduplication, car chaque sauvegarde complète organise les fichiers dans les paquets de manière différente. Enfin, les paquets de fichiers ne peuvent pas être repris, veillez donc à ne pas définir repo-bundle-limit trop élevé.
Incrémentation par bloc
Les sauvegardes incrémentielles par bloc économisent de l’espace en ne stockant que les parties d’un fichier modifiées depuis la sauvegarde précédente, plutôt que le fichier entier.
La fonctionnalité de sauvegarde incrémentielle par bloc est activée avec l’option repo-block et fonctionne de manière optimale lorsqu’elle est activée pour toutes les types de sauvegarde. Le regroupement des fichiers doit également être activé.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure repo1-block
Annotations de sauvegarde
Les utilisateurs peuvent attacher des paires clé/valeur explicatives à la sauvegarde. Cette option peut être utilisée plusieurs fois pour attacher plusieurs annotations.
pg-primary ⇒ Effectuer une sauvegarde complète avec annotations
Les annotations sont produites par la sortie texte de la commande info lorsque une sauvegarde est spécifiée avec --set, et apparaissent toujours dans la sortie JSON.
pg-primary ⇒ Obtenir les informations sur le cluster de démonstration
Les annotations incluses avec la commande backup peuvent être ajoutées, modifiées ou supprimées ultérieurement à l’aide de la commande annotate.
pg-primary ⇒ Modifier les annotations de sauvegarde
rétention
En général, il est préférable de conserver autant de sauvegardes que possible afin de disposer d’une fenêtre plus étendue pour la restauration à un instant donné Restauration à un instant donné , mais des contraintes pratiques telles que l’espace disque doivent également être prises en compte. Les options de rétention suppriment automatiquement les sauvegardes anciennes une fois qu’elles ne sont plus nécessaires.
pgBackRest effectue la rotation des sauvegardes complètes selon le type de rétention, qui peut être défini par un nombre ou une période de temps. Lorsqu’un nombre est spécifié, l’expiration n’est pas liée à la date de création des sauvegardes, mais au nombre de sauvegardes à conserver. Les sauvegardes différentielles sont basées sur un nombre, mais sont toujours expirées lorsque la sauvegarde complète dont elles dépendent l’est. Les sauvegardes incrémentielles ne sont pas expirées indépendamment par rétention — elles sont toujours expirées en même temps que leur sauvegarde complète ou différentielle associée. Pour plus de détails et des exemples, reportez-vous aux sections Rétention des sauvegardes complètes et Rétention des sauvegardes différentielles .
L’archive WAL est conservée par défaut pour les sauvegardes n’ayant pas expiré, mais, bien que non recommandé, ce délai peut être modifié par dépôt à l’aide de l’option retention-archive. Voir la section Archive Retention pour les détails et exemples.
La commande expire s’exécute automatiquement après chaque sauvegarde réussie et peut également être exécutée par l’utilisateur. Lorsqu’elle est exécutée par l’utilisateur, l’expiration s’effectue selon les paramètres de rétention définis pour chaque dépôt configuré. Si l’option --repo est fournie, l’expiration s’applique uniquement au dépôt spécifié. L’expiration peut également être limitée par l’utilisateur à un jeu de sauvegarde spécifique à l’aide de l’option --set, et, sauf si l’option --repo est spécifiée, tous les dépôts seront recherchés et tous ceux correspondant aux critères seront supprimés. Il convient de noter que la planification de rétention des archives sera vérifiée et appliquée chaque fois que la commande expire est exécutée.
Rétention des sauvegardes complètes
L’option repo1-retention-full-type détermine la manière dont l’option repo1-retention-full est interprétée : soit comme le nombre de sauvegardes complètes à conserver, soit comme le nombre de jours pendant lesquels conserver les sauvegardes complètes. Une nouvelle sauvegarde doit être terminée avant qu’une expiration ne puisse se produire — cela signifie que si repo1-retention-full-type=count et repo1-retention-full=2, alors trois sauvegardes complètes seront conservées avant que la plus ancienne ne soit supprimée, ou que si repo1-retention-full-type=time et repo1-retention-full=20, alors une sauvegarde complète d’au moins 20 jours d’âge doit exister avant qu’une expiration ne puisse avoir lieu.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure repo1-retention-full
Sauvegarde repo1-retention-full=2 mais actuellement, il n’existe qu’une seule sauvegarde complète, donc la prochaine sauvegarde complète à exécuter n’expirera aucune sauvegarde complète.
pg-primary ⇒ Effectuer une sauvegarde complète
L’archive est expirée car des segments WAL ont été générés avant la sauvegarde la plus ancienne. Ces segments ne sont pas utiles pour la récupération — seuls les segments WAL générés après une sauvegarde peuvent être utilisés pour récupérer cette sauvegarde.
pg-primary ⇒ Effectuer une sauvegarde complète
La sauvegarde complète 20260817-045036F a expiré et la rétention des archives est basée sur 20260817-045058F, qui est désormais la sauvegarde complète la plus ancienne.
Rétention des sauvegardes différentielles
Définissez repo1-retention-diff sur le nombre de sauvegardes différentielles requises. Les sauvegardes différentielles ne dépendent que de la dernière sauvegarde complète, il est donc possible de créer un ensemble « en rouleau » de sauvegardes différentielles pour la dernière journée ou plus. Cela permet des restaurations rapides à des points récents dans le temps tout en réduisant la consommation globale d’espace.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure repo1-retention-diff
Avec repo1-retention-diff=1, deux sauvegardes différentielles doivent être effectuées avant que l’une d’elles n’expire. Une sauvegarde incrémentielle est ajoutée pour illustrer l’expiration incrémentielle, qui dépend ici de l’expiration de la sauvegarde différentielle.
pg-primary ⇒ Effectuer des sauvegardes différentielles et incrémentielles
Effectuer maintenant une sauvegarde différentielle expire les sauvegardes différentielles et incrémentielles précédentes, ne laissant ainsi qu’une seule sauvegarde différentielle.
pg-primary ⇒ Effectuer une sauvegarde différentielle
Rétention des archives
Bien que pgBackRest supprime automatiquement les segments WAL archivés lors de l’expiration des sauvegardes (le comportement par défaut expire les WAL des sauvegardes complètes en fonction de l’option repo1-retention-full), il peut être utile d’expirer l’archive de manière plus agressive afin de libérer de l’espace disque. Notez que les sauvegardes complètes sont traitées comme des sauvegardes différentielles pour l’application de la rétention des archives différentielles.
L’expiration de l’archive ne supprimera jamais les segments WAL nécessaires à la cohérence d’une sauvegarde. Toutefois, comme la récupération à un point donné (PITR) ne fonctionne qu’avec un flux WAL continu, une attention particulière doit être portée lors de l’expiration agressive de l’archive en dehors du processus normal d’expiration des sauvegardes. Pour déterminer quels éléments seront supprimés sans effectuer réellement l’expiration, l’option dry-run peut être fournie en ligne de commande avec la commande expire.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure repo1-retention-diff
pg-primary ⇒ Effectuer une sauvegarde différentielle
pg-primary ⇒ Expire archive
La sauvegarde différentielle 20260817-045100F_20260817-045104D contient des segments WAL qui doivent être conservés pour assurer la cohérence des sauvegardes plus anciennes, même si elles ne peuvent plus être restaurées ultérieurement avec une récupération à un point précis (PITR). Les segments WAL générés après 20260817-045100F_20260817-045104D mais avant 20260817-045100F_20260817-045106D sont supprimés. Les segments WAL générés après la nouvelle sauvegarde 20260817-045100F_20260817-045106D sont conservés et peuvent être utilisés pour une récupération à un point précis (PITR).
Étant donné que les sauvegardes complètes sont considérées comme des sauvegardes différentielles afin de déterminer la rétention des archives différentielles, si une sauvegarde complète est désormais effectuée avec les mêmes paramètres, seule l’archive correspondante à cette sauvegarde complète est conservée pour la récupération à un instant donné.
restauration
La commande de restauration sélectionne automatiquement la dernière sauvegarde du premier dépôt où des sauvegardes existent (voir Démarrage rapide - Restaurer une sauvegarde
). L’ordre dans lequel les dépôts sont vérifiés est déterminé par le paramètre pgbackrest.conf (par exemple, repo1 sera vérifié avant repo2). Pour sélectionner un dépôt spécifique, l’option --repo peut être utilisée (par exemple, --repo=1). L’option --set peut être utilisée si une sauvegarde autre que la plus récente est souhaitée.
Lorsqu’une restauration à un instant donné de --type=time ou --type=lsn est spécifiée, le temps cible ou le numéro LSN cible doit être précisé à l’aide de l’option --target. Si aucune sauvegarde n’est spécifiée via l’option --set, les dépôts configurés seront examinés, dans l’ordre, à la recherche d’une sauvegarde contenant le temps ou le numéro LSN demandés. Si aucune sauvegarde correspondante n’est trouvée, la dernière sauvegarde du premier dépôt contenant des sauvegardes sera utilisée pour --type=time, tandis qu’aucune sauvegarde ne sera sélectionnée pour --type=lsn. Pour les autres types de restauration à un instant donné, par exemple xid, l’option --set doit être fournie si le temps cible est antérieur à la dernière sauvegarde. Voir Restauration à un instant donné
pour plus de détails et d’exemples.
Les slots de réplication ne sont pas inclus, conformément à la recommandation de PostgreSQL. Consultez Sauvegarde du répertoire de données dans la documentation PostgreSQL pour plus d’informations.
Les sections suivantes présentent des fonctionnalités supplémentaires de la commande restore.
Propriétaire du fichier
Si un restore est exécuté en tant qu’utilisateur non privilégié (scénario typique), tous les fichiers restaurés appartiendront à l’utilisateur/groupe exécutant pgBackRest. Si des fichiers existants ne sont pas possédés par l’utilisateur/groupe exécutant, une erreur se produira si la propriété ne peut pas être mise à jour pour correspondre à l’utilisateur/groupe exécutant. Dans ce cas, la propriété des fichiers devra être mise à jour par un utilisateur ayant des privilèges avant de pouvoir réessayer la restauration.
Si un restore est exécuté en tant qu’utilisateur root, pgBackRest tentera de recréer la propriété enregistrée dans le manifeste au moment de la sauvegarde. Seuls les noms d’utilisateur/groupe sont stockés dans le manifeste, donc les mêmes noms doivent exister sur l’hôte de restauration pour que cela fonctionne. Si le nom d’utilisateur/groupe ne peut pas être trouvé localement, l’utilisateur/groupe du répertoire de données PostgreSQL sera utilisé, puis root si l’utilisateur/groupe du répertoire de données ne peut pas être mappé à un nom.
Option Delta
Restaurer une sauvegarde
dans Mise en route rapide
nécessite que le répertoire du cluster de base de données soit nettoyé avant la restore de restauration. L’option delta permet à pgBackRest de déterminer automatiquement quels fichiers du répertoire du cluster de base de données peuvent être conservés et quels fichiers doivent être restaurés à partir de la sauvegarde — elle supprime également les fichiers absents du manifeste de sauvegarde, ce qui permet d’éliminer les modifications divergentes. Cette opération est réalisée en calculant un hachage cryptographique SHA-1
pour chaque fichier du répertoire du cluster de base de données. Si le hachage SHA-1 ne correspond pas au hachage stocké dans la sauvegarde, ce fichier sera restauré. Cette opération est particulièrement efficace lorsqu’elle est combinée avec l’option process-max. Comme le serveur PostgreSQL est arrêté pendant la restauration, un plus grand nombre de processus peut être utilisé que lors d’une sauvegarde, où le serveur PostgreSQL est en cours d’exécution.
pg-primary ⇒ Arrêtez le cluster de démonstration, effectuez une restauration incrémentielle
pg-primary ⇒ Redémarrer PostgreSQL
Restauration des bases de données sélectionnées
Il peut arriver que l’on souhaite restaurer sélectivement des bases de données spécifiques à partir d’une sauvegarde de cluster. Cela peut être utile pour des raisons de performance ou pour déplacer des bases sélectionnées vers une machine qui ne dispose pas d’espace suffisant pour restaurer l’intégralité de la sauvegarde du cluster.
Pour démontrer cette fonctionnalité, deux bases de données sont créées : test1 et test2.
pg-primary ⇒ Créer deux bases de données de test
Chaque base de données de test sera initialisée avec des tables et des données afin de démontrer que la restauration sélective fonctionne.
pg-primary ⇒ Créer une table de test dans chaque base de données
Une nouvelle sauvegarde est exécutée afin que pgBackRest prenne connaissance des nouveaux bases de données.
pg-primary ⇒ Effectuer une sauvegarde
L’une des principales raisons d’utiliser une restauration sélective est de conserver de l’espace. La taille de la base de données test1 est indiquée ici afin de pouvoir la comparer à l’utilisation du disque après une restauration sélective.
pg-primary ⇒ Afficher l’espace utilisé par la base test1
Si la base de données à restaurer n’est pas connue, utilisez l’option info de la commande set pour découvrir les bases de données faisant partie de l’ensemble de sauvegarde.
pg-primary ⇒ Afficher la liste des bases de données pour la sauvegarde
Arrêtez le cluster et effectuez une restauration uniquement de la base test2. Les bases de données intégrées (template0, template1 et postgres) sont toujours restaurées.
AVERTISSEMENT :
La récupération peut échouer sauf si --type=immediate est spécifié. Cela est dû au fait qu’une fois la cohérence atteinte, PostgreSQL signale les pages nulles comme des erreurs, même pour une écriture complète de page. Pour PostgreSQL ≥ 13, le paramètre ignore_invalid_pages peut être utilisé pour ignorer les pages non valides. Dans ce cas, il est important de vérifier les journaux après la récupération afin de s’assurer qu’aucune page non valide n’a été signalée dans les bases de données sélectionnées.
pg-primary ⇒ Restauration à partir de la dernière sauvegarde, incluant uniquement la base test2
Une fois la récupération terminée, la base de données test2 contiendra toutes les tables et les données précédemment créées.
pg-primary ⇒ Démontrer que la base de données test2 a été restaurée
La base de données test1, malgré une récupération réussie, n’est pas accessible. Cela est dû au fait que la base entière a été restaurée sous forme de fichiers creux initialisés à zéro. PostgreSQL peut appliquer correctement le WAL sur ces fichiers initialisés à zéro, mais la base de données dans son ensemble ne sera pas valide, car certains fichiers clés ne contiennent aucune donnée. Cette situation est volontaire, afin d’éviter que la base de données ne soit utilisée accidentellement alors qu’elle pourrait contenir des données partielles appliquées pendant la relecture du WAL.
pg-primary ⇒ Tenter de se connecter à la base de données test1 produira une erreur
Étant donné que la base de données test1 est restaurée avec des fichiers épars et initialisés à zéro, elle n’utilisera que l’espace nécessaire à la quantité de WAL écrite pendant la récupération. Bien que la quantité de WAL générée lors d’une sauvegarde et appliquée lors de la récupération puisse être importante, elle représente généralement une fraction réduite de la taille totale de la base de données, en particulier pour les grandes bases de données où cette fonctionnalité est le plus susceptible d’être utile.
Il est clair que la base de données test1 utilise bien moins d’espace disque lors d’une restauration sélective que si toute la base de données avait été restaurée.
pg-primary ⇒ Afficher l’espace utilisé par la base de données test1 après la récupération
À ce stade, la seule action pouvant être entreprise sur la base test1 invalide est drop database. pgBackRest ne supprime pas automatiquement la base de données, car cela n’est pas possible tant que la récupération n’est pas terminée et que le cluster n’est pas accessible.
pg-primary ⇒ Supprimer la base de données test1
À présent que la base de données test1 invalide a été supprimée, seules les bases de données test2 et les bases intégrées restent.
pg-primary ⇒ Liste des bases de données restantes
restauration à un instant donné
Restaurer une sauvegarde dans Démarrage rapide a effectué une récupération par défaut, qui consiste à rejouer toutes les transactions jusqu’à la fin du flux WAL. En cas de panne matérielle, il s’agit généralement du choix optimal, mais en cas de corruption des données (qu’elle soit due à une panne matérielle ou humaine), la restauration à un instant donné (PITR) est souvent plus appropriée.
La restauration à un instant donné (PITR) permet de rejouer les journaux d’écriture (WAL) à partir d’une sauvegarde jusqu’à un LSN, une heure, un identifiant de transaction ou un point de récupération spécifié. Pour les scénarios de récupération courants, la récupération basée sur le temps est sans doute la plus utile. Un scénario de récupération typique consiste à restaurer une table supprimée par erreur ou des données supprimées par erreur. La récupération d’une table supprimée est plus spectaculaire, aussi est-elle prise comme exemple ici, mais les données supprimées seraient récupérées exactement de la même manière.
pg-primary ⇒ Créer une table avec des données très importantes
Il est important de représenter l’heure selon le calcul de PostgreSQL et d’inclure les décalages de fuseau horaire. Cela réduit la possibilité de conversions de fuseau horaire non souhaitées et d’un résultat de récupération inattendu.
pg-primary ⇒ Obtenir l’heure depuis PostgreSQL
À présent que l’heure a été enregistrée, la table est supprimée. En pratique, déterminer l’heure exacte à laquelle la table a été supprimée est bien plus difficile qu’à l’exemple présenté. Il se peut qu’il ne soit pas possible de déterminer l’heure exacte, mais une analyse forensique devrait toutefois pouvoir s’en approcher.
pg-primary ⇒ Supprimer la table importante
Si la mauvaise sauvegarde est sélectionnée pour la restauration, la récupération jusqu’à la cible de temps requise échouera. Pour illustrer ce cas, une nouvelle sauvegarde incrémentielle est effectuée alors que important_table n’existe pas.
pg-primary ⇒ Effectuer une sauvegarde incrémentielle
Il ne sera pas possible de récupérer la table perdue à partir de cette sauvegarde, car PostgreSQL ne peut avancer que vers l’avant, pas vers l’arrière.
pg-primary ⇒ Tentative de récupération à partir d’une sauvegarde incorrecte
Une méthode fiable consiste à autoriser pgBackRest à sélectionner automatiquement une sauvegarde pouvant être restaurée jusqu’à l’instant cible, c’est-à-dire une sauvegarde terminée avant l’instant spécifié.
NOTE :
pgBackRest ne peut pas sélectionner automatiquement une sauvegarde lorsque le type de restauration est xid ou name.
pg-primary ⇒ Effectuer la restauration du cluster de démonstration sur 2026-08-17 04:51:24.23782+00
pgBackRest a généré les paramètres de récupération dans postgresql.auto.conf afin que PostgreSQL puisse être démarré immédiatement. %f est le moyen par lequel PostgreSQL indique le segment WAL dont il a besoin, et %p est l’emplacement où il doit être copié. Une fois la récupération de PostgreSQL terminée, la table existera à nouveau et pourra être interrogée.
pg-primary ⇒ Démarrer PostgreSQL et vérifier que la table importante existe
Le journal PostgreSQL contient également des informations précieuses. Il indique l’heure et la transaction où la récupération s’est arrêtée, ainsi que l’heure de la dernière transaction appliquée.
pg-primary ⇒ Examinez la sortie des journaux PostgreSQL
Supprimer une stanza
La commande stanza-delete supprime les données du dépôt associées à un stanza.
AVERTISSEMENT :
Utilisez cette commande avec précaution — elle supprimera définitivement toutes les sauvegardes et archives du dépôt pgBackRest pour le stanza spécifié.
Pour supprimer une stanza :
- Arrêtez le cluster PostgreSQL associé à la stanza (ou utilisez –force pour l’ignorer).
- Exécutez la commande
stopsur l’hôte où la commandestanza-deletesera exécutée. - Exécutez la commande
stanza-delete.
Une fois la commande exécutée avec succès, il incombe à l’utilisateur de supprimer la stanza de tous les fichiers de configuration pgBackRest et/ou des variables d’environnement.
Un stanza ne peut être supprimé que d’un dépôt à la fois. Pour supprimer le stanza de plusieurs dépôts, répétez la commande stanza-delete pour chaque dépôt tout en spécifiant l’option --repo.
pg-primary ⇒ Arrêtez le cluster PostgreSQL à supprimer
pg-primary ⇒ Arrêtez pgBackRest pour la stanza
pg-primary ⇒ Supprimer le stanza depuis un dépôt
Dépôts multiples
Plusieurs dépôts peuvent être configurés, comme illustré dans Prise en charge S3 . Un avantage potentiel est la possibilité de disposer d’un dépôt local pour des restaurations rapides et d’un dépôt distant pour la redondance.
Certaines commandes, par exemple stanza-create
/stanza-upgrade
, fonctionnent automatiquement avec tous les dépôts configurés, tandis que d’autres, par exemple stanza-delete
, nécessitent la spécification d’un dépôt à l’aide de l’option repo.
Notez que l’option repo n’est pas obligatoire lorsqu’uniquement repo1 est configuré, afin de préserver la compatibilité descendante. Toutefois, l’option repo est obligatoire lorsqu’un seul dépôt est configuré, par exemple repo2. Ceci vise à éviter la rupture de commande en cas d’ajout ultérieur d’un nouveau dépôt.
La commande archive-push poussera toujours les journaux WAL vers l’archive dans tous les dépôts configurés. Si un dépôt n’est pas accessible, les journaux WAL seront tout de même poussés vers les autres dépôts. Toutefois, pour que cela fonctionne efficacement, archive-async=y doit être activé ; sinon, les autres dépôts ne pourront avancer que d’un segment WAL par rapport au dépôt inatteignable. Notez également qu’en cas d’impossibilité de pousser les journaux WAL vers n’importe quel dépôt, PostgreSQL ne supprimera pas ces journaux du répertoire pg_wal, ce qui peut entraîner la saturation du volume.
Les sauvegardes doivent être planifiées individuellement pour chaque dépôt. Dans de nombreuses situations, cela est souhaitable car les types de sauvegarde et la rétention varient d’un dépôt à l’autre. De même, les restaurations doivent préciser un dépôt. Il est généralement préférable de spécifier un dépôt à faible latence/coût, même si cela implique un temps de récupération plus long. Seule une vérification par test de restauration permettra de déterminer quel dépôt sera le plus efficace.
Prise en charge du magasin d’objets compatible Azure
pgBackRest prend en charge la localisation des dépôts dans des magasins d’objets compatibles Azure. Le conteneur utilisé pour stocker le dépôt doit être créé à l’avance — pgBackRest ne le fera pas automatiquement. Le dépôt peut être situé à la racine du conteneur (/), mais il est généralement préférable de le placer dans un sous-chemin afin de pouvoir stocker également des journaux ou d’autres données dans le conteneur sans conflit.
AVERTISSEMENT :
N’activez pas l’« espace de noms hiérarchique » car cela provoquera des erreurs lors de l’expiration.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez Azure
Les signatures d’accès partagé peuvent être utilisées en définissant l’option repo2-azure-key-type sur sas et l’option repo2-azure-key sur le jeton de signature d’accès partagé.
Les commandes sont exécutées exactement comme si le dépôt était stocké sur un disque local.
pg-primary ⇒ Créer la stanza
Le temps de création de fichier dans Azure est relativement lent, aussi la performance de backup/restore est améliorée en activant le regroupement de fichiers file bundling
.
pg-primary ⇒ Effectuer une sauvegarde du cluster de démonstration
Prise en charge du stockage d’objets compatible S3
pgBackRest prend en charge le positionnement des dépôts dans des magasins d’objets compatibles S3. Le bac utilisé pour stocker le dépôt doit être créé à l’avance — pgBackRest ne le fera pas automatiquement. Le dépôt peut être placé à la racine du bac (/), mais il est généralement préférable de le situer dans un sous-répertoire afin de pouvoir stocker également des journaux ou d’autres données dans le bac sans conflit.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez S3
NOTE :
La région et le point de terminaison devront être configurés selon l’emplacement du bac. Les valeurs indiquées ici correspondent à la région us-east-1.
Un rôle doit être créé pour exécuter pgBackRest et les autorisations du bac doivent être définies aussi restrictivement que possible. Si le rôle est associé à une instance dans AWS, pgBackRest récupérera automatiquement des identifiants temporaires lorsque repo3-s3-key-type=auto, ce qui signifie que les clés n’ont pas besoin d’être explicitement définies dans /etc/pgbackrest/pgbackrest.conf.
Politique Amazon S3 d’exemple qui restreint toutes les lectures et écritures au bac et au chemin du dépôt.
Les commandes sont exécutées exactement comme si le dépôt était stocké sur un disque local.
pg-primary ⇒ Créer la stanza
Le temps de création de fichier dans S3 est relativement lent, aussi la performance de backup/restore est améliorée en activant le regroupement de fichiers file bundling
.
pg-primary ⇒ Effectuer une sauvegarde du cluster de démonstration
Prise en charge SFTP
pgBackRest prend en charge le localisation des dépôts sur des hôtes SFTP. Le transfert de fichiers SFTP est relativement lent, aussi les commandes bénéficient-elles d’une augmentation de process-max afin de paralléliser le transfert de fichiers.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez SFTP
Lors de l’utilisation de SFTP, si libssh2 est compilé contre OpenSSH, repo4-sftp-public-key-file est facultatif.
pg-primary ⇒ Générer une paire de clés SSH pour la sauvegarde SFTP
sftp-server ⇒ Copier la clé publique de sauvegarde SFTP de pg-primary sur sftp-server
Les commandes sont exécutées exactement comme si le dépôt était stocké sur un disque local.
pg-primary ⇒ Ajouter l’empreinte du serveur SFTP au fichier known_hosts, car repo4-sftp-host-key-check-type est par défaut défini sur « strict »
pg-primary ⇒ Créer la stanza
pg-primary ⇒ Effectuer une sauvegarde du cluster de démonstration
Prise en charge du stockage d’objets compatible GCS
pgBackRest prend en charge la localisation des dépôts dans des magasins d’objets compatibles GCS. Le conteneur utilisé pour stocker le dépôt doit être créé à l’avance — pgBackRest ne le fera pas automatiquement. Le dépôt peut être situé à la racine du conteneur (/), mais il est généralement préférable de le placer dans un sous-répertoire afin de pouvoir stocker également des journaux ou d’autres données dans le conteneur sans conflit.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez le GCS
Lors de l’exécution sur GCE, définissez repo5-gcs-key-type=auto pour authentifier automatiquement à l’aide du compte de service de l’instance.
Les commandes sont exécutées exactement comme si le dépôt était stocké sur un disque local.
Le temps de création de fichier dans GCS est relativement lent, aussi la performance de backup/restore est améliorée en activant le regroupement de fichiers file bundling
.
Heure cible pour le dépôt
Le temps cible définit l’instant auquel les commandes lisent un dépôt sur un stockage versionné. Cela permet à la commande de lire le dépôt tel qu’il était à un instant donné, afin de récupérer des données supprimées ou corrompues par une erreur utilisateur ou un logiciel malveillant.
Le stockage versionné est pris en charge par S3, GCS et Azure, mais il est généralement désactivé par défaut. En plus d’activer la versioning, il peut être utile d’activer le verrouillage d’objets pour S3, ou la suppression progressive pour GCS ou Azure.
Lorsque l’option repo-target-time est spécifiée, l’option repo doit également être fournie. Il est probable que tous les types de dépôt ne prennent pas en charge la versionning, et il est généralement préférable de cibler un seul dépôt pour la récupération.
Notez que les comparaisons avec l’horodatage de stockage sont <= à l’horodatage fourni et que les millisecondes sont tronquées de l’horodatage lorsqu’elles sont fournies.
Pour démontrer cette fonctionnalité, la stanza demo dans le dépôt S3 est supprimée.
pg-primary ⇒ Supprimer le stanza dans le dépôt S3
Une fois le stanza supprimé, la commande info affichera le dépôt dans un état d’erreur.
pg-primary ⇒ Erreur lors de l’information
Toutefois, comme le stockage est versionné, il est possible d’examiner le dépôt à une époque antérieure à la suppression du stanza. Trouver l’instant cible peut s’avérer délicat selon la situation, mais dans ce cas, l’instant de suppression du stanza peut être déterminé en vérifiant quand backup.info a été supprimé.
pg-primary ⇒ Répertorier les versions de backup.info dans le bac
À présent, la commande info peut être exécutée avec une heure cible afin d’afficher le dépôt avant sa suppression.
pg-primary ⇒ Information avec heure cible
Si la sauvegarde requise est indiquée par la commande info, elle peut être restaurée en utilisant le même instant cible.
pg-primary ⇒ Restauration avec heure cible
Hôte dédié au dépôt
La configuration décrite dans Quickstart convient aux installations simples, mais pour les configurations d’entreprise, il est plus courant d’avoir un hôte dédié au dépôt, où sont stockées les sauvegardes et les fichiers d’archive WAL. Cette approche sépare les sauvegardes et l’archive WAL du serveur de base de données, de sorte que les défaillances de l’hôte de base de données aient un impact moindre. Il est toutefois recommandé d’utiliser un logiciel de sauvegarde traditionnel pour sauvegarder l’hôte du dépôt.
Sur les hôtes PostgreSQL, pg1-path doit être le chemin du cluster PostgreSQL local et aucune configuration pg1-host ne doit être définie. Lors de la configuration d’un hôte de dépôt, le fichier de configuration pgBackRest doit inclure l’option pg-host pour se connecter aux hôtes principaux et secondaires (le cas échéant). L’hôte de dépôt est le seul qui doit disposer d’une configuration pgBackRest connaissant plusieurs hôtes PostgreSQL. L’ordre n’a pas d’importance, par exemple pg1-path/pg1-host, pg2-path/pg2-host peut correspondre à un hôte principal ou secondaire.
Installation
Un nouvel hôte nommé repository est créé pour stocker les sauvegardes du cluster.
NOTE :
La version de pgBackRest installée sur l’hôte du dépôt doit correspondre exactement à la version installée sur l’hôte PostgreSQL.
L’utilisateur pgbackrest est créé pour posséder le dépôt pgBackRest. Tout utilisateur peut posséder le dépôt, mais il est préférable de ne pas utiliser postgres (le cas échéant) afin d’éviter toute confusion.
NOTE :
Lorsque pgBackRest est installé à partir d’un paquet, une configuration logrotate telle que /etc/logrotate.d/pgbackrest peut être fournie, qui effectue le rotation des journaux en tant qu’utilisateur spécifique via la directive su (par exemple su postgres postgres). Étant donné que les fichiers dans /var/log/pgbackrest sont possédés par l’utilisateur exécutant pgBackRest (ici pgbackrest), la directive su doit être mise à jour pour correspondre à cet utilisateur, sinon logrotate échouera avec une erreur de permission.
dépôt ⇒ Créer l’utilisateur pgbackrest
Installer pgBackRest à partir d’un paquet est préférable à la compilation à partir des sources. Lors de l’installation à partir d’un paquet, les autres instructions de cette section sont généralement inutiles, mais il se peut qu’un paquet omette de créer un répertoire ou applique des permissions incorrectes. Dans ce cas, il peut être nécessaire de créer manuellement les répertoires ou de mettre à jour les permissions.
Les paquets Debian/Ubuntu pour pgBackRest sont disponibles sur apt.PostgreSQL.org .
Si des paquets ne sont pas fournis pour votre distribution/version, vous pouvez compiler à partir des sources puis procéder à l’installation manuelle comme indiqué ici.
dépôt ⇒ Installer les dépendances
dépôt ⇒ Copier le binaire pgBackRest depuis l’hôte de compilation
pgBackRest nécessite des répertoires pour les journaux et la configuration, ainsi qu’un fichier de configuration.
dépôt ⇒ Créer le fichier de configuration pgBackRest et les répertoires
dépôt ⇒ Créer le dépôt pgBackRest
Configuration d’un accès SSH sans mot de passe
pgBackRest peut utiliser SSH sans mot de passe pour permettre la communication entre les hôtes. Il est également possible d’utiliser TLS, voir Configurer TLS .
dépôt ⇒ Créer une paire de clés pour l’hôte du dépôt
pg-primary ⇒ Créer une paire de clés pour l’hôte pg-primary
Échanger les clés entre le dépôt et pg-primary.
dépôt ⇒ Copiez la clé publique pg-primary vers le dépôt
pg-primary ⇒ Copier la clé publique du dépôt sur pg-primary
Testez que les connexions peuvent être établies depuis le dépôt vers pg-primary et inversement.
dépôt ⇒ Tester la connexion depuis le dépôt vers pg-primary
pg-primary ⇒ Tester la connexion depuis pg-primary vers le dépôt
NOTE :
ssh a été configuré pour autoriser uniquement l’exécution de pgBackRest via ssh sans mot de passe. Cela renforce la sécurité en cas de compromission d’un compte de service.
Configuration
L’hôte du dépôt doit être configuré avec l’hôte/utilisateur principal et le chemin de la base de données. Le principal sera configuré en tant que pg1 afin de permettre l’ajout ultérieur d’un serveur de secours.
dépôt : /etc/pgbackrest/pgbackrest.conf ⇒ Configurez pg1-host/pg1-host-user et pg1-path
L’hôte de base de données doit être configuré avec l’hôte/utilisateur du dépôt. La valeur par défaut de l’option repo1-host-user est pgbackrest. Si l’utilisateur postgres effectue des restaurations sur l’hôte du dépôt, il est préférable de ne pas autoriser également l’utilisateur postgres à effectuer des sauvegardes. Toutefois, l’utilisateur postgres peut lire directement le dépôt s’il appartient au même groupe que l’utilisateur pgbackrest.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configure repo1-host/repo1-host-user
La configuration de PostgreSQL peut être trouvée dans la section Configurer la sauvegarde archivée .
Les commandes sont exécutées de la même manière qu’avec une configuration à hôte unique, à ceci près que certaines commandes, telles que backup et expire, sont exécutées depuis l’hôte du dépôt plutôt que depuis l’hôte de la base de données.
Créer et vérifier une stanza
Créez le stanza dans le nouveau dépôt.
dépôt ⇒ Créer le stanza
Vérifiez que la configuration est correcte sur les hôtes de base de données et de dépôt. Plus d’informations sur la commande check sont disponibles dans Vérifier la configuration
.
pg-primary ⇒ Vérifier la configuration
dépôt ⇒ Vérifiez la configuration
Effectuer une sauvegarde
Pour effectuer une sauvegarde du cluster PostgreSQL, exécutez pgBackRest avec la commande backup sur l’hôte du dépôt.
dépôt ⇒ Sauvegarder le cluster de démonstration
Depuis la création d’un nouveau dépôt sur l’hôte du dépôt, l’avertissement indiquant que la sauvegarde incrémentielle passe à une sauvegarde complète a été émis.
Restaurer une sauvegarde
Pour effectuer une restauration du cluster PostgreSQL, exécutez pgBackRest avec la commande restore sur l’hôte de la base de données.
pg-primary ⇒ Arrêtez le cluster de démonstration, effectuez une restauration, puis redémarrez PostgreSQL
Sauvegarde / Restauration parallèle
pgBackRest propose un traitement parallèle afin d’améliorer les performances de compression et de transfert. Le nombre de processus à utiliser pour cette fonctionnalité est défini à l’aide de l’option --process-max.
Il est généralement préférable de ne pas utiliser plus de 25 % des processeurs disponibles pour la commande backup. Les sauvegardes n’ont pas besoin de s’exécuter aussi rapidement, à condition d’être effectuées régulièrement, et le processus de sauvegarde ne doit pas impacter les performances de la base de données, si possible.
La commande de restauration peut et doit utiliser tous les processeurs disponibles, car pendant une restauration le cluster PostgreSQL est arrêté et il n’y a généralement aucune autre tâche importante en cours sur l’hôte. Si l’hôte contient plusieurs clusters, cela doit être pris en compte lors de la configuration de la parallélisation de la restauration.
dépôt ⇒ Effectuer une sauvegarde avec un seul processus
dépôt : /etc/pgbackrest/pgbackrest.conf ⇒ Configurez pgBackRest pour utiliser plusieurs processus backup
dépôt ⇒ Effectuer une sauvegarde avec plusieurs processus
dépôt ⇒ Obtenir les informations de sauvegarde pour le cluster de démonstration
La performance de la dernière sauvegarde devrait être améliorée en utilisant plusieurs processus. Pour des sauvegardes très petites, la différence peut ne pas être très marquée, mais à mesure que la taille de la base de données augmente, les gains de temps deviennent plus importants.
Démarrage et arrêt
Si un serveur de secours est promu à des fins de test, ou si un cluster de test est restauré à partir d’une sauvegarde de production, il est recommandé de bloquer l’écriture de ces clusters dans les dépôts pgBackRest. Cette mesure peut être mise en œuvre à l’aide de la commande stop.
Les commandes qui écrivent et sont bloquées par stop sont : archive-push, backup, expire, stanza-create et stanza-upgrade. Notez que stanza-delete est une exception à cette règle (voir Supprimer une stanza
pour plus de détails).
pg-primary ⇒ Arrêt des commandes d’écriture pgBackRest
Les nouvelles commandes d’écriture pgBackRest ne s’exécuteront plus.
dépôt ⇒ Tentative de sauvegarde
Spécifiez l’option --force pour interrompre toute commande d’écriture pgBackRest en cours d’exécution. Cela inclut l’archive-get asynchrone (même si elle redémarre si PostgreSQL en a besoin). Si pgBackRest est déjà arrêté, un nouvel arrêt générera un avertissement.
pg-primary ⇒ Arrêtez à nouveau les services pgBackRest
Redémarrez les commandes d’écriture pgBackRest à l’aide de la commande start. Les commandes d’écriture en cours avant l’arrêt ne reprendront pas automatiquement, mais elles sont désormais autorisées à redémarrer.
pg-primary ⇒ Démarrer les commandes d’écriture pgBackRest
Il est également possible d’arrêter pgBackRest pour une seule stanza.
pg-primary ⇒ Arrête les commandes d’écriture pgBackRest pour la stanza demo
Les nouvelles commandes d’écriture pgBackRest pour la stanza spécifiée ne s’exécuteront plus.
dépôt ⇒ Tentative de sauvegarde
La stanza doit également être précisée lors du lancement des commandes d’écriture pgBackRest pour une seule stanza.
pg-primary ⇒ Démarrer les commandes d’écriture pgBackRest pour la stanza demo
Réplication
La réplication permet de créer plusieurs copies d’un cluster PostgreSQL (appelées réplicas) à partir d’un seul hôte principal. Les réplicas sont utiles pour équilibrer les lectures et assurer une redondance en cas de défaillance de l’hôte principal.
Installation
Un nouvel hôte nommé pg-standby est créé pour exécuter le serveur de secours.
Installer pgBackRest à partir d’un paquet est préférable à la compilation à partir des sources. Lors de l’installation à partir d’un paquet, les autres instructions de cette section sont généralement inutiles, mais il se peut qu’un paquet omette de créer un répertoire ou applique des permissions incorrectes. Dans ce cas, il peut être nécessaire de créer manuellement les répertoires ou de mettre à jour les permissions.
Les paquets Debian/Ubuntu pour pgBackRest sont disponibles sur apt.PostgreSQL.org .
Si des paquets ne sont pas fournis pour votre distribution/version, vous pouvez compiler à partir des sources puis procéder à l’installation manuelle comme indiqué ici.
pg-standby ⇒ Installer les dépendances
pg-standby ⇒ Copier le binaire pgBackRest depuis l’hôte de compilation
pgBackRest nécessite des répertoires pour les journaux et la configuration, ainsi qu’un fichier de configuration.
pg-standby ⇒ Créer le fichier de configuration et les répertoires pgBackRest
Configuration d’un accès SSH sans mot de passe
pgBackRest peut utiliser SSH sans mot de passe pour permettre la communication entre les hôtes. Il est également possible d’utiliser TLS, voir Configurer TLS .
pg-standby ⇒ Créer une paire de clés hôte pg-standby
Échanger les clés entre le dépôt et pg-standby.
dépôt ⇒ Copiez la clé publique pg-standby sur le dépôt
pg-standby ⇒ Copier la clé publique du dépôt sur pg-standby
Testez que les connexions peuvent être établies depuis le dépôt vers pg-standby et réciproquement.
dépôt ⇒ Tester la connexion depuis le dépôt vers pg-standby
pg-standby ⇒ Tester la connexion depuis pg-standby vers le dépôt
Standby chaud
Une station de secours active effectue la réplication à l’aide de l’archive WAL et autorise les requêtes en lecture seule.
La configuration de pgBackRest est très similaire à celle de pg-primary, sauf que le type de récupération standby sera utilisé pour maintenir le cluster en mode récupération lorsque la fin du flux WAL aura été atteinte.
pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez pgBackRest sur le serveur de secours
Le cluster de démonstration doit être créé (même s’il sera écrasé lors de la restauration) afin de générer les fichiers de configuration PostgreSQL.
pg-standby ⇒ Créer un cluster de démonstration
À présent, le serveur de secours peut être créé avec la commande restore.
IMPORTANT :
Si le cluster doit être promu sans devenir le nouveau principal (par exemple pour des rapports ou des tests), utilisez --archive-mode=off ou définissez archive_mode=off dans postgresql.conf afin de désactiver l’archivage. Si l’archivage n’est pas désactivé, le dépôt risque d’être pollué par des WAL qui peuvent compliquer les restaurations.
pg-standby ⇒ Effectuer la restauration du cluster de secours démo
La configuration est en cas de promotion du serveur de secours en serveur principal.
pg-standby:/etc/postgresql/17/demo/postgresql.conf ⇒ Configurez PostgreSQL
pg-standby ⇒ Démarrer PostgreSQL
Le journal PostgreSQL fournit des informations précieuses sur la récupération. Notez notamment que le cluster est passé en mode standby et est prêt à accepter des connexions en lecture seule.
pg-standby ⇒ Examinez la sortie du journal PostgreSQL pour les messages indiquant une réussite
Une façon simple de vérifier que la réplication est correctement configurée consiste à créer une table sur pg-primary.
pg-primary ⇒ Créer une nouvelle table sur le serveur primaire
Ensuite, interrogez la même table sur pg-standby.
pg-standby ⇒ Interroger une nouvelle table sur le serveur de secours
Qu’est-ce qui s’est mal passé ? Puisque PostgreSQL extrait les segments WAL de l’archive pour effectuer la réplication, les modifications ne seront pas visibles sur le serveur de secours tant que le segment WAL contenant ces modifications n’aura pas été transféré depuis pg-primary.
Cela peut être effectué manuellement en appelant pg_switch_wal(), ce qui transfère le segment WAL actuel vers l’archive (un nouveau segment WAL est créé pour contenir les modifications ultérieures).
pg-primary ⇒ Appel à pg_switch_wal()
À présent, après un court délai, la table apparaîtra sur pg-standby.
pg-standby ⇒ La nouvelle table existe désormais sur le serveur de secours (peut nécessiter plusieurs tentatives)
Vérifiez la configuration du serveur de secours pour accéder au dépôt.
pg-standby ⇒ Vérifier la configuration
Réplication en streaming
Au lieu de se fier uniquement à l’archive WAL, la réplication en streaming établit une connexion directe avec le principal et applique les modifications dès qu’elles sont effectuées sur ce dernier. Cela réduit considérablement le délai de latence entre le principal et le secondaire.
La réplication en streaming nécessite un utilisateur disposant du privilège de réplication.
pg-primary ⇒ Créer un utilisateur de réplication
Le fichier pg_hba.conf doit être mis à jour pour autoriser le serveur de secours à se connecter en tant qu’utilisateur de réplication. Veillez à remplacer l’adresse IP ci-dessous par l’adresse IP réelle de votre serveur pg-standby. Un rechargement sera nécessaire après la modification du fichier pg_hba.conf.
pg-primary ⇒ Créer une entrée pg_hba.conf pour l’utilisateur de réplication
Le serveur de secours doit savoir comment contacter le serveur principal, donc le paramètre primary_conninfo sera configuré dans pgBackRest.
pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Définir primary_conninfo
Il est possible de configurer un mot de passe dans le paramètre primary_conninfo, mais utiliser un fichier .pgpass est plus flexible et plus sécurisé.
pg-standby ⇒ Configurez le mot de passe de réplication dans le fichier .pgpass.
À présent, le serveur de secours peut être créé avec la commande restore.
pg-standby ⇒ Arrêtez PostgreSQL et effectuez la restauration du cluster de secours démo
NOTE :
Le paramètre primary_conninfo a été écrit dans le fichier postgresql.auto.conf car il a été configuré en tant que recovery-option dans pgbackrest.conf. L’option --type=preserve peut être utilisée avec restore pour laisser le fichier postgresql.auto.conf existant inchangé si ce comportement est préféré.
pg-standby ⇒ Démarrer PostgreSQL
Le journal PostgreSQL confirmera que la réplication en flux a commencé.
pg-standby ⇒ Examinez la sortie du journal PostgreSQL pour les messages indiquant une réussite
Désormais, lorsque vous créerez une table sur pg-primary, elle apparaîtra sur pg-standby rapidement et sans avoir à appeler pg_switch_wal().
pg-primary ⇒ Créer une nouvelle table sur le serveur primaire
pg-standby ⇒ Interroger une table sur le serveur de secours
Stanzas multiples
pgBackRest prend en charge plusieurs stanzas. L’utilisation la plus courante consiste à partager un hôte de dépôt entre plusieurs stanzas.
Installation
Un nouvel hôte nommé pg-alt est créé pour exécuter le nouveau primaire.
Installer pgBackRest à partir d’un paquet est préférable à la compilation à partir des sources. Lors de l’installation à partir d’un paquet, les autres instructions de cette section sont généralement inutiles, mais il se peut qu’un paquet omette de créer un répertoire ou applique des permissions incorrectes. Dans ce cas, il peut être nécessaire de créer manuellement les répertoires ou de mettre à jour les permissions.
Les paquets Debian/Ubuntu pour pgBackRest sont disponibles sur apt.PostgreSQL.org .
Si des paquets ne sont pas fournis pour votre distribution/version, vous pouvez compiler à partir des sources puis procéder à l’installation manuelle comme indiqué ici.
pg-alt ⇒ Installer les dépendances
pg-alt ⇒ Copier le binaire pgBackRest depuis l’hôte de compilation
pgBackRest nécessite des répertoires pour les journaux et la configuration, ainsi qu’un fichier de configuration.
pg-alt ⇒ Créer le fichier de configuration et les répertoires pgBackRest
Configuration d’un accès SSH sans mot de passe
pgBackRest peut utiliser SSH sans mot de passe pour permettre la communication entre les hôtes. Il est également possible d’utiliser TLS, voir Configurer TLS .
pg-alt ⇒ Créer une paire de clés hôte pg-alt
Échanger les clés entre le dépôt et pg-alt.
dépôt ⇒ Copiez la clé publique pg-alt vers le dépôt
pg-alt ⇒ Copier la clé publique du dépôt sur pg-alt
Testez que les connexions peuvent être établies depuis le dépôt vers pg-alt et réciproquement.
dépôt ⇒ Tester la connexion depuis le dépôt vers pg-alt
pg-alt ⇒ Tester la connexion depuis pg-alt vers le dépôt
Configuration
La configuration de pgBackRest est presque identique à celle de pg-primary, sauf que la stanza demo-alt sera utilisée, de sorte que les sauvegardes et l’archive seront stockées dans un emplacement séparé.
pg-alt:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez pgBackRest sur le nouveau serveur primaire
dépôt : /etc/pgbackrest/pgbackrest.conf ⇒ Configurez pg1-host/pg1-host-user et pg1-path
Configurer un cluster de démonstration
pg-alt ⇒ Créer le cluster de démonstration
pg-alt:/etc/postgresql/17/demo/postgresql.conf ⇒ Configure les paramètres PostgreSQL
pg-alt ⇒ Démarrer le cluster de démonstration
Créer la stanza et vérifier la configuration
La commande stanza-create doit être exécutée pour initialiser la stanza. Il est recommandé d’exécuter la commande check après stanza-create afin de vérifier que l’archivage et les sauvegardes sont correctement configurés.
pg-alt ⇒ Créer la stanza et vérifier la configuration
Si la commande check est exécutée depuis l’hôte du dépôt, tous les stanzas seront vérifiés.
dépôt ⇒ Vérifiez la configuration de tous les stanzas
Archivage asynchrone
La sauvegarde asynchrone est activée avec l’option archive-async. Cette option permet une opération asynchrone pour les commandes archive-push et archive-get.
Un chemin de tampon est requis. Les commandes stockeront les données temporaires ici, mais chaque commande fonctionne de manière assez différente ; l’utilisation du chemin de tampon est donc décrite en détail dans chaque section.
pg-primary ⇒ Créer le répertoire de file d’attente
pg-standby ⇒ Créer le répertoire de tampon
Le chemin d’attente doit être configuré et l’archivage asynchrone activé. L’archivage asynchrone apporte automatiquement certains avantages en réduisant le nombre de connexions établies vers le stockage distant, mais la configuration de process-max peut améliorer considérablement les performances en parallélisant les opérations. Veillez à ne pas définir process-max trop élevé afin de ne pas affecter les opérations normales de la base de données.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez le chemin d’épissage et l’archivage asynchrone
pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Configurez le chemin d’épissage et l’archivage asynchrone
NOTE :
process-max est configuré à l’aide de sections de commande afin que l’option ne soit pas utilisée lors de la sauvegarde ni de la restauration. Cela permet également d’attribuer des valeurs différentes à archive-push et archive-get.
À des fins de démonstration, la réplication en streaming sera interrompue afin de forcer PostgreSQL à récupérer les WAL à l’aide de la commande restore_command.
pg-primary ⇒ Interrompre la réplication en continu en modifiant le mot de passe de réplication
pg-standby ⇒ Redémarrer le serveur de secours pour interrompre la connexion
Archivage push
La commande asynchrone archive-push déplace l’archivage des WAL vers un processus (ou plusieurs processus) distinct pour améliorer le débit. Elle fonctionne en « regardant à l’avance » pour déterminer quels segments WAL sont prêts à être archivés, au-delà de la demande actuelle de PostgreSQL via le archive_command. Les segments WAL sont transférés directement depuis le répertoire pg_xlog/pg_wal et la réussite n’est retournée par le archive_command que lorsque le segment WAL a été stocké en toute sécurité dans l’archive.
Le répertoire de stockage temporaire contient l’état actuel de l’archivage des WAL. Les fichiers d’état écrits dans le répertoire de stockage temporaire sont généralement de taille nulle et doivent consommer une quantité négligeable d’espace (au plus quelques mégaoctets) et très peu d’E/S. Toutes les informations contenues dans ce répertoire peuvent être régénérées, aussi n’est-il pas nécessaire de préserver le répertoire de stockage temporaire si le cluster est déplacé vers de nouveaux matériels.
IMPORTANT :
Dans l’implémentation originale de l’archivage asynchrone, les segments WAL étaient copiés dans le répertoire tampon avant compression et transfert. La nouvelle implémentation copie directement les segments WAL depuis le répertoire pg_xlog. Si l’archivage asynchrone était utilisé dans la version 1.12 ou antérieure, lisez attentivement les notes de publication de la version 1.13 avant de procéder à la mise à jour.
Le fichier [stanza]-archive-push-async.log peut être utilisé pour surveiller l’activité du processus asynchrone. Une bonne manière de tester cela consiste à envoyer rapidement un nombre important de segments WAL.
pg-primary ⇒ Test de l’archivage asynchrone parallèle
Le fichier journal contiendra désormais une activité parallèle et asynchrone.
pg-primary ⇒ Vérifier les résultats dans le journal
Récupération d’archive
La commande asynchrone archive-get maintient une file locale de WAL afin d’améliorer le débit. Si un segment de WAL n’est pas présent dans la file, il est récupéré à partir du dépôt, accompagné de suffisamment de segments de WAL consécutifs pour remplir la file. La taille maximale de la file est définie par archive-get-queue-max. Chaque fois que la file est à moins de la moitié pleine, davantage de WAL est récupéré afin de la remplir.
L’opération asynchrone est particulièrement utile dans les environnements qui génèrent beaucoup de WAL ou qui disposent d’une connexion à haute latence avec le stockage du dépôt (par exemple, S3 ou d’autres magasins d’objets). Dans le cas d’une connexion à haute latence, il peut être pertinent d’augmenter process-max.
Le fichier [stanza]-archive-get-async.log peut être utilisé pour surveiller l’activité du processus asynchrone.
pg-standby ⇒ Vérifier les résultats dans le journal
pg-primary ⇒ Corriger la réplication en streaming en modifiant le mot de passe de réplication
Sauvegarde à partir d’un serveur de secours
pgBackRest peut effectuer des sauvegardes sur une instance de secours au lieu du serveur principal. Les sauvegardes sur instance de secours nécessitent que l’hôte pg-standby soit configuré et que l’option backup-standby soit activée. Si plusieurs instances de secours sont configurées, la première instance de secours en cours d’exécution trouvée sera utilisée pour la sauvegarde.
dépôt : /etc/pgbackrest/pgbackrest.conf ⇒ Configurez pg2-host/pg2-host-user et pg2-path
La base primaire comme la base standby sont nécessaires pour effectuer la sauvegarde, bien que l’immense majorité des fichiers soient copiés depuis le standby afin de réduire la charge du primaire. Les hôtes de base de données peuvent être configurés dans n’importe quel ordre ; pgBackRest détermine automatiquement lequel est primaire et lequel est standby.
dépôt ⇒ Effectuer une sauvegarde du cluster de démonstration depuis pg2
Cette sauvegarde incrémentielle montre que la majeure partie des fichiers provient de l’hôte pg-standby et qu’un petit nombre provient de l’hôte pg-primary.
pgBackRest crée une sauvegarde en mode basculement identique à celle effectuée sur le serveur principal. Il procède en lançant/arrêtant la sauvegarde sur l’hôte pg-primary, en copiant uniquement les fichiers répliqués depuis l’hôte pg-standby, puis en copiant les quelques fichiers restants depuis l’hôte pg-primary. Cela signifie que les journaux et les statistiques de la base de données principale seront inclus dans la sauvegarde.
Mise à jour de PostgreSQL
Immédiatement après la mise à niveau de PostgreSQL vers une nouvelle version majeure, le pg-path de toutes les configurations pgBackRest doit être défini sur le nouveau emplacement de la base de données, puis la commande stanza-upgrade doit être exécutée. Si plusieurs dépôts sont configurés sur l’hôte, le stanza sera mis à niveau sur chacun. Si la base de données est hors ligne, utilisez l’option --no-online.
Les instructions suivantes ne constituent pas un guide complet de mise à jour de PostgreSQL, mais décrivent le processus général de mise à jour d’un nœud principal et d’un nœud secondaire, dans le but de démontrer les étapes nécessaires à la reconfiguration de pgBackRest. Il est recommandé de prendre une sauvegarde avant la mise à jour.
pg-primary ⇒ Arrêt de l’ancêtre cluster
Arrêtez l’ancien cluster sur le serveur de secours, car il sera restauré à partir du cluster nouvellement mis à jour.
pg-standby ⇒ Arrêter l’ancêtre cluster
Créez le nouveau cluster et effectuez la mise à jour.
pg-primary ⇒ Créer un nouveau cluster et effectuer la mise à jour
Configurez les paramètres du nouveau cluster et le port.
pg-primary:/etc/postgresql/18/demo/postgresql.conf ⇒ Configurez PostgreSQL
Mettez à jour la configuration de pgBackRest sur tous les systèmes pour qu’elle pointe vers le nouveau cluster.
pg-primary:/etc/pgbackrest/pgbackrest.conf ⇒ Mettre à jour pg1-path
pg-standby:/etc/pgbackrest/pgbackrest.conf ⇒ Mettre à jour pg-path
dépôt : /etc/pgbackrest/pgbackrest.conf ⇒ Mettre à jour pg1-path et pg2-path, désactiver la sauvegarde depuis le serveur de secours
pg-primary ⇒ Copie de la configuration HBA
Avant de démarrer le nouveau cluster, la commande stanza-upgrade doit être exécutée.
pg-primary ⇒ Mettre à jour la stanza
Démarrer le nouveau cluster et confirmer qu’il est correctement installé.
pg-primary ⇒ Démarrer un nouveau cluster
Testez la configuration à l’aide de la commande check.
pg-primary ⇒ Vérifier la configuration
Supprimez le cluster ancien.
pg-primary ⇒ Supprimer le cluster ancien
Installez les nouveaux binaires PostgreSQL sur le serveur de secours et créez le cluster.
pg-standby ⇒ Supprimer l’ancien cluster et créer le nouveau cluster
Exécutez check sur l’hôte du dépôt. L’avertissement concernant l’arrêt du serveur secondaire est attendu, car le cluster secondaire est arrêté. L’exécution de cette commande montre que le serveur de dépôt est conscient de la présence du serveur secondaire et est correctement configuré pour le serveur principal.
dépôt ⇒ Vérifier la configuration
Effectuez une sauvegarde complète sur le cluster nouvellement configuré, puis restaurez le serveur de secours à partir de cette sauvegarde. Le type de sauvegarde sera automatiquement modifié en full si incr ou diff est demandé.
dépôt ⇒ Exécuter une sauvegarde complète
pg-standby ⇒ Effectuer la restauration du cluster de secours démo
pg-standby ⇒ Démarrer PostgreSQL et vérifier la configuration de pgBackRest
La sauvegarde depuis un serveur de secours peut maintenant être activée, puisque le serveur de secours est restauré.
dépôt : /etc/pgbackrest/pgbackrest.conf ⇒ Réactiver la sauvegarde depuis le serveur secondaire