PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 15.6 » Référence » Applications client de PostgreSQL » pg_basebackup

pg_basebackup

pg_basebackup — réalise une sauvegarde de base d'une instance PostgreSQL

Synopsis

pg_basebackup [option...]

Description

pg_basebackup est utilisé pour effectuer une sauvegarde de base d'une instance PostgreSQL en cours d'exécution. Elle se fait sans affecter les autres clients du serveur de bases de données, et peut être utilisée pour une restauration à un certain point dans le temps (PITR, voir Section 26.3) ou comme point de départ pour un serveur secondaire, par envoi des journaux de transactions ou par le flux de réplication (voir Section 27.2).

pg_basebackup fait une copie exacte des fichiers de l'instance, en s'assurant que le système entre et sort du mode sauvegarde automatiquement. Les sauvegardes sont toujours faites sur l'ensemble de l'instance ; il n'est donc pas possible de sauvegarder une base individuelle ou des objets d'une base. Pour de telles sauvegardes, utiliser un outil comme pg_dump.

La sauvegarde se fait via une connexion PostgreSQL standard qui utilise le protocole de réplication. La connexion doit se faire avec un rôle doté de l'attribut REPLICATION ou SUPERUSER (voir Section 22.2), et pg_hba.conf doit explicitement permettre la connexion de réplication. Le serveur doit aussi être configuré avec un max_wal_senders suffisamment élevé pour fournir au moins une connexion disponible pour la sauvegarde, et une autre pour le transfert par flux des journaux de transactions (si utilisé).

Plusieurs commandes pg_basebackup peuvent tourner en même temps, mais, du point de vue des performances, il est généralement préférable de n'en faire qu'une seule, puis de faire une copie du résultat.

pg_basebackup peut effectuer une sauvegarde non seulement à partir du serveur primaire, mais aussi d'un serveur secondaire. Pour cela, paramétrez le secondaire pour accepter les connexions pour réplication (c'est-à-dire configurez les paramètres max_wal_senders et hot_standby, et configurez le fichier pg_hba.conf de façon approprié). Il sera aussi nécessaire d'activer full_page_writes sur le serveur primaire.

Il est à noter qu'il existe des limites à la sauvegarde à chaud depuis un serveur secondaire :

  • Le fichier d'historique de la sauvegarde n'est pas créé dans l'instance sauvegardée.

  • pg_basebackup ne peut forcer le serveur standby à basculer vers un nouveau fichier WAL à la fin de la sauvegarde. Quand vous utilisez -X none, si l'activité en écriture sur le primaire est basse, pg_basebackup peut avoir besoin d'attendre un long moment pour que le dernier fichier WAL requis par la sauvegarde soit archivé. Dans ce cas, il pourrait être utile d'exécuter pg_switch_wal ur le primaire pour causer un changement immédiat de fichier WAL.

  • Si le serveur secondaire est promu en tant que primaire durant la sauvegarde à chaud, celle-ci échouera.

  • Toutes les entrées WAL nécessaires à la sauvegarde doivent disposer de suffisamment de pages complètes, ce qui nécessite d'activer full_page_writes sur le primaire.

La vue pg_stat_progress_basebackup du serveur sauvegardé permet de suivre la progression d'une sauvegarde de base effectuée avec pg_basebackup. Voir Section 28.4.5 pour les détails.

Options

Les options de ligne de commande suivantes contrôlent l'emplacement et le format du résultat.

-D répertoire
--pgdata=répertoire

Configure le répertoire cible de la sauvegarde. pg_basebackup créera le répertoire (et les répertoires parents) s'il n'existe pas. S'il existe déjà, il doit être vide.

Quand la sauvegarde est en mode tar, le répertoire doit être spécifié sous la forme d'un tiret (-), causant l'écriture du fichier tar sur stdout.

Cette option est obligatoire.

-F format
--format=format

Sélectionne le format de sortie. format peut valoir :

p
plain

Écrit des fichiers standards, avec l'agencement d'origine du répertoire des données et des tablespaces du serveur source. Si l'instance n'a pas de tablespace supplémentaire, toute l'instance sera placée dans le répertoire cible. Si l'instance contient des tablespaces supplémentaires, le répertoire principal des données sera placé dans le répertoire cible mais les autres tablespaces seront placés dans le même chemin absolu que celui d'origine. (Voir --tablespace-mapping pour changer cela.)

C'est le format par défaut.

t
tar

Écrit des fichiers tar dans le répertoire cible. Le contenu du répertoire principal de données sera écrit dans un fichier nommé base.tar, et tous les autres tablespaces seront écrit dans un fichier tar séparé nommé d'après l'OID du tablespace.

Si le répertoire cible est indiqué avec un tiret -, le contenu du fichier tar sera écrit sur la sortie standard, ce qui est permet de l'envoyer par un tube vers gzip, par exemple. Ceci n'est autorisé que si l'instance n'a pas de tablespaces supplémentaires, ou que le transfert des WAL par streaming n'est pas utilisé.

-R
--write-recovery-conf

Crée un fichier standby.signal et ajoute les paramètres de connexion dans le fichier postgresql.auto.conf du répertoire cible (ou dans le fichier d'archive du répertoire principal des données lors de l'utilisation du format tar). Ceci facilite la configuration d'un serveur secondaire en utilisant les résultats de la sauvegarde.

Le fichier postgresql.auto.conf enregistrera les paramètres de connexion et, si indiqué, le slot de réplication utilisé par pg_basebackup, pour que la réplication en streaming utilise plus tard la même configuration.

-t cible
--target=cible

Indique au serveur où placer la sauvegarde de base. La cible par défaut est client, qui indique que la sauvegarde devrait être envoyée à la machine où pg_basebackup est exécuté. Si la cible est configuré à server:/un/chemin, la sauvegarde sera restaurée sur la machine où le serveur est exécuté dans le répertoire /un/chemin. Enregistrer une sauvegarde nécessite des droits de superutilisateur ou d'avoir les droits du rôle pg_write_server_files. Si la cible est configuré à blackhole, le contenu est ignoré et n'est pas sauvegardé. Ceci devrait seulement être utilisé pour des tests. Cela ne devrait pas concerné une sauvegarde réelle.

Comme le flux de journaux de transactions est implémenté par pg_basebackup plutôt que par le serveur, cette option ne peut pas être utilisée avec -Xstream. Comme il s'agit de la valeur par défaut, quand cette option est soumse, vous debez également spécifier soit -Xfetch soit -Xnone.

-T ancien_repertoire=nouveau_repertoire
--tablespace-mapping=ancien_repertoire=nouveau_repertoire

Déplace le tablespace du répertoire ancien_repertoire vers le répertoire nouveau_repertoire pendant la sauvegarde. Pour bien fonctionner, ancien_repertoire doit correspondre exactement à la spécification du tablespace tel qu'il est actuellement défini sur le serveur source. (Mais il n'y a pas d'erreur s'il n'y a aucun tablespace dans ancien_repertoire sur le serveur source.) Pendant ce temps, nouveau_repertoire est un répertoire dans le système de fichiers de l'hôte cible. Comme avec le répertoire principal cible nouveau_repertoire n'a pas besoin d'exister déjà, mais s'il existe, il doit être vide. ancien_repertoire et nouveau_repertoire doivent tous deux être des chemins absolus. S'il se trouve qu'un chemin contient un signe =, échappez-le avec un anti-slash (\). Cette option peut être spécifiée plusieurs fois pour différents tablespaces.

Si un tablespace est déplacé de cette façon, les liens symboliques à l'intérieur du répertoire de données principal sont mis à jour pour pointer vers le nouvel emplacement. Du coup, le nouveau répertoire de données est prêt à être utilisé sur la nouvelle instance avec les nouveaux chemins.

Actuellement, cette option ne fonctionne qu'avec le format de sortie plain. Elle est ignorée sur le format tar est sélectionné.

--waldir=rep_wal

Indique l'emplacement du répertoire des journaux de transactions. Par défaut, les journaux de transactions seront placés dans le sous-répertoire pg_wal du répertoire cible, mais cette option peut être utilisée pour les placer ailleurs. rep_wal doit être un chemin absolu. Comme avec le répertoire principal des données, waldir peut ne pas exister mais s'il existe déjà, il doit être vide. Cette option ne peut être utilisée que quand la sauvegarde est au format plain.

-X methode
--wal-method=methode

Inclut les journaux de transactions requis (fichiers WAL) dans la sauvegarde. Cela inclura toutes les transactions intervenues pendant la sauvegarde. À moins que la méthode none ne soit spécifiée, il est possible de démarrer un postmaster sur le répertoire cible sans avoir besoin de consulter les archives des journaux, ce qui rend la sauvegarde complètement autonome.

Les méthodes suivantes sont supportées pour récupérer les journaux de transactions :

n
none

N'inclut pas les journaux de transactions dans la sauvegarde.

f
fetch

Les journaux de transactions sont récupérés à la fin de la sauvegarde. Il est donc nécessaire de définir le paramètre wal_keep_size du serveur source suffisamment haut pour que les données WAL requises ne soient pas recyclées avant la fin de la sauvegarde. Si les données WAL ont été recyclées avant qu'il n'ait été possible de les transférer, la sauvegarde échouera et sera inutilisable.

Quand le format tar est utilisé, les journaux de transactions seront écrits dans le fichier base.tar.

s
stream

Envoie les données des journaux de transactions lors de la sauvegarde. Cette option ouvre une seconde connexion sur le serveur et entame l'envoi du journal de transactions en parallèle de la sauvegarde. À cet effet, ce mécanisme consommera deux connexions, et non pas juste une. Ce mode permet de ne pas avoir à sauvegarder des journaux de transactions additionnels sur le serveur primaire, aussi longtemps que le client pourra suivre le flux des journaux de transactions.

Quand le format tar est utilisé, les journaux de transactions seront écrits dans un fichier séparé nommé pg_wal.tar (si le serveur est d'une version antérieure à la version 10, le fichier sera nommé pg_xlog.tar).

Cette valeur est la valeur par défaut.

-z
--gzip

Active la compression gzip de l'archive tar en sortie, avec le niveau de compression par défaut. La compression n'est disponible qu'avec le format tar, et le suffixe .gz sera automatiquement ajouté à tous les noms de fichier tar.

-Z niveau
-Z [{client|server}-]method[:detail]
--compress=niveau
--compress=[{client|server}-]method[:detail]

Réclame la compression de la sauvegarde. Si client ou server est inclus, cela indique où la compression doit avoir lieu. Compresser sur le serveur réduira la bande passante réseau mais augmentera la consommation CPU du serveur. La valeur par défaut est client sauf quand --target est utilisé. Dans ce cas, la sauvegarde n'est pas envoyée au client, donc seule la compression serveur est sensible. Quand -Xstream, qui est la valeur par défaut, est utilisé, la compression côté serveur n'est pas appliquée aux journaux de transaction. Pour les compresser, utilisez la compression niveau client ou indiquez -Xfetch.

La méthode de compression peut être gzip, lz4, zstd ou none pour aucune compression. Une chaîne de détails de compression peut être indiquée en option. Si la chaîne de détails est un entier, elle indique l niveau de compression. Sinon elle devra être une ligne d'éléments séparés par des virgules, chacun de la forme motclé ou motclé=valeur. Actuellement, les mots clés acceptés sont level et workers.

Si aucun niveau de compression n'est indiqué, le niveau de compression par défaut sera utilisé. Si seulement un niveau est indiqué sans mention d'un algorithme, la compression gzip sera utilisée si le niveau est supérieur à zéro, et aucune compression ne sera utilisée si le niveau est 0.

Quand le format tar est utilisé avec gzip, lz4 ou zstd, le suffixe, respectivement, .gz, .lz4 ou .zst sera automatiquement ajouté aux noms de fichiers tar. Quand le format plain est utilisée, la compression côté client peut ne pas être précisée mais il est toujours possible de réclamer la compression niveau serveur. Si c'est fait, le serveur compressera la sauvegarde pour transmission, et le client la décompressera et l'extraira.

Quand cette option est utilisée en combinaison avec -Xstream, pg_wal.tar sera compressé en utilisant gzip si la compression gzip côté client est sélectionnée, mais ne sera pas compressé si un autre algorithme de compression est sélectionné ou si la compression côté serveur est sélectionnée.

Les options de ligne de commande suivantes contrôlent la génération de la sauvegarde et l'exécution du programme :

-c {fast|spread}
--checkpoint={fast|spread}

Configure le mode du checkpoint à immédiat (fast) ou étalé (spread, la valeur par défaut). Voir Section 26.3.3.

-C
--create-slot

Indique que le slot de réplication nommé par l'option --slot doit être créé avant d'exécuter la sauvegarde. Une erreur est levée si le slot existe déjà.

-l label
--label=label

Définit un nom pour la sauvegarde. Sans indication, la valeur par défaut, « pg_basebackup base backup », sera utilisée.

-n
--no-clean

Par défaut, quand pg_basebackup échoue avec une erreur, il supprime tous les répertoires qu'il aurait pu créer avant de découvrir qu'il ne peut pas terminer le travail (par exemple, le répertoire de données et le répertoire des journaux de transactions du serveur cible). Cette option désactive le nettoyage, et est donc pratique pour le débogage.

Notez que les répertoires des tablespaces ne sont pas supprimés non plus.

-N
--no-sync

Par défaut, pg_basebackup attendra que tous les fichiers soient écrits de manière sûre sur disque. Cette option demande à pg_basebackup de rendre la main sans attendre, ce qui est plus rapide, mais signifie qu'un arrêt brutal du serveur après la sauvegarde peut laisser la sauvegarde de base dans un état corrompu. De manière générale, cette option est utile durant les tests, mais ne devrait pas être utilisée dans un environnement de production.

-P
--progress

Active l'indicateur de progression. Activer cette option donnera un rapport de progression approximatif lors de la sauvegarde. Comme la base de données peut changer pendant la sauvegarde, ce n'est qu'une approximation, et peut ne pas se terminer à exactement 100%. En particulier, lorsque les journaux de transactions sont inclus dans la sauvegarde, la quantité totale de données ne peut pas être estimée à l'avance et, dans ce cas, la taille cible estimée va augmenter une fois dépassée l'estimation totale sans les journaux.

-r taux
--max-rate=taux

Configure le taux maximum de transfert de données avec lequel les données sont récupérées du serveur source. Ceci peut se révéler utile pour limiter l'impact de pg_basebackup sur le serveur Les valeurs sont en kilooctets par seconde. Le suffixe M indique des mégaoctets par seconde. Un suffixe k est aussi accepté, mais n'a pas d'effet supplémentaire. Les valeurs valides vont de 32 ko/s à 1024 Mo/s.

Cette option concerne le transfert du répertoire de données. Le transfert des journaux de transactions n'est affecté que si la méthode de récupération est fetch.

-S nom_slot
--slot=nom_slot

Cette option ne peut être utilisée qu'avec l'option -X stream. Elle entraîne l'utilisation du slot de réplication indiqué par le flux de réplication des journaux. Si la sauvegarde de base doit être utilisée pour un serveur secondaire avec un slot, ce serveur devra alors utiliser le même nom de slot dans primary_slot_name. Ainsi, on s'assure que le serveur primaire ne supprimera pas les journaux nécessaires entre la fin de la sauvegarde et le début du lancement de la réplication par streaming sur le nouveau secondaire.

Le slot de réplication spécifié doit exister, sauf si l'option -C est aussi utilisée.

Si cette option n'est pas spécifiée, et que le serveur supporte les slots de réplication temporaires (versions 10 et supérieures), alors un slot de réplication temporaire sera automatiquement utilisé pour le transfert des WAL par streaming.

-v
--verbose

Active le mode verbeux. Il affichera des étapes supplémentaires pendant le démarrage et l'arrêt, ainsi que, si le rapport de progression est aussi activé, le nom exact du fichier en cours de traitement.

--manifest-checksums=algorithm

Spécifie l'algorithme à utiliser dans le manifeste de la sauvegarde pour les sommes de contrôle appliquées à chaque fichier. Les algorithmes disponibles sont actuellement NONE, CRC32C, SHA224, SHA256, SHA384 et SHA512. Le défaut est CRC32C.

Si NONE est choisi, le manifeste ne contiendra aucune somme de contrôle. Sinon, il y en aura une pour chaque fichier de la sauvegarde, avec l'algorithme indiqué. De plus, le manifeste contiendra toujours une somme de contrôle SHA256 de son propre contenu. Les algorithmes SHA sont significativement plus consommateurs de CPU que CRC32C ; choisir l'un d'eux peut donc augmenter la durée nécessaire à la sauvegarde.

Une fonction de hachage SHA fournit un résumé cryptographiquement sûr de chaque fichier, pour les utilisateurs voulant vérifier que la sauvegarde n'a pas été modifiée ; alors que l'algorithme CRC32C fournit une somme de contrôle bien plus rapide à calculer, bonne pour déceler des erreurs dues à des changements accidentels, mais vulnérable à des modifications ciblées. Notez que, pour qu'il serve face à un adversaire avec un accès à la sauvegarde, il faut stocker de manière sécurisée, ailleurs, le fichier manifeste, ou vérifier d'une manière ou d'une autre qu'il n'a pas été modifié depuis le moment de la sauvegarde.

pg_verifybackup peut être utilisé pour vérifier l'intégrité d'une sauvegarde grâce à son manifeste.

--manifest-force-encode

Dans le manifeste de la sauvegarde, force l'encodage hexadécimal de tous les noms de fichiers. Sans cette option, seuls les noms de fichiers non-UTF8 sont ainsi encodés. Cette option est surtout destinée à tester que les outils qui lisent un manifeste de sauvegarde traitent correctement ce cas.

--no-estimate-size

Empêche le serveur d'estimer la taille totale de la sauvegarde qui sera renvoyée, et entraînera toujours une valeur NULL pour la colonne backup_total de pg_stat_progress_basebackup.

Sans cette option, la sauvegarde commencera par calculer la taille de toute l'instance, puis procédera à l'envoi du contenu. Cela peut allonger légèrement la sauvegarde, en particulier avant l'envoi des premières données. Si cela est trop long, cette option permet de l'éviter.

Cette option n'est pas autorisée si l'on utilise --progress.

--no-manifest

Désactive la génération du fichier manifeste de la sauvegarde. Sans cette option, le serveur générera et enverra un manifeste, contrôlable avec pg_verifybackup. Ce manifeste est une liste de tous les fichiers présent dans la sauvegarde, à l'exception d'éventuels fichiers WAL. Pour chaque fichier, il stocke aussi la taille, le moment de la dernière modification et, optionnellement, une somme de contrôle.

--no-slot

Empêche la création d'un slot de réplication temporaire pour la sauvegarde.

Par défaut, si le flux de réplication est sélectionné mais qu'aucun nom de slot n'a été donné avec l'option -S, alors un slot de réplication temporaire est créé si cela est supporté par le serveur source).

Le but principal de cette option est de permettre de prendre une sauvegarde de base même si le serveur est à cours de slots de réplication. Utiliser les slots est presque toujours la meilleure solution, car cela empêche le serveur de supprimer les WAL nécessaires pendant la sauvegarde.

--no-verify-checksums

Désactive la vérification des sommes de contrôles, si elles sont activées sur le serveur sur lequel la sauvegarde est réalisée.

Par défaut, les sommes de contrôles sont vérifiées, et les erreurs produiront un code de sortie différent de zéro. Cependant, la sauvegarde ne sera pas supprimée, comme si l'option --no-clean avait été utilisée. Les échecs de vérification des sommes de contrôle seront aussi rapportés dans la vue pg_stat_database.

Les options de ligne de commande suivantes contrôlent la connexion au serveur source :

-d connstr
--dbname=connstr

Indique les paramètres utilisés pour se connecter au serveur sous la forme d'une chaîne de connexion ; elles surchargeront les options en ligne de commande conflictuelles.

Cette option est appelée --dbname par cohérence avec les autres applications clientes, mais comme pg_basebackup ne se connecte à aucune base de données particulière dans l'instance, le nom de la base de données dans la chaîne de connexion est ignorée.

-h hôte
--host=hôte

Indique le nom d'hôte de la machine sur laquelle le serveur de bases de données est exécuté. Si la valeur commence par une barre oblique (/), elle est interprétée comme le répertoire de socket de domaine Unix. La valeur par défaut est fournie par la variable d'environnement PGHOST, si elle est en place ; sinon une connexion sur la socket de domaine Unix est tentée.

-p port
--port=port

Indique le port TCP ou l'extension du fichier local de socket de domaine Unix sur lequel le serveur écoute les connexions. La valeur par défaut est fournie par la variable d'environnement PGPORT, si elle est en place ; sinon il s'agit de la valeur fournie à la compilation.

-s interval
--status-interval=interval

Spécifie le nombre de secondes entre les envois au serveur source des paquets informant de l'état en cours. Des valeurs plus petites permettent une supervision plus précise de la progression de la sauvegarde à partir du serveur source. Une valeur de zéro désactive complètement les mises à jour de statut périodiques, bien qu'une mise à jour sera toujours envoyée sur demande du serveur, pour éviter une déconnexion suite au dépassement d'un délai. La valeur par défaut est de 10 secondes.

-U nom_utilisateur
--username=nom_utilisateur

Indique le nom d'utilisateur pour la connexion.

-w
--no-password

Enpêche l'affichage d'une demande de mot de passe. Si le serveur en réclame un pour l'authentification, et qu'un mot de passe n'est pas disponible d'une autre façon (par exemple avec le fichier .pgpass), la tentative de connexion échouera. Cette option peut être utile dans les batchs et les scripts où aucun utilisateur n'est présent pour saisir un mot de passe.

-W
--password

Force pg_basebackup à demander un mot de passe avant la connexion au serveur source.

Cette option n'est jamais nécessaire, car pg_basebackup demandera automatiquement un mot de passe si le serveur exige une telle authentification. Néanmoins, pg_basebackup gaspillera une tentative de connexion pour découvrir que le serveur veut ce mot de passe. Dans certains cas, il est préférable d'ajouter l'option -W pour éviter la tentative de connexion.

D'autres options sont aussi disponibles :

-V
--version

Affiche la version de pg_basebackup, puis quitte.

-?
--help

Affiche l'aide sur les arguments en ligne de commande de pg_basebackup, puis quitte.

Environnement

Cet outil, comme la plupart des outils PostgreSQL, utilise les variables d'environnement supportées par libpq (voir Section 34.15).

La variable d'environnement PG_COLOR indique s'il faut utiliser les couleurs dans les messages de diagnostique. Les valeurs possibles sont always, auto, never.

Notes

Au début d'une sauvegarde, un checkpoint doit être réalisé sur le serveur cible. Ceci peut prendre un certain temps (tout spécialement si l'option --checkpoint=fast n'est pas utilisée), pendant lequel pg_basebackup semblera inactif.

La sauvegarde inclura tous les fichiers du répertoire de données et des tablespaces, dont les fichiers de configuration, et aussi tout autre fichier placé dans le répertoire par d'autres personnes, à l'exception de certains fichiers temporaires gérés par PostgreSQL. Seuls les fichiers normaux et les répertoires sont cependant copiés. Les liens symboliques utilisés pour les tablespaces sont aussi préservés. Les liens symboliques pointant vers certains répertoires connus de PostgreSQL sont copiés en tant que répertoires vides. Les autres liens symboliques et les fichiers de périphérique spéciaux sont ignorés. Voir Section 55.4 pour des détails précis.

Dans le format plain, les tablespaces seront sauvegardés avec le même chemin que sur le serveur source, sauf si l'option --tablespace-mapping est utilisée. Sans elle, restaurer et lancer une sauvegarde de format plain sur le même serveur ne fonctionnera pas si les tablespaces sont utilisés, car la sauvegarde devra écrire dans les mêmes répertoires que ceux des tablespaces originaux.

Quand le format tar est utilisé, il est de la responsabilité de l'utilisateur de décompresser chaque archive tar avant de démarrer un serveur PostgreSQL qui utilisera ces données. S'il existe des tablespaces supplémentaires, les archives tar les concernant doivent être décompressés au même emplacement. Dans ce cas, les liens symboliques pour ces tablespaces seront créés par le serveur, suivant le contenu du fichier tablespace_map inclus dans le fichier base.tar.

pg_basebackup fonctionne sur les serveurs de même version, ou de version plus ancienne jusqu'à la 9.1. Néanmoins, le streaming des WAL (option -X) ne fonctionne qu'avec un serveur en version 9.3 ou ultérieure, et le format tar (--format=tar) ne fonctionne qu'avec les serveurs de version 9.5 ou ultérieure.

pg_basebackup conservera les droits de groupe pour les fichiers de données si les droits de groupe sont activés sur l'instance cible.

Exemples

Pour créer une sauvegarde de base du serveur mon_sgbd et l'enregistrer dans le répertoire local /usr/local/pgsql/data :

$ pg_basebackup -h mon_sgbd -D /usr/local/pgsql/data
   

Pour créer une sauvegarde du serveur local avec un fichier tar compressé pour chaque tablespace, et stocker le tout dans le répertoire sauvegarde, tout en affichant la progression pendant l'exécution :

$ pg_basebackup -D sauvegarde -Ft -z -P
   

Pour créer une sauvegarde d'une base de données locale avec un seul tablespace, et la compresser avec bzip2 :

$ pg_basebackup -D - -Ft -X fetch | bzip2 > backup.tar.bz2
   

(Cette commande échouera s'il existe plusieurs tablespaces dans l'instance.)

Pour créer une sauvegarde d'une base locale, où le tablespace situé dans /opt/ts doit être déplacé vers ./backup/ts :

$ pg_basebackup -D backup/data -T /opt/ts=$(pwd)/backup/ts
   

Pour créer une sauvegarde d'un serveur local avec un fichier tar pour chaque tablespace compressé avec gzip au niveau 9, enregistré dans le répertoire backup :

$ pg_basebackup -D backup -Ft --compress=gzip:9