# pg_basebackup > Utiliser pg_basebackup pour copier physiquement une instance et construire un secondaire. --- Index LLMS : [llms.txt](/fr/llms.txt) --- ## pg_basebackup {#dba3-ch3} Ce chapitre reprend la présentation complète de pg_basebackup et renvoie aux mécanismes PITR du chapitre précédent : [sauvegarde physique à chaud et PITR](/fr/dba3/02-sauvegarde-physique-pitr/#dba3-ch2). **Figure 3-1.** Figure 3\-1 \- Diapositive d\'ouverture du chapitre 3\. ![Diapositive d\'ouverture du chapitre 3\.](/images/dba3/manual/dba3-p113-01.png) ## 3/ Pg_basebackup ### 3.1 Introduction pg_basebackup, l’outil simple et efficace pour la copie physique à chaud pg_basebackup est un produit qui a beaucoup évolué dans les dernières versions de PostgreSQL. pg_basebackup est simple à mettre en place et à utiliser. De plus, il est livré avec PostgreSQL, et le paramétrage par défaut le rend immédiatement utilisable. S’il a des limitations qui n’en font pas le premier choix pour une sauvegarde PITR, il a quand même de plus en plus d’atouts. #### 3.1.1 Au menu - Copie physique à chaud - Formats de sauvegarde - Compression - Avantages/inconvénients - Utilisation possible pour - le PITR - créer un secondaire ### 3.2 Utilisation de pg_basebackup Cas prévu : la sauvegarde ponctuelle physique à chaud #### 3.2.1 Présentation - Intégré à PostgreSQL - Buts : - copie physique à chaud cohérente - créer facilement un secondaire - Ni restauration ni PITR incluses pg_basebackup 1 est une application cliente intégrée à PostgreSQL, au même titre que pg_dump ou pg_dumpall . pg_basebackup a été conçu pour permettre l’initialisation d’une instance secondaire, et il peut donc être utilisé pour effectuer facilement une sauvegarde physique ponctuelle. Celle-ci inclut les fichiers et journaux nécessaires pour une restauration telle que l’instance était à la fin de la sauvegarde. pg_basebackup ne permet pas à lui seul de procéder à des sauvegardes PITR, mais peut aider à les mettre en place. Il peut aussi être à la base d’outils permettant le PITR (par exemple barman). Ces outils s’occupent également de l’archivage des journaux générés pendant et après la sauvegarde initiale. Cela permet une restauration dans un état postérieur à la fin de cette sauvegarde. Lisez bien la documentation de pg_basebackup 2 pour votre version précise de PostgreSQL, des options ont changé de nom au fil des versions. Même avec un serveur un peu ancien, il est possible d’utiliser un pg_basebackup récent, en installant les outils clients de la dernière version de PostgreSQL. - Source 1 : https://docs.postgresql.fr/current/app-pgbasebackup.html - Source 2 : https://docs.postgresql.fr/current/app-pgbasebackup.html #### 3.2.2 But - Réalise les différentes étapes d’une sauvegarde - via 1 ou 2 connexions de réplication + slots de réplication - « base backup » & journaux nécessaires - Copie intégrale - image de la base à la fin du backup - peut servir de base pour du PITR plus tard pg_basebackup est un produit qui a beaucoup évolué dans les dernières versions de PostgreSQL. De plus, le paramétrage par défaut le rend immédiatement utilisable. Il permet de réaliser toute la sauvegarde de l’instance, à distance, via deux connexions de réplication : - une pour les données ; - une pour les journaux de transactions qui sont générés pendant la copie. Il est simple à mettre en place et à utiliser, et permet d’éviter de nombreuses étapes. Il gère la compression côté serveur ou client, et la sauvegarde incrémentale de manière encore peu pratique. Ci-dessous figurent toutes les options disponibles (en version 18). Nous en verrons la plupart. ```bash $ pg_basebackup --help ``` pg_basebackup prend une sauvegarde binaire d'un serveur PostgreSQL en cours d'exécution. Usage : pg_basebackup [OPTION]... Options contrôlant la sortie : -D, --pgdata=RÉPERTOIRE reçoit la sauvegarde de base dans ce répertoire ```text -F, --format=p|t format en sortie (plain (par défaut), tar) ``` -i, --incremental=ANCIENMANIFESTE réalise une sauvegarde incrémentale -r, --max-rate=TAUX taux maximum de transfert du répertoire de données (en Ko/s, ou utiliser le suffixe « k » ou « M ») -R, --write-recovery-conf écrit la configuration pour la réplication -t, --target=CIBLE[:DETAIL] cible de sauvegarde (si autre que client) -T, --tablespace-mapping=ANCIENREP=NOUVEAUREP déplace le répertoire ANCIENREP en NOUVEAUREP ```text --waldir=RÉP_WAL emplacement du répertoire des journaux de ``` transactions ```text -X, --wal-method=none|fetch|stream ``` inclut les journaux de transactions requis avec la méthode spécifiée -z, --gzip compresse la sortie tar ```text -Z, --compress=[{client|server}-]METHODE[:DETAIL] ``` compresse sur le client ou le serveur comme indiqué -Z, --compress=none ne compresse pas la sortie tar Options générales : ```text -c, --checkpoint=fast|spread ``` exécute un CHECKPOINT rapide ou réparti (par défaut) ```text --create-slot crée un slot de réplication ``` -l, --label=LABEL configure le label de sauvegarde -n, --no-clean ne nettoie pas en cas d'erreur -N, --no-sync n'attend pas que les modifications soient proprement écrites sur disque -P, --progress affiche la progression de la sauvegarde -S, --slot=NOMREP slot de réplication à utiliser -v, --verbose affiche des messages verbeux -V, --version affiche la version puis quitte ```text --manifest-checksums=SHA{224,256,384,512}|CRC32C|NONE ``` utilise cet algorithme pour les sommes de contrôle du manifeste ```text --manifest-force-encode ``` encode tous les noms de fichier dans le manifeste en hexadécimal ```text --no-estimate-size ne réalise pas d'estimation sur la taille de la ``` sauvegarde côté serveur ```text --no-manifest supprime la génération de manifeste de ``` sauvegarde ```text --no-slot empêche la création de slots de réplication ``` temporaires ```text --no-verify-checksums ``` ne vérifie pas les sommes de contrôle ```text --sync-method=METHODE ``` configure la méthode pour synchroniser les fichiers sur disque -?, --help affiche cette aide puis quitte Options de connexion : -d, --dbname=CHAÎNE_CONNEX chaîne de connexion -h, --host=HÔTE hôte du serveur de bases de données ou répertoire des sockets -p, --port=PORT numéro de port du serveur de bases de données -s, --status-interval=INTERVAL durée entre l'envoi de paquets de statut au serveur (en secondes) -U, --username=UTILISATEUR se connecte avec cet utilisateur -w, --no-password ne demande jamais le mot de passe -W, --password force la demande du mot de passe (devrait survenir automatiquement) Rapporter les bogues à . Page d'accueil de PostgreSQL : #### 3.2.3 Mise en place - postgresql.conf : ```ini wal_level = replica max_wal_senders = 10 max_replication_slots = 10 ``` - pg_hba.conf : hostreplication usersvg 192.168.0.42/32 scram-sha-256 pg_basebackup nécessite des connexions de réplication. De plus, par défaut et de manière transparente, il utilise aussi un slot de réplication temporaire, une technique qui fiabilise la sauvegarde ou la réplication en indiquant à l’instance quels journaux elle doit conserver. Avec la configuration de PostgreSQL par défaut, tout est en place : ```ini wal_level = replica max_wal_senders = 10 max_replication_slots = 10 ``` Ensuite, il faut configurer le fichier pg_hba.conf pour accepter la connexion du serveur où est exécuté pg_basebackup . Dans la configuration par défaut, il y a en général cette ligne qui permet au moins de faire une copie en local avec l’utilisateur système postgres : localreplicationall peer (noter la base replication). Il vaut mieux un utilisateur dédié à la connexion de réplication (au sens de la base de données) séparé, nommé ici sauve. Il faut donc ajouter cette ligne : hostreplication sauve 127.0.0.1/32 scram-sha-256 Il faut créer cet utilisateur dédié : ```sql CREATE ROLE sauve LOGIN REPLICATION; ``` \password sauve Dans un but d’automatisation, le mot de passe finira souvent dans un fichier .pgpass ou équivalent. #### 3.2.4 Exemple de sauvegarde ```bash $ pg_basebackup --format=tar --wal-method=stream \ --checkpoint=fast --progress -h 127.0.0.1 -U sauve \ ``` -D /var/lib/postgresql/backups/ - Attention aux fichiers de configuration - Possible aussi depuis un serveur secondaire La commande précédente : - lance pg_basebackup, ici en lui demandant une archive au format tar ; - archive les journaux en utilisant une connexion de réplication par streaming; - force le checkpoint ; - implicitement, utilise un slot de réplication temporaire pour sécuriser l’opération. Le résultat est ici un ensemble des deux archives : ```bash $ ls -l /var/lib/postgresql/backups/ ``` total 4163772 -rw------- 1 postgres postgres 659785216 Oct 9 11:37 base.tar -rw------- 1 postgres postgres 16780288 Oct 9 11:37 pg_wal.tar La première contient le PGDATA. Les journaux sont dans la deuxième. D’autres archives peuvent apparaître s’il y a des tablespaces supplémentaires. Une sauvegarde avec --format=plain (format par défaut) donne une image complète, non compressée, du PGDATA, répertoire pg_wal compris (par défaut). C’est l’idéal pour créer le répertoire de données et y démarrer tout de suite un secondaire. Attention : les fichiers de configuration ne sont pas inclus s’ils ne sont pas dans le `PGDATA`. Cela concerne donc en priorité Debian, Ubuntu et leurs versions dérivées. Noter que pg_basebackup peut très bien réaliser une sauvegarde à partir d’une instance secondaire. #### 3.2.5 Restauration - Aucun automatisme - éventuellement créer l’instance - Juste copier vers le bon PGDATA - éventuellement décompresser journaux/tablespaces - fichier tablespace_map - Fichiers de configuration? - Configuration adaptée à la restauration L’emplacement cible de la sauvegarde doit être vide. En cas d’arrêt avant la fin, il faut donc tout recommencer de zéro. C’est une limite de l’outil. Si l’on a utilisé des sauvegardes incrémentales, il faut utiliser pg_combinebackup pour reconstituer une sauvegarde complète utilisable (voir plus loin). Si l’on a une archive, il faut la décompresser. Il faut aussi décompresser l’archive associée contenant les journaux, à moins qu’il soit prévu de les récupérer autrement ( restore_command ). S’il y a d’autres fichiers pour des tablespaces, il faut les décompresser, et adapter le fichier tablespace_map si les chemins diffèrent pour que l’instance en tienne compte au démarrage. Pour restaurer sur une instance existante, il suffit de remplacer le PGDATA corrompu ou perdu par le contenu de l’archive complète de la base source. Ne pas oublier les fichiers de configuration s’ils ne font pas partie de la sauvegarde (notamment sur Debian/Ubuntu). S’il s’agit d’une nouvelle instance (par exemple car le serveur a changé), il faut créer l’instance de la manière habituelle, l’arrêter, et remplacer son répertoire PGDATA par cette sauvegarde. Il faut prévoir aussi la configuration propre à une restauration : - recovery.signal ; - lignes adéquates dans postgresql.conf , notamment la restore_command . ou la configuration propre à la réplication : - standby.signal ; - lignes adéquates dans postgresql.conf , notamment restore_command , primary_conninfo …; - paramétrage propre à une instance répliquée. L’option --write-recovery-conf (voir plus loin) peut faciliter la création de la configuration de réplication. Si la copie doit être une instance indépendante (par exemple une copie de la production pour du développement), ne pas oublier de modifier l’archivage pour que les journaux ne se mélangent pas! Au démarrage, l’instance repère qu’elle est une sauvegarde restaurée. Elle réapplique les journaux présents. L’instance restaurée contient au final les données telles qu’elles étaient à la fin du pg_basebackup. LOG:database system was interrupted; last known up at 2026-08-27 16:12:00 CEST LOG:starting backup recovery with redo LSN B/90000028, checkpoint LSN B/90000088, on timeline ID 1 LOG:redo starts at B/90000028 LOG:completed backup recovery with redo LSN B/90000028 and end LSN B/90000130 LOG:consistent recovery state reached at B/90000130 LOG:redo done at B/90000130 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s LOG:checkpoint starting: end-of-recovery fast wait LOG:checkpoint complete: end-of-recovery fast wait: wrote 0 buffers (0.0%), wrote 3 SLRU buffers; 0 WAL file(s) added, 0 removed, 1 recycled; write=0.002 s, sync=0.001 s, total=0.006 s; sync files=2, longest=0.001 s, average=0.001 s; distance=16384 kB, estimate=16384 kB; lsn=B/91000028, redo lsn=B/91000028 LOG:database system is ready to accept connections L’instance n’ira chercher les journaux suivants que si elle est configurée explicitement ainsi. ### 3.3 Options de pg_basebackup #### 3.3.1 Formats de sauvegarde - --format plain - arborescence identique à l’instance sauvegardée - --format tar - 3 archives : PGDATA, journaux, tablespaces - compression : - -z - -Z client-lz4 - -Z server-zstd:6 ```bash tar ou plain : ``` Le format par défaut de la sauvegarde est plain , ce qui signifie que les fichiers seront créés tels quels dans le répertoire de destination (ou les répertoires en cas de tablespaces). C’est idéal pour obtenir une copie immédiatement utilisable, par exemple pour créer un secondaire. Pour une archive à proprement parler, préférer l’option --format tar . pg_basebackup génère alors par défaut : - une archive base.tar pour le PGDATA de l’instance; - une archive ``.tar pour chaque tablespace éventuel; - une archive pg_wal.tar avec les journaux nécessaires à une sauvegarde cohérente. Compression de la sauvegarde : À partir de la version 15, il est possible de demander la compression de la sauvegarde avec un grand niveau de personnalisation : - algorithme de compression parmi gzip , lz4 et zstd ; - rapidité de la compression hors parallélisme; - niveau de compression; - parallélisation de la compression; - localisation de la compression (serveur ou client). L’option -z compresse avec gzip , l’algorithme par défaut et historique… et sans doute le moins bon. Le taux se définit plutôt avec -Z1 à -Z9 . Préférez zstd ou lz4 . On peut choisir de compresser sur le serveur ou sur le client (donc après passage par le réseau). Les options sont alors par exemple -Z client-lz4 , -Z server-zstd , en rajoutant par exemple :1 à :9 pour le taux de compression. Cela permet de gérer différents scénarios selon que le CPU ou le réseau est le facteur limitant lors d’une sauvegarde, et entre taille et temps de compression. #### 3.3.2 Récupération des journaux - Défaut : --wal-method stream - par streaming, slot de réplication par défaut - --wal-method fetch - en une phase, un fichier, pas de slot - --wal-method none - pas de journaux (si copiés par ailleurs) - archive alors non cohérente pg_basebackup sait récupérer les fichiers WAL nécessaires à la restauration de la sauvegarde sans passer par la commande d’archivage. Il connaît deux méthodes : L’option par défaut est --wal-method stream (en abrégé -X stream ) : les WAL sont récupérés mais en streaming pendant la sauvegarde. Cela utilise un wal sender supplémentaire sur le serveur (au besoin, le paramètre max_wal_senders doit être augmenté). Avec l’option --wal-method fetch (ou -X fetch ) : les WAL générés pendant la sauvegarde sont demandés une fois la copie des fichiers terminée. Aucun slot n’est utilisé. L’utilisation est rare (par exemple avec --target plus bas). Par contre, `-X none` peut être utile si la récupération des journaux est déjà gérée en parallèle (généralement par `archive_command` ou `archive_library`). Attention ! l’archive réalisée par `pg_basebackup` n’est alors pas « complète », et ne peut pas être restaurée sans ces archives des journaux. Il faudra indiquer où aller les chercher avec `restore_command`. #### 3.3.3 Slot de réplication - Par défaut : slot temporaire - Pour un secondaire : - créer le slot - --slot nom_du_slot --create - à utiliser rapidement Par défaut, pg_basebackup crée un slot de réplication temporaire sur le serveur pour sécuriser la sauvegarde. Le serveur conserve donc les journaux nécessaires jusqu’à ce qu’ils soient récupérés et inclus dans la sauvegarde pour qu’elle soit complète. Le slot disparaît une fois celle-ci terminée. Si cela suffit pour une sauvegarde, ce peut être insuffisant pour la mise en place d’une instance secondaire. En effet, rien ne garantit que tous les journaux nécessaires sont encore sur le primaire quand le secondaire démarre et tente de se resynchroniser avec lui, et il n’y a pas forcément d’archivage PITR disponible. Pour ce cas, pg_basebackup sait utiliser un slot permanent, qu’on lui indique avec `--slot nom_du_slot`. pg_basebackup peut le créer lui-même avec `--create`, ce qui est le plus simple. Si l’on préfère le créer préalablement, il suffit d’exécuter la requête suivante : ```sql SELECT pg_create_physical_replication_slot ('nom_du_slot'); ``` Après la sauvegarde, le slot n’est pas supprimé et conserve les journaux générés jusqu’à ce qu’un secondaire se rattache à ce slot et consomme les journaux. Rappelons qu’un slot initialisé mais inutilisé doit être rapidement supprimé pour ne pas mener à une dangereuse accumulation des journaux ! Le secondaire ne doit donc pas tarder à être mis en place pour qu’il commence à consommer les journaux du primaire. #### 3.3.4 Intégrité - Fichier manifeste - pg_verifybackup - --manifest-checksums=CRC32C|SHA523|NONE - Vérification des checksums de l’instance #### 3.3.4.1 Manifeste Par défaut, pg_basebackup crée un manifeste dans l’archive (fichier backup_manifeste ), contenant la liste des fichiers sauvegardés, leur taille et une somme de contrôle. Cela permet de vérifier la sauvegarde avec l’outil pg_verifybackup . Ce dernier fonctionne sur une sauvegarde au format plain ou décompressée depuis son ajout, et sur une sauvegarde au format tar depuis la version 18. L’algorithme par défaut de la somme de contrôle, CRC32C, suffit pour détecter une erreur technique accidentelle. D’autres algorithmes plus sécurisés (et plus consommateurs en CPU) permettent de parer à une manipulation volontaire (généralement malveillante) de la sauvegarde, par exemple avec `--manifest-checksums=SHA512`. L’algorithme `NONE` désactive le contrôle. #### 3.3.4.2 Vérification des sommes de contrôle Une sauvegarde avec pg_basebackup entraîne la vérification des sommes de contrôle de l’instance, si elles sont en place (ce qui est fortement conseillé). Ainsi la sauvegarde n’hérite pas d’une corruption existante car l’outil tombe en erreur. L’option --no-verify-checksums autorise la sauvegarde d’une instance où une corruption est détectée (la sauvegarde reste problématique, mais on peut ainsi tester la récupération sur une copie physique, ou sauver l’essentiel). #### 3.3.5 Cible de la sauvegarde - Généralement : - répertoire vide ou fichier - là où pg_basebackup est lancé - ex : -D /backups/erp_prod - --target=server:/backups/erp_prod - --target=blackhole - tests Généralement on veut sauvegarder vers un répertoire vide ou une archive. À partir de la version 15, l’option --target permet de spécifier où la sauvegarde doit être réalisée. Par exemple, l’option --target=server:/backups/erp_prod crée la sauvegarde dans le répertoire indiqué directement depuis le serveur. On ne se connecte ainsi ni au serveur de la base ni au serveur cible de la sauvegarde. Il y a quelques restrictions : le format doit être tar ; l’utilisateur employé pour la réaliser doit être membre du rôle pg_write_server_files ; et la méthode de récupération des WAL doit être fetch ou none . ```text --target=blackhole ne sert que pour des tests : la sauvegarde n’est pas écrite! ``` Des destinations peuvent être ajoutées par des extensions. basebackup_to_shell 3 est fournie à titre d’exemple et permet d’exécuter une commande à l’issue d’une sauvegarde. #### 3.3.6 Copie en vue d’un réplica - --write-recovery-conf - pré-configure le streaming d’un réplica Si pg_basebackup est utilisé pour créer la base d’un serveur secondaire, utiliser --write-recovery-conf préconfigure le paramétrage du streaming dans la sauvegarde pour une connexion immédiate en streaming au serveur que l’on vient de sauvegarder. - Source 3 : https://docs.postgresql.fr/current/basebackup-to-shell.html Concrètement : - un fichier vide standby.signal est créé dans la sauvegarde (indiquant que ce sera un secondaire); - dans postgresql.auto.conf apparaît ceci en dernière ligne : ```ini primary_conninfo = 'user=postgres passfile=''/home/durand/.pgpass'' channel_binding=prefer host=grosserveur port=5435 sslmode=prefer sslnegotiation=postgres sslcompression=0 sslcertmode=allow sslsni=1 ssl_min_protocol_version=TLSv1.2 gssencmode=prefer krbsrvname=postgres gssdelegation=0 target_session_attrs=any load_balance_hosts=disable' ``` Il s’agit tout simplement de la chaîne de connexion utilisée pour faire la copie. Le reste de la configuration ( restore_command , primary_slot_name …) reste à la charge du DBA. #### 3.3.7 Autres options - Limite de débit : - --max-rate=10M - Checkpoint immédiat : - --checkpoint-fast - Adapter le chemin des tablespaces : --tablespace-mapping=``=`` - Et des journaux : --waldir=chemin #### 3.3.7.1 Débit Le débit de la sauvegarde est configurable avec l’option --max-rate= ( -r ) pour limiter l’impact sur l’instance ou le réseau. Par exemple, --max-rate=10M limite le débit à 10 Mo/s. Cette restriction de débit ne concerne pas les journaux transférés en parallèle ( -X stream ), mais leur volumétrie est en général faible. #### 3.3.7.2 Checkpoint déclenché Un checkpoint est un préalable à la sauvegarde. Pour gagner un peu de temps, ajouter --checkpoint=fast le déclenche immédiatement et permet de gagner quelques minutes. C’est à éviter sur une machine aux écritures très chargées. #### 3.3.7.3 Tablespaces Il est possible de modifier sur la cible les chemins des éventuels tablespaces avec l’option `--tablespace-mapping==` (ou `-T`). Sans cette option, en format plain, pg_basebackup ne génère plus tous les fichiers dans le répertoire cible : il cherche à copier les tablespaces en local avec le même chemin que sur le serveur, ce qui n’est pas forcément possible (ni souhaitable pour une sauvegarde). Exemple de copie d’un tablespace qui est dans `/var/lib/postgresql/` sur le serveur d’origine vers `/mnt/tbl/froid` en local : ```text pg_basebackup -F plain -h serveur -U sauve \ -D /var/lib/postgresql/nouveau \ --tablespace-mapping=/mnt/tbl/froid=/var/lib/postgresql/tblfroid ``` Le lien symbolique dans `pg_tblspc` est adapté. (Évidemment, il ne faut pas déplacer les fichiers sauvegardés sans remodifier ce lien symbolique.) Dans le cas d’une sauvegarde tar, le tablespace est une archive séparée, et le chemin indiqué est en dur dans le fichier `tablespace_map` dans l’archive principale `base.tar` : ```bash ls -1 sauvegarde/ 96201403.tar backup_manifest base.tar pg_wal.tar tar xf sauvegarde/base.tar tablespace_map --to-stdout 96201403 /mnt/tbl/froid ``` Cet exemple montre que les tablespaces compliquent l’administration. Rappelons que leur utilisation n’est pas encouragée, à moins de posséder des disques fonctionnant à des vitesses différentes, ou de dédier un tablespace aux fichiers temporaires. #### 3.3.7.4 Journaux De même, on peut relocaliser le répertoire des fichiers WAL avec l’option --waldir=`` . #### 3.3.8 Supervision de la sauvegarde - --progress - Vue pg_stat_progress_basebackup Pour suivre le déroulement de la sauvegarde depuis un terminal, il existe l’option --progress ( -P ). Il existe aussi une vue très utile pour ce suivi : pg_stat_progress_basebackup 4 . Elle affiche par - Source 4 : https://docs.postgresql.fr/current/progress-reporting.html#BASEBACKUP-PROGRESS-REPORTING exemple ces deux étapes : ```text TABLE pg_stat_progress_basebackup ; ``` ```text -[ RECORD 1 ]--------+------------------------pid | 3372779 phase | streaming database files backup_total | 12691149312 ``` backup_streamed ```text | 3555945472 ``` tablespaces_total ```text | 1 tablespaces_streamed | 0 ``` … ```text -[ RECORD 1 ]--------+-----------------------------------pid | 3372779 phase | waiting for wal archiving to finish backup_total | 12691160576 ``` backup_streamed ```text | 12691160576 ``` tablespaces_total ```text | 1 tablespaces_streamed | 1 ``` #### 3.3.9 Sauvegardes incrémentales - v17+ - À recombiner avec pg_combinebackup - Plutôt destiné à être utilisé par un outil La principale limitation de pg_basebackup avant PostgreSQL 17, est qu’il ne permet pas de réaliser une sauvegarde incrémentale, juste une image complète de la base. À partir de PostgreSQL 17, pg_basebackup sait créer des sauvegardes incrémentales et différentielles (selon ce qu’on lui fournit comme backup de référence au lancement de la sauvegarde). En vue de la restauration, ces sauvegardes peuvent se combiner avec un outil nommé pg_combinebackup , mais les fonctionnalités sont encore un peu sommaires. Ce mode est plutôt destiné à être la base d’autres outils plus conviviaux. pg_combinebackup recrée une sauvegarde complète à partir d’une première complète et de sauvegardes incrémentales. Il se contente de vérifier que l’enchaînement est bon et n’aide pas à déterminer ce dont on a besoin pour une restauration à un moment donné (comme le fait pgBackRest par exemple). La copie de fichiers pour reconstituer un PGDATA est longue, mais des options comme --clone permettent d’utiliser des fonctionnalités de copy on write de certains systèmes de fichier. ### 3.4 Résumé des avantages/inconvénients #### 3.4.1 Avantages - Simple; inclus dans le projet - Transfert des WAL nécessaires pendant la sauvegarde - Slot de réplication automatique (temporaire voire permanent) - Limitation du débit - Relocalisation des tablespaces - Fichier manifeste - Vérification des checksums - Sauvegarde possible à partir d’un secondaire - Compression côté serveur ou client, plusieurs algorithmes - Emplacement de la sauvegarde (client/server/blackhole) - Suivi : pg_stat_progress_basebackup #### 3.4.2 Limitations - Streaming nécessaire - Pas de configuration de l’archivage - Pas de politique de rétention des sauvegardes - Pas de politique de rétention des journaux - Sauvegarde incrémentale peu conviviale - Pas de gestion de la restauration Le streaming n’est pas une contrainte forte, toute instance PostgreSQL en est capable par défaut. L’outil exige tout de même deux connexions le temps de la sauvegarde (monter max_wal_senders au besoin). L’archivage n’est pas géré par pg_basebackup. Il ne récupère par streaming que les journaux nécessaires à la cohérence de sa sauvegarde. Contrairement aux outils de PITR classiques, pg_basebackup ne permet pas de continuer à archiver les journaux. Il n’utilise le protocole de réplication que pour récupérer les journaux de transactions nécessaires à sa sauvegarde. Il faut paramétrer archive_command (ou archive_library ) et gérer soi-même les journaux pour les sauvegardes PITR. Gérer la rétention n’est peut-être pas aussi simple que purger des journaux de plus de quelques jours. Il faut aussi vérifier qu’aucun journal nécessaire à la restauration ne manque. Cependant, un outil ou un script peut utiliser pg_basebackup pour réaliser la première copie des fichiers d’une sauvegarde d’instance (c’est le cas de barman), ou pour créer un secondaire (ce que fait ```text patroni). ``` La gestion des sauvegardes (rétention, purge…) n’est pas prévue dans l’outil. pg_basebackup n’effectue pas non plus de lien entre les WAL archivés et les sauvegardes effectuées (il archive ceux générés pendant la copie avec l’option -X , c’est tout). Il ne sait faire des sauvegardes incrémentales qu’à partir de PostgreSQL 17. pg_basebackup n’offre pas d’outil ni d’option pour la restauration. La copie est en fait directement utilisable, éventuellement après déplacement et/ou décompression. Ajouter recovery.signal ne doit pas être oublié pour que PostgreSQL sache qu’il a peut-être d’autres journaux à récupérer! Sinon l’instance s’ouvre une fois rejoués les journaux présents. Dans l’idéal, restore_command sera déjà prête dans le postgresql.conf . Si le but est de monter un serveur secondaire de l’instance copiée, ne pas oublier --write-recovery-conf ( -R ). ### 3.5 Conclusion - pg_basebackup : simple et efficace - Parfois, pas besoin de plus - Si ça se complique, voir pgBackRest & concurrents pg_basebackup est un outil à connaître. Pour des besoins simples (volumétrie raisonnable, rétention aisée), il peut éviter de sortir l’« artillerie lourde » comme pgBackRest. Cependant, attention à ne pas redévelopper un outillage complexe audessus de pg_basebackup : il vaut mieux se tourner vers un outil plus complet. #### 3.5.1 Questions N’hésitez pas, c’est le moment ! ### 3.6 Quiz - https://dali.bo/bk50_quiz