PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Principaux outils de sauvegarde pour PostgreSQL

PostgreSQL a la réputation d'être solide comme le roc depuis ses débuts et, au fil des ans, a accumulé un ensemble de fonctionnalités impressionnantes. Cependant, la tranquillité d'esprit que vos données sur disque sont conformes à ACID - si elle n'est pas complétée par une stratégie de sauvegarde équivalente bien pensée - peut être facilement brisée.

Types de sauvegarde

Avant de plonger dans les outils disponibles, examinons les types de sauvegarde PostgreSQL disponibles et quelles sont leurs caractéristiques :

Dumps SQL (ou logiques)

  • Ne bloque pas les lecteurs ni les rédacteurs.
  • Conçu pour de petits ensembles de données en raison de l'impact négatif sur la charge du système et de la longue durée requise pour les opérations de sauvegarde et de restauration. Les performances peuvent être augmentées avec l'indicateur –no-sync, mais reportez-vous à la page de manuel pour les risques associés à la désactivation de l'attente d'écriture.
  • Une ANALYSE post-restauration est requise afin d'optimiser les statistiques.
  • Les objets globaux tels que les rôles et les espaces de table ne peuvent être sauvegardés qu'à l'aide de l'utilitaire pg_dumpall. Notez que les répertoires d'espace de table doivent être créés manuellement avant de démarrer la restauration.
  • Prend en charge le parallélisme au détriment d'une charge système accrue. Lisez man pg_dump pour ses mises en garde et ses exigences particulières, par exemple. instantanés synchronisés.
  • Les vidages peuvent être chargés dans les versions plus récentes de PostgreSQL, ou même dans une autre architecture de machine, mais il n'est pas garanti qu'ils soient rétrocompatibles entre les versions majeures, donc une modification manuelle du fichier de vidage peut être nécessaire.

Système de fichiers (ou physique)

  • Nécessite l'arrêt de la base de données.
  • Plus rapide que les sauvegardes logiques.
  • Comprend des données de cluster.
  • Ne peut être restauré que sur la même version majeure de PostgreSQL.

Archivage continu (ou Point In Time Recovery ou PITR)

  • Convient aux très grandes bases de données où les sauvegardes logiques ou physiques prendraient trop de temps.
  • Certains répertoires à l'intérieur du répertoire de données peuvent être exclus pour accélérer le processus.

Instantanés

  • Nécessite la prise en charge du système d'exploitation — par exemple, LVM fonctionne assez bien, ce qui est également confirmé par NetBackup for PostgreSQL Agent.
  • Convient aux applications où le répertoire de données et la base de données doivent être synchronisés, par ex. Applications LAMP, à condition que les deux instantanés soient synchronisés.
  • Non recommandé lorsque les fichiers de la base de données sont stockés sur plusieurs systèmes de fichiers (doit prendre un instantané de tous les systèmes de fichiers simultanément).

Nuage

Tous les fournisseurs de cloud implémentent des sauvegardes dans leur offre PostgreSQL. Les sauvegardes logiques peuvent être effectuées comme d'habitude, tandis que les sauvegardes physiques et le PITR sont disponibles via les offres de services cloud puisque l'accès au magasin de données n'est pas disponible (voir par exemple Amazon Aurora pour PostgreSQL). Par conséquent, la sauvegarde de PostgreSQL dans le cloud devra être un sujet pour un autre blog.

Base d'agents

  • Nécessite l'installation d'un agent sur les cibles.
  • Peut effectuer des sauvegardes au niveau des blocs, par ex. COMMVAULT (installation prise en charge sur Windows uniquement).

Caractéristiques

Alors que PostgreSQL fournit les outils prêts à l'emploi nécessaires pour effectuer des sauvegardes logiques, physiques et PITR, les applications de sauvegarde spécialisées s'appuient sur les outils natifs de PostgreSQL et du système d'exploitation pour répondre au besoin d'implémenter une stratégie de sauvegarde qui répond aux points suivants :

  • automatisation
  • fréquence
  • durée de conservation
  • intégrité
  • facilité d'utilisation

De plus, les outils de sauvegarde PostgreSQL tentent de fournir des fonctionnalités communes aux outils de sauvegarde génériques tels que :

  • sauvegardes incrémentielles pour économiser de l'espace de stockage
  • catalogues de sauvegarde
  • possibilité de stocker des sauvegardes sur site ou dans le cloud
  • alerte et notification
  • rapports complets
  • contrôle d'accès
  • chiffrement
  • interface graphique et tableaux de bord
  • sauvegardes des hôtes distants
  • débit adaptatif afin de minimiser la charge sur les cibles
  • gestion de plusieurs hôtes en parallèle
  • Orchestration de sauvegarde, par ex. enchaînement d'emplois
  • API REST

Configuration du laboratoire

Pour cet exercice, j'ai configuré un hôte de commande et de contrôle sur lequel j'installerai les outils de sauvegarde, qui exécute également deux instances PostgreSQL - 9.6 et 10 - installées à partir des référentiels PGDG :

[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres  4535     1 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data/
postgres  4538  4535  \_ postgres: logger process
postgres  4540  4535  \_ postgres: checkpointer process
postgres  4541  4535  \_ postgres: writer process
postgres  4542  4535  \_ postgres: wal writer process
postgres  4543  4535  \_ postgres: autovacuum launcher process
postgres  4544  4535  \_ postgres: stats collector process
postgres  4545  4535  \_ postgres: bgworker: logical replication launcher
postgres  4481     1 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
postgres  4483  4481  \_ postgres: logger process
postgres  4485  4481  \_ postgres: checkpointer process
postgres  4486  4481  \_ postgres: writer process
postgres  4487  4481  \_ postgres: wal writer process
postgres  4488  4481  \_ postgres: autovacuum launcher process
postgres  4489  4481  \_ postgres: stats collector process

[[email protected] ~]# netstat -npeelt | grep :543
tcp   0  0  127.0.0.1:5432  0.0.0.0:*  LISTEN  26  79972  4481/postmaster
tcp   0  0  127.0.0.1:5433  0.0.0.0:*  LISTEN  26  81801  4535/postmaster
tcp6  0  0  ::1:5432        :::*       LISTEN  26  79971  4481/postmaster
tcp6  0  0  ::1:5433        :::*       LISTEN  26  81800  4535/postmaster

J'ai également configuré deux instances PostgreSQL distantes exécutant respectivement les mêmes versions 9.6 et 10 :

[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres 10972     1 /usr/pgsql-9.6/bin/postmaster -D /var/lib/pgsql/9.6/data/
postgres 10975 10972  \_ postgres: logger process
postgres 10977 10972  \_ postgres: checkpointer process
postgres 10978 10972  \_ postgres: writer process
postgres 10979 10972  \_ postgres: wal writer process
postgres 10980 10972  \_ postgres: autovacuum launcher process
postgres 10981 10972  \_ postgres: stats collector process

[[email protected] ~]# netstat -npeelt | grep :5432
tcp   0  0  0.0.0.0:5432  0.0.0.0:*  LISTEN  26  34864  10972/postmaster
tcp6  0  0  :::5432       :::*       LISTEN  26  34865  10972/postmaster


[[email protected] ~]# ps -o user,pid,ppid,args --forest -U postgres
USER       PID  PPID COMMAND
postgres 10829     1 /usr/pgsql-10/bin/postmaster -D /var/lib/pgsql/10/data/
postgres 10831 10829  \_ postgres: logger process
postgres 10833 10829  \_ postgres: checkpointer process
postgres 10834 10829  \_ postgres: writer process
postgres 10835 10829  \_ postgres: wal writer process
postgres 10836 10829  \_ postgres: autovacuum launcher process
postgres 10837 10829  \_ postgres: stats collector process
postgres 10838 10829  \_ postgres: bgworker: logical replication launcher

[[email protected] ~]# netstat -npeelt | grep :5432
tcp   0  0  0.0.0.0:5432  0.0.0.0:*  LISTEN  26  34242  10829/postmaster
tcp6  0  0  :::5432       :::*       LISTEN  26  34243  10829/postmaster

Ensuite, utilisez pgbench pour créer un ensemble de données :

pgbench=# \dt+
                          List of relations
 Schema |       Name       | Type  |  Owner   |  Size   | Description
--------+------------------+-------+----------+---------+-------------
 public | pgbench_accounts | table | postgres | 128 MB  |
 public | pgbench_branches | table | postgres | 40 kB   |
 public | pgbench_history  | table | postgres | 0 bytes |
 public | pgbench_tellers  | table | postgres | 40 kB   |
(4 rows)

Outils

Une liste des outils de sauvegarde courants peut être trouvée dans la section PostgreSQL Wiki — Backup. J'ai augmenté la liste avec des produits que j'ai rencontrés au fil des ans et lors d'une récente recherche sur Internet.

Amanda

Amanda est basé sur un agent, open source et prend en charge PostgreSQL prêt à l'emploi via l'API ampgsql. Au moment d'écrire ces lignes, la version 3.5.1 ne prend pas en charge les espaces de table (voir man ampgsql).

Zmanda fournit une version d'entreprise qui est également open source, mais qui n'est pas directement disponible en téléchargement en tant qu'essai.

Amanda nécessite un hôte de sauvegarde dédié car les packages serveur et client s'excluent :

[[email protected] ~]# rpm -qp --conflicts ./amanda-backup_client-3.5.1-1.rhel7.x86_64.rpm
amanda-backup_server
[[email protected] ~]# rpm -qp --conflicts ./amanda-backup_server-3.5.1-1.rhel7.x86_64.rpm
amanda-backup_client

Suivez le guide de configuration de base pour configurer le serveur et le client, puis configurez l'API PostgreSQL.

Voici un git diff de mon labo :

  • Serveur :

    • augmenter l'espace de sauvegarde du serveur :

      --- a/etc/amanda/omiday/amanda.conf
				+++ b/etc/amanda/omiday/amanda.conf
				@@ -13,7 +13,7 @@ amrecover_changer "changer"

				tapetype "TEST-TAPE"
				define tapetype TEST-TAPE {
				1.  length 100 mbytes
				2.  length 500 mbytes
					filemark 4 kbytes
				}

      • définissez la cible PostgreSQL (et désactivez la sauvegarde de l'échantillon) :

        --- a/etc/amanda/omiday/disklist
+++ b/etc/amanda/omiday/disklist
@@ -1,3 +1,2 @@
-localhost /etc simple-gnutar-local
+#localhost /etc simple-gnutar-local
+10.1.9.243 /var/lib/pgsql/9.6/data dt_ampgsql

  • Client :

    • configuration :

      --- /dev/null
+++ b/etc/amanda/omiday/amanda-client.conf
@@ -0,0 +1,5 @@
+property "PG-DATADIR" "/var/lib/pgsql/9.6/data"
+property "PG-ARCHIVEDIR" "/var/lib/pgsql/9.6/archive"
+property "PG-HOST" "/tmp"
+property "PG-USER" "amandabackup"
+property "PG-PASSFILE" "/etc/amanda/pg_passfile"

      • fichier d'authentification :

        --- /dev/null
+++ b/etc/amanda/pg_passfile
@@ -0,0 +1 @@
+/tmp:*:*:amandabackup:pass

    • autoriser le serveur :

      --- a/var/lib/amanda/.amandahosts
+++ b/var/lib/amanda/.amandahosts
@@ -1,2 +1,3 @@
localhost amandabackup amdump
localhost.localdomain amandabackup amdump
+10.1.9.231 amandabackup amdump

    • Authentification PostgreSQL :

      --- a/var/lib/pgsql/9.6/data/pg_hba.conf
+++ b/var/lib/pgsql/9.6/data/pg_hba.conf
@@ -79,7 +79,8 @@
# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
-host    all             all             127.0.0.1/32            ident
+host    all             all             127.0.0.1/32            trust
+host    all             amandabackup    10.1.9.243/32           trust
# IPv6 local connections:
host    all             all             ::1/128                 ident
# Allow replication connections from localhost, by a user with the

    • Configuration PostgreSQL :

      --- a/var/lib/pgsql/9.6/data/postgresql.conf
+++ b/var/lib/pgsql/9.6/data/postgresql.conf
@@ -178,6 +178,7 @@ dynamic_shared_memory_type = posix  # the default is the first option

#wal_level = minimal                   # minimal, replica, or logical
                                       # (change requires restart)
+wal_level = replica
#fsync = on                            # flush data to disk for crash safety
                                                # (turning this off can cause
                                                # unrecoverable data corruption)
@@ -215,10 +216,12 @@ dynamic_shared_memory_type = posix        # the default is the first option

#archive_mode = off            # enables archiving; off, on, or always
                              # (change requires restart)
+archive_mode = on
#archive_command = ''          # command to use to archive a logfile segment
                              # placeholders: %p = path of file to archive
                              #               %f = file name only
                              # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f'
+archive_command = 'test ! -f /var/lib/pgsql/9.6/archive/%f && cp %p /var/lib/pgsql/9.6/archive/%f'
#archive_timeout = 0           # force a logfile segment switch after this
                              # number of seconds; 0 disables

Une fois la configuration ci-dessus terminée, lancez la sauvegarde :

[[email protected] ~]$ amdump omiday

Et vérifiez :

[[email protected] ~]$ amreport omiday
Hostname: cc
Org     : omiday
Config  : omiday
Date    : April 14, 2018

These dumps were to tape MyData01.
The next tape Amanda expects to use is: MyData02.


STATISTICS:
                        Total       Full      Incr.   Level:#
                        --------   --------   --------  --------
Estimate Time (hrs:min)     0:00
Run Time (hrs:min)          0:00
Dump Time (hrs:min)         0:00       0:00       0:00
Output Size (meg)            0.1        0.0        0.1
Original Size (meg)         16.0        0.0       16.0
Avg Compressed Size (%)      0.5        --         0.5
DLEs Dumped                    1          0          1  1:1
Avg Dump Rate (k/s)         33.7        --        33.7

Tape Time (hrs:min)         0:00       0:00       0:00
Tape Size (meg)              0.1        0.0        0.1
Tape Used (%)                0.0        0.0        0.0
DLEs Taped                     1          0          1  1:1
Parts Taped                    1          0          1  1:1
Avg Tp Write Rate (k/s)    830.0        --       830.0


USAGE BY TAPE:
Label                 Time         Size      %  DLEs Parts
MyData01              0:00          83K    0.0     1     1


NOTES:
planner: tapecycle (3) <= runspercycle (3)
planner: Last full dump of 10.1.9.243:/var/lib/pgsql/9.6/data on tape MyData04 overwritten in 3 runs.
taper: tape MyData01 kb 83 fm 1 [OK]


DUMP SUMMARY:
                                                               DUMPER STATS   TAPER STATS
HOSTNAME     DISK                    L ORIG-KB  OUT-KB  COMP%  MMM:SS   KB/s MMM:SS   KB/s
-------------------------------------- ---------------------- -------------- -------------
10.1.9.243   /var/lib/pgsql/9.6/data 1   16416      83    0.5    0:02   33.7   0:00  830.0

(brought to you by Amanda version 3.5.1)

La restauration à partir d'une sauvegarde implique davantage d'étapes manuelles, comme expliqué dans la section restauration.

Selon la FAQ d'Amanda Enterprise, l'amélioration suivante s'appliquerait à notre exemple PostgreSQL :

  • console de gestion pour l'automatisation de la sauvegarde, des règles de conservation et des planifications
  • sauvegarde sur le stockage cloud Amazon S3

Barman

Barman est une solution de reprise après sinistre pour PostgreSQL maintenue par 2ndQuadrant. Il est conçu pour gérer les sauvegardes de plusieurs bases de données et a la capacité de restaurer à un moment antérieur à l'aide de la fonction PITR de PostgreSQL.

Les fonctionnalités de Barman en un coup d'œil :

  • gère ​​plusieurs cibles
  • prise en charge de différentes versions de PostgreSQL
  • zéro perte de données
  • streaming et/ou archivage standard des WAL
  • récupération locale ou à distance
  • récupération simplifiée à un moment précis

Comme indiqué dans le manuel Barman, la prise en charge des sauvegardes incrémentielles, des tâches parallèles, de la déduplication des données et de la compression réseau est disponible uniquement lors de l'utilisation de l'option rsync. De plus, le streaming de WAL à partir d'une veille à l'aide de la commande archive_command n'est actuellement pas pris en charge.

Après avoir suivi les instructions du manuel pour configurer l'environnement, nous pouvons vérifier :

-bash-4.2$ barman list-server
db1 - master
db2 - replica

-bash-4.2$ barman check db1
Server db1:
      PostgreSQL: OK
      is_superuser: OK
      PostgreSQL streaming: OK
      wal_level: OK
      replication slot: OK
      directories: OK
      retention policy settings: OK
      backup maximum age: OK (no last_backup_maximum_age provided)
      compression settings: OK
      failed backups: OK (there are 0 failed backups)
      minimum redundancy requirements: OK (have 0 backups, expected at least 0)
      pg_basebackup: OK
      pg_basebackup compatible: OK
      pg_basebackup supports tablespaces mapping: OK
      archive_mode: OK
      archive_command: OK
      continuous archiving: OK
      pg_receivexlog: OK
      pg_receivexlog compatible: OK
      receive-wal running: OK
      archiver errors: OK

-bash-4.2$ barman check db2
Server db2:
      PostgreSQL: OK
      is_superuser: OK
      PostgreSQL streaming: OK
      wal_level: OK
      replication slot: OK
      directories: OK
      retention policy settings: OK
      backup maximum age: OK (no last_backup_maximum_age provided)
      compression settings: OK
      failed backups: OK (there are 0 failed backups)
      minimum redundancy requirements: OK (have 0 backups, expected at least 0)
      pg_basebackup: OK
      pg_basebackup compatible: OK
      pg_basebackup supports tablespaces mapping: OK
      archive_mode: OK
      archive_command: OK
      continuous archiving: OK
      pg_receivexlog: OK
      pg_receivexlog compatible: OK
      receive-wal running: OK
      archiver errors: OK

Tout est OK, nous pouvons donc tester en sauvegardant les deux hôtes :

-bash-4.2$ barman backup db1
Starting backup using postgres method for server db1 in /var/lib/barman/db1/base/20180414T091155
Backup start at LSN: 0/240001B0 (000000010000000000000024, 000001B0)
Starting backup copy via pg_basebackup for 20180414T091155
Copy done (time: 2 seconds)
Finalising the backup.
This is the first backup for server db1
WAL segments preceding the current backup have been found:
      000000010000000000000023 from server db1 has been removed
Backup size: 201.9 MiB
Backup end at LSN: 0/26000000 (000000010000000000000025, 00000000)
Backup completed (start time: 2018-04-14 09:11:55.783708, elapsed time: 2 seconds)
Processing xlog segments from file archival for db1
      000000010000000000000023
      000000010000000000000024
      000000010000000000000025.00000028.backup
Processing xlog segments from streaming for db1
      000000010000000000000024

-bash-4.2$ barman backup db2
Starting backup using postgres method for server db2 in /var/lib/barman/db2/base/20180414T091225
Backup start at LSN: 0/B0000D0 (00000001000000000000000B, 000000D0)
Starting backup copy via pg_basebackup for 20180414T091225
Copy done (time: 3 seconds)
Finalising the backup.
This is the first backup for server db2
WAL segments preceding the current backup have been found:
      000000010000000000000009 from server db2 has been removed
      00000001000000000000000A from server db2 has been removed
Backup size: 196.8 MiB
Backup end at LSN: 0/D000000 (00000001000000000000000C, 00000000)
Backup completed (start time: 2018-04-14 09:12:25.619005, elapsed time: 3 seconds)
Processing xlog segments from file archival for db2
      00000001000000000000000B
      00000001000000000000000C.00000028.backup
Processing xlog segments from streaming for db2
      00000001000000000000000B

Lister le catalogue de sauvegarde :

-bash-4.2$ barman list-backup all
db1 20180414T091155 - Sat Apr 14 09:11:58 2018 - Size: 217.9 MiB - WAL Size: 0 B
db2 20180414T091225 - Sat Apr 14 09:12:28 2018 - Size: 212.8 MiB - WAL Size: 0 B

Afficher le contenu d'une sauvegarde particulière :

-bash-4.2$ barman list-files db1 20180414T091155 | head
/var/lib/barman/db1/base/20180414T091155/backup.info
/var/lib/barman/db1/base/20180414T091155/data/backup_label
/var/lib/barman/db1/base/20180414T091155/data/PG_VERSION
/var/lib/barman/db1/base/20180414T091155/data/postgresql.auto.conf
/var/lib/barman/db1/base/20180414T091155/data/pg_ident.conf
/var/lib/barman/db1/base/20180414T091155/data/postgresql.conf
/var/lib/barman/db1/base/20180414T091155/data/pg_hba.conf

Lorsque Barman a été configuré pour le streaming WAL synchrone, nous pouvons vérifier l'état de la réplication :

-bash-4.2$ barman replication-status db1
Status of streaming clients for server 'db1':
Current LSN on master: 0/26000528
Number of streaming clients: 1

1. Async WAL streamer
   Application name: barman_receive_wal
   Sync stage      : 3/3 Remote write
   Communication   : TCP/IP
   IP Address      : 10.1.9.231 / Port: 37278 / Host: -
   User name       : streaming_barman
   Current state   : streaming (async)
   Replication slot: barman
   WAL sender PID  : 2046
   Started at      : 2018-04-14 09:04:03.019323+00:00
   Sent LSN   : 0/26000528 (diff: 0 B)
   Write LSN  : 0/26000528 (diff: 0 B)
   Flush LSN  : 0/26000000 (diff: -1.3 KiB)

D'autres améliorations peuvent être ajoutées à l'aide des scripts hook fournis.

Enfin, pour les amateurs de ligne de commande, Barman est livré avec la complétion complète des tabulations.

Outil de sauvegarde et de récupération EDB (BART)

EDB BART est une application propriétaire à source fermée fournie par EnterpriseDB. Il combine la sauvegarde au niveau du système de fichiers natif PostgreSQL et PITR dans un outil facile à utiliser offrant les fonctionnalités suivantes :

  • politiques de conservation
  • sauvegardes incrémentielles
  • sauvegardes physiques complètes à chaud de plusieurs serveurs de base de données Postgres Plus Advanced Server et PostgreSQL
  • gestion de la sauvegarde et de la restauration des serveurs de base de données sur des hôtes locaux ou distants
  • catalogue centralisé pour les données de sauvegarde
  • stocker les données de sauvegarde dans un format compressé
  • vérification de la somme de contrôle

Alors que la version d'essai de la dernière version v2.1 ne peut être obtenue que via une demande de dépôt yum, l'article Data Backup Made Easy et le guide de documentation du produit offrent quelques informations aux personnes curieuses d'en savoir plus.

Téléchargez le livre blanc aujourd'hui PostgreSQL Management &Automation with ClusterControlDécouvrez ce que vous devez savoir pour déployer, surveiller, gérer et faire évoluer PostgreSQLTélécharger le livre blanc

pgArrièreRepos

pgBackRest implémente une sauvegarde complète du système qui ne repose pas sur les outils communs tar et rsync. Il est actuellement hébergé et mis à disposition par CrunchyData sous une licence MIT. Voir Reconnaissance pour plus de détails sur ses origines.

Il offre toutes les fonctionnalités que l'on peut attendre d'un outil centré sur PostgreSQL :

  • débit de sauvegarde/restauration élevé
  • sauvegardes complètes, incrémentielles et différentielles
  • politiques de conservation
  • vérification de l'intégrité des sauvegardes et des restaurations via les sommes de contrôle des fichiers et l'intégration avec les sommes de contrôle des pages PostgreSQL.
  • possibilité de reprendre les sauvegardes
  • compression de flux et sommes de contrôle
  • Prise en charge du stockage cloud Amazon S3
  • Chiffrement

..et beaucoup plus. Reportez-vous à la page du projet pour plus de détails.

L'installation nécessite un système Linux/Unix 64 bits et est décrite dans le guide de l'utilisateur. Le guide présente également au lecteur les principaux concepts, très utiles pour ceux qui découvrent PostgreSQL ou la technologie de stockage.

Bien que le guide utilise des exemples de commandes pour Debian/Ubuntu, pgBackRest est disponible dans le référentiel PGDG yum, et le programme d'installation récupérera toutes les dépendances :

Installation :

pgbackrest       x86_64  2.01-1.rhel7     pgdg10  36k

Installing       for     dependencies:
perl-DBD-Pg      x86_64  2.19.3-4.el7     base    195k
perl-DBI         x86_64  1.627-4.el7      base    802k
perl-Digest-SHA  x86_64  1:5.85-4.el7     base    58k
perl-JSON-PP     noarch  2.27202-2.el7    base    55k
perl-Net-Daemon  noarch  0.48-5.el7       base    51k
perl-PlRPC       noarch  0.2020-14.el7    base    36k
perl-XML-LibXML  x86_64  1:2.0018-5.el7   base    373k
perl-version     x86_64  3:0.99.07-2.el7  base    84k

Configurons deux clusters, pg96 et pg10, chacun ayant un nœud :

  • nœud de contrôle ("référentiel" dans le guide) :

    [[email protected] ~]# cat /etc/pgbackrest.conf
[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y

[pg96]
pg1-path=/var/lib/pgsql/9.6/data
pg1-host=db1
pg1-host-user=postgres

[pg10]
pg1-path=/var/lib/pgsql/10/data
pg1-host=db2
pg1-host-user=postgres

  • groupe #1 :

    [[email protected] ~]# cat /etc/pgbackrest.conf
[global]
log-level-file=detail
repo1-host=repository

[pg96]
pg1-path=/var/lib/pgsql/9.6/data

  • grappe 2 :

    [[email protected] ~]# cat /etc/pgbackrest.conf
[global]
log-level-file=detail
repo1-host=repository

[pg10]
pg1-path=/var/lib/pgsql/10/data

Ensuite, exécutez les sauvegardes et affichez le catalogue de sauvegarde :

-bash-4.2$ pgbackrest --stanza=pg96 info
stanza: pg96
   status: ok

   db (current)
      wal archive min/max (9.6-1): 00000001000000000000003D / 00000001000000000000003D

      full backup: 20180414-120727F
            timestamp start/stop: 2018-04-14 12:07:27 / 2018-04-14 12:08:01
            wal start/stop: 00000001000000000000003D / 00000001000000000000003D
            database size: 185.6MB, backup size: 185.6MB
            repository size: 12.1MB, repository backup size: 12.1MB
-bash-4.2$ pgbackrest --stanza=pg10 info
stanza: pg10
   status: ok

   db (current)
      wal archive min/max (10-1): 000000010000000000000012 / 000000010000000000000012

      full backup: 20180414-120810F
            timestamp start/stop: 2018-04-14 12:08:10 / 2018-04-14 12:08:38
            wal start/stop: 000000010000000000000012 / 000000010000000000000012
            database size: 180.5MB, backup size: 180.5MB
            repository size: 11.6MB, repository backup size: 11.6MB

pgBackRest prend en charge la parallélisation de la sauvegarde et de la restauration — en suivant l'exemple du guide, nous prenons en charge un seul processeur, puis nous mettons à jour la configuration pour utiliser 2 processeurs :

--- a/etc/pgbackrest.conf
+++ b/etc/pgbackrest.conf
@@ -2,6 +2,7 @@
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
start-fast=y
+process-max=2

[pg96]
pg1-host=db1

Le résultat :

-bash-4.2$ pgbackrest --stanza=pg96 info
stanza: pg96
    status: ok

    db (current)
        wal archive min/max (9.6-1): 00000001000000000000003D / 000000010000000000000041

        full backup: 20180414-120727F
            timestamp start/stop: 2018-04-14 12:07:27 / 2018-04-14 12:08:01
            wal start/stop: 00000001000000000000003D / 00000001000000000000003D
            database size: 185.6MB, backup size: 185.6MB
            repository size: 12.1MB, repository backup size: 12.1MB

        incr backup: 20180414-120727F_20180414-121434I
            timestamp start/stop: 2018-04-14 12:14:34 / 2018-04-14 12:14:52
            wal start/stop: 00000001000000000000003F / 00000001000000000000003F
            database size: 185.6MB, backup size: 8.2KB
            repository size: 12.1MB, repository backup size: 431B
            backup reference list: 20180414-120727F

        incr backup: 20180414-120727F_20180414-121853I
            timestamp start/stop: 2018-04-14 12:18:53 / 2018-04-14 12:19:08
            wal start/stop: 000000010000000000000041 / 000000010000000000000041
            database size: 185.6MB, backup size: 8.2KB
            repository size: 12.1MB, repository backup size: 429B
            backup reference list: 20180414-120727F

Avec 2 processeurs, la sauvegarde s'est exécutée presque 20 % plus rapidement, ce qui peut faire une grande différence lors de l'exécution sur un grand ensemble de données.

Conclusion

Les outils de sauvegarde centrés sur PostgreSQL offrent, comme prévu, plus d'options que les outils à usage général. La plupart des outils de sauvegarde PostgreSQL offrent les mêmes fonctionnalités de base, mais leur implémentation introduit des limitations qui ne peuvent être découvertes qu'en suivant attentivement la documentation pour tester le produit.

De plus, ClusterControl offre une gamme de fonctionnalités de sauvegarde et de restauration que vous pouvez utiliser dans le cadre de la configuration de la gestion de votre base de données.