Les sauvegardes de bases de données jouent un rôle essentiel dans la conception d'une stratégie efficace de reprise après sinistre pour les bases de données de production. Les administrateurs et les architectes de bases de données doivent travailler en permanence à la conception d'une stratégie de sauvegarde optimale et efficace pour les bases de données critiques en temps réel et s'assurer en outre que les SLA de reprise après sinistre sont satisfaits. Selon mon expérience, ce n'est pas facile et cela peut prendre de quelques jours à quelques semaines pour parvenir à une stratégie de sauvegarde impeccable. Il ne s'agit tout simplement pas d'écrire un bon script pour sauvegarder les bases de données et s'assurer que cela fonctionne. Il y a plusieurs facteurs à considérer, examinons-les :
- Taille de la base de données : La taille de la base de données joue un rôle important lors de la conception des stratégies de sauvegarde. En fait, c'est l'un des principaux facteurs qui définit
- Temps pris par la sauvegarde
- La charge sur les composants de l'infrastructure tels que le disque, le réseau, le processeur, etc.
- Nombre de stockage de sauvegarde requis et les coûts impliqués
- Si les bases de données sont hébergées sur le cloud, les coûts de stockage de sauvegarde dépendent de la quantité de stockage requise
- En outre, la taille de la base de données a un impact sur le RTO
- Infrastructure : La stratégie de sauvegarde repose fortement sur l'infrastructure des bases de données. La procédure de sauvegarde serait différente pour les bases de données hébergées sur un serveur physique dans un centre de données sur site par rapport à celles hébergées sur le cloud.
- Emplacement de sauvegarde : Où vont les sauvegardes ? Généralement, les sauvegardes seront placées à un emplacement distant, par exemple sur une bande ou un stockage spécifique au cloud comme AWS S3.
- Outil de sauvegarde : Identifiez un outil optimal pour effectuer une sauvegarde de base de données en ligne qui garantit potentiellement une sauvegarde cohérente.
Une bonne stratégie de sauvegarde de base de données doit garantir que le RTO (Recovery Time Objective) et le RPO (Recovery Point Objective) sont atteints, ce qui à son tour aide à atteindre l'objectif de Disaster Recovery. Les sauvegardes au niveau du système de fichiers peuvent être effectuées sur les bases de données PostgreSQL de plusieurs manières. Dans ce blog, je me concentrerai sur un outil appelé Barman qui est couramment utilisé pour effectuer des sauvegardes de bases de données PostgreSQL.
Barman (gestionnaire de sauvegarde et de récupération) est un outil open source basé sur Python développé par les développeurs de 2nd Quadrant. Cet outil est développé pour réaliser une stratégie de sauvegarde de base de données de niveau entreprise pour les bases de données de production PostgreSQL critiques. Ses caractéristiques et caractéristiques ressemblent à celles du RMAN d'Oracle. À mon avis, barman est l'une des meilleures options pour les bases de données PostgreSQL et peut offrir plusieurs avantages du point de vue des opérations aux administrateurs de base de données et aux ingénieurs d'infrastructure.
Examinons quelques fonctionnalités de Barman :
Je vais commencer par un aperçu de la configuration, puis énumérer les types de sauvegardes pouvant être effectuées
Techniquement, barman-cli est un outil basé sur python et a deux fichiers de configuration différents à gérer. Un fichier qui est la configuration réelle de la base de données à sauvegarder réside dans les noms "/etc/barman.d" comme
Un exemple de contenu du fichier /etc/barman.conf est présenté ci-dessous
[barman]
barman_user = barman ---------> barman user who performs backup/recovery of database
configuration_files_directory = /etc/barman.d -----> location for DB configuration files
barman_home = /dbbackups/barman ---> barman home directory
log_file = /dbbackups/barman/logs/barman.log ---> barman log file location
log_level = INFO -----> level of logging for barman operations
compression = gzip -----> backups must be compressed
Installation de Barman
Jetons un coup d'œil à la procédure d'installation de barman -
Installation à partir de la source
Téléchargez le barman depuis le https://www.pgbarman.org/
Décompressez / décompressez le programme d'installation et exécutez la commande suivante en tant qu'utilisateur root -
[[email protected] barman-2.4]# ./setup.py install
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'setup_requires'
warnings.warn(msg)
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'install_requires'
warnings.warn(msg)
/usr/lib64/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'tests_require'
warnings.warn(msg)
running install
running build
running build_py
creating build
creating build/lib
creating build/lib/barman
copying barman/utils.py -> build/lib/barman
copying barman/fs.py -> build/lib/barman
copying barman/retention_policies.py -> build/lib/barman
copying barman/diagnose.py -> build/lib/barman
copying barman/backup.py -> build/lib/barman
copying barman/recovery_executor.py -> build/lib/barman
copying barman/backup_executor.py -> build/lib/barman
copying barman/config.py -> build/lib/barman
copying barman/process.py -> build/lib/barman
copying barman/output.py -> build/lib/barman
copying barman/__init__.py -> build/lib/barman
copying barman/remote_status.py -> build/lib/barman
copying barman/xlog.py -> build/lib/barman
copying barman/lockfile.py -> build/lib/barman
copying barman/postgres.py -> build/lib/barman
copying barman/server.py -> build/lib/barman
copying barman/cli.py -> build/lib/barman
copying barman/version.py -> build/lib/barman
copying barman/compression.py -> build/lib/barman
copying barman/wal_archiver.py -> build/lib/barman
copying barman/infofile.py -> build/lib/barman
copying barman/exceptions.py -> build/lib/barman
copying barman/hooks.py -> build/lib/barman
copying barman/copy_controller.py -> build/lib/barman
copying barman/command_wrappers.py -> build/lib/barman
running build_scripts
creating build/scripts-2.7
copying and adjusting bin/barman -> build/scripts-2.7
changing mode of build/scripts-2.7/barman from 644 to 755
running install_lib
creating /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/utils.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/fs.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/retention_policies.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/diagnose.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/backup.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/recovery_executor.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/backup_executor.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/config.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/process.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/output.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/__init__.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/remote_status.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/xlog.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/lockfile.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/postgres.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/server.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/cli.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/version.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/compression.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/wal_archiver.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/infofile.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/exceptions.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/hooks.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/copy_controller.py -> /usr/lib/python2.7/site-packages/barman
copying build/lib/barman/command_wrappers.py -> /usr/lib/python2.7/site-packages/barman
byte-compiling /usr/lib/python2.7/site-packages/barman/utils.py to utils.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/fs.py to fs.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/retention_policies.py to retention_policies.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/diagnose.py to diagnose.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/backup.py to backup.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/recovery_executor.py to recovery_executor.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/backup_executor.py to backup_executor.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/config.py to config.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/process.py to process.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/output.py to output.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/__init__.py to __init__.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/remote_status.py to remote_status.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/xlog.py to xlog.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/lockfile.py to lockfile.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/postgres.py to postgres.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/server.py to server.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/cli.py to cli.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/version.py to version.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/compression.py to compression.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/wal_archiver.py to wal_archiver.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/infofile.py to infofile.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/exceptions.py to exceptions.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/hooks.py to hooks.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/copy_controller.py to copy_controller.pyc
byte-compiling /usr/lib/python2.7/site-packages/barman/command_wrappers.py to command_wrappers.pyc
running install_scripts
copying build/scripts-2.7/barman -> /usr/bin
changing mode of /usr/bin/barman to 755
running install_data
copying doc/barman.1 -> /usr/share/man/man1
copying doc/barman.5 -> /usr/share/man/man5
running install_egg_info
Writing /usr/lib/python2.7/site-packages/barman-2.4-py2.7.egg-info
Installation à partir du dépôt
L'installation peut également être effectuée via yum comme suit
[[email protected]~]$ yum install barman
Jetons un coup d'œil aux différents types de sauvegardes prises en charge par barman
Sauvegardes physiques à chaud
Barman prend en charge les sauvegardes à chaud physiques, ce qui signifie une sauvegarde en ligne des fichiers de données physiques et des fichiers journaux des transactions de la base de données à l'aide de la méthodologie rsync qui peut également être sous forme compressée.
Jetons un coup d'œil aux étapes et aux commandes pour effectuer une sauvegarde RSYNC à l'aide de barman
#1 fichier de configuration de la base de données PostgreSQL pour barman
[pgdb]
description="Main PostgreSQL server"
conninfo=host=pgserver user=postgres dbname=postgres
ssh_command=ssh [email protected]
archiver=on
backup_method = rsync
"pgdb" est l'identifiant de la base de données Postgres pour barman et le nom du fichier de configuration doit être
Le paramètre backup_method définit le type de sauvegarde à effectuer. Dans ce cas, backup_method est rsync.
Remarque :Pour que la commande barman backup réussisse, l'authentification ssh sans mot de passe doit être configurée entre les serveurs barman et postgres.
#2 paramètres du fichier postgresql.conf
wal_level=replica
archive_mode=on
archive_command=’rsync to <ARCHIVE LOCATION>’
Commande de sauvegarde de Barman
#3 Vérifiez si le barman est prêt à effectuer des sauvegardes
[[email protected] pgdb]$ barman check pgdb
Server pgdb:
PostgreSQL: OK
is_superuser: OK
wal_level: 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 4 backups, expected at least 0)
ssh: OK (PostgreSQL server)
not in recovery: OK
archive_mode: OK
archive_command: OK
continuous archiving: OK
archiver errors: OK
La sortie ci-dessus indique que tout est "OK" pour procéder à la sauvegarde, ce qui signifie que vous êtes prêt à effectuer une sauvegarde.
Par exemple, la sortie ci-dessous indique que la sauvegarde ne peut pas être effectuée car, selon le barman, SSH ne fonctionne pas -
[[email protected] ~]$ barman check pgdb
Server pgdb:
PostgreSQL: OK
is_superuser: OK
wal_level: 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)
ssh: FAILED (Connection failed using '[email protected] -o BatchMode=yes -o StrictHostKeyChecking=no' return code 127)
not in recovery: OK
archive_mode: OK
archive_command: OK
continuous archiving: OK
archiver errors: OK
#4 Effectuer une sauvegarde de la base de données
[[email protected] ~]$ barman backup pgdb
Starting backup using rsync-exclusive method for server pgdb in /dbbackup/barman_backups/pgdb/base/20180816T153846
Backup start at LSN: 0/1C000028 (00000001000000000000001C, 00000028)
This is the first backup for server pgdb
WAL segments preceding the current backup have been found:
00000001000000000000000B from server pgdb has been removed
00000001000000000000000C from server pgdb has been removed
00000001000000000000000D from server pgdb has been removed
00000001000000000000000E from server pgdb has been removed
00000001000000000000000F from server pgdb has been removed
000000010000000000000010 from server pgdb has been removed
000000010000000000000011 from server pgdb has been removed
000000010000000000000012 from server pgdb has been removed
000000010000000000000013 from server pgdb has been removed
000000010000000000000014 from server pgdb has been removed
000000010000000000000015 from server pgdb has been removed
000000010000000000000016 from server pgdb has been removed
Starting backup copy via rsync/SSH for 20180816T153846
Copy done (time: 1 second)
This is the first backup for server pgdb
Asking PostgreSQL server to finalize the backup.
Backup size: 21.8 MiB
Backup end at LSN: 0/1C0000F8 (00000001000000000000001C, 000000F8)
Backup completed (start time: 2018-08-16 15:38:46.668492, elapsed time: 1 second)
Processing xlog segments from file archival for pgdb
000000010000000000000016
000000010000000000000017
000000010000000000000018
000000010000000000000019
00000001000000000000001A
00000001000000000000001B
00000001000000000000001C
00000001000000000000001C.00000028.backup
Pour comprendre si la commande de sauvegarde du barman réussira même, la commande ci-dessous aide -
Sauvegardes incrémentielles
Une autre grande capacité de Barman est la possibilité d'effectuer des sauvegardes incrémentielles. Cela signifie que seuls les blocs modifiés depuis la dernière sauvegarde complète de la base de données peuvent être sauvegardés. Pour les bases de données qui subissent moins de modifications de données, leur sauvegarde incrémentielle peut réduire l'utilisation des ressources.
Cela dépend fortement de rsync et des liens physiques. Vous trouverez ci-dessous les avantages des sauvegardes incrémentielles –
- Réduit considérablement le temps de sauvegarde quotidien
- Le volume de données sauvegardées diminue car seuls les blocs de données modifiés seront sauvegardés, ce qui réduit l'utilisation des ressources d'infrastructure telles que la bande passante du réseau, l'espace disque, les E/S, etc.
- Si vous recherchez un très bon RTO, c'est la fonctionnalité que vous recherchez
Les commandes pour la sauvegarde incrémentielle sont à peu près les mêmes. Toutes les sauvegardes ultérieures après la première sauvegarde effectuée avec l'option backup_method=rsync seront des sauvegardes incrémentielles et barman extrait les WAL à l'aide de l'utilitaire pg_recievexlog.
Sauvegardes et récupération de bases de données à distance
Cette capacité de Barman est très bénéfique pour les DBA à mon avis. La première chose que les administrateurs de bases de données rechercheraient est d'éviter autant que possible de solliciter les ressources du serveur de base de données de production pendant les sauvegardes et de les effectuer à distance serait la meilleure option. Barman exploite pg_basebackup, ce qui facilite grandement la création de scripts et l'automatisation.
En général, les options traditionnellement disponibles pour les sauvegardes automatisées seront -
- pg_basebackup
- copie tar
Les deux options ci-dessus impliquent beaucoup de développement et de tests pour s'assurer qu'une stratégie de sauvegarde efficace est en place pour répondre aux exigences des SLA et peut poser des problèmes pour les grandes bases de données avec plusieurs tablespaces.
Avec Barman, c'est assez simple. Une autre capacité exceptionnelle de barman est le streaming WAL continu. Voyons cela un peu plus en détail.
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 blancSauvegarde en streaming avec streaming WAL continu
Cela rend le barman remarquable par rapport aux autres outils du marché. Les fichiers WAL en direct peuvent être diffusés en continu vers un emplacement de sauvegarde distant à l'aide de Barman. C'est LA FONCTION que les administrateurs de bases de données seraient ravis de connaître. J'étais excité de savoir à ce sujet. Il est extrêmement difficile, voire impossible, d'y parvenir avec des scripts construits manuellement ou avec une combinaison d'outils comme pg_basebackup et pg_receivewal. Avec le streaming WAL continu, un meilleur RPO peut être atteint. Si la stratégie de sauvegarde est conçue méticuleusement, il ne serait pas exagéré de dire qu'un RPO proche de 0 peut être atteint.
Regardons les étapes, les commandes pour effectuer une sauvegarde de barman en streaming
#1 changements de paramètre postgresql.conf
Suite des configurations à faire dans le postgresql.conf
wal_level=replica
max_wal_senders = 2
max_replication_slots = 2
synchronous_standby_names = 'barman_receive_wal'
archive_mode=on
archive_command = 'rsync -a %p [email protected]:INCOMING_WAL_DIRECTORY/%f'
archive_timeout=3600 (should not be 0 or disabled)
#2 Créer un emplacement de réplication à l'aide de barman
L'emplacement de réplication est important pour les sauvegardes en continu. En cas d'échec de la diffusion continue des WAL pour une raison quelconque, tous les WAL non diffusés peuvent être conservés dans la base de données postgres sans être supprimés.
[[email protected] ~]$ barman receive-wal --create-slot pgdb
Creating physical replication slot 'barman' on server 'pgdb'
Replication slot 'barman' created
#3 Configurer le fichier de configuration du serveur de base de données pour barman
L'identifiant de base de données pour barman est "pgdb". Un fichier de configuration appelé pgdb.conf doit être créé à l'emplacement /etc/barman.d/ avec le contenu suivant
[pgdb]
description="Main PostgreSQL server"
conninfo=host=pgserver user=postgres dbname=postgres
streaming_conninfo=host=pgserver user=barman
backup_method=postgres
archiver=on
incoming_wals_directory=/dbbackups/barman_backups/pgdb/incoming
streaming_archiver=on
slot_name=barman
streaming_conninfo est le paramètre à configurer pour que barman effectue des sauvegardes en streaming
backup_method doit être configuré sur "postgres" lorsque la sauvegarde en continu doit être effectuée
streaming_archiver doit être configuré sur "on"
slot_name=barman Ce paramètre doit être configuré lorsque vous avez besoin que barman utilise des slots de réplication. Dans ce cas, le nom de l'emplacement de réplication est barman
Une fois la configuration terminée, effectuez une vérification du barman pour vous assurer que les sauvegardes en continu fonctionneront correctement.
#4 Vérifiez si barman receive-wal fonctionne correctement
En général, pour le premier barman receive-wal ne fonctionne pas immédiatement après les modifications de configuration, une erreur peut se produire et la commande barman check peut afficher ce qui suit -
[[email protected] archive_status]$ barman check pgdb
Server pgdb:
PostgreSQL: OK
is_superuser: OK
PostgreSQL streaming: OK
wal_level: 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: FAILED (See the Barman log file for more details)
archiver errors: OK
Lorsque vous exécutez barman receive-wal, il peut se bloquer. Pour que receive-wal fonctionne correctement pour la première fois, la commande ci-dessous doit être exécutée.
[[email protected] arch_logs]$ barman cron
Starting WAL archiving for server pgdb
Starting streaming archiver for server pgdb
Maintenant, refaites une vérification au barman, ça devrait être bon maintenant.
[[email protected] arch_logs]$ barman check pgdb
Server pgdb:
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 2 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
Si vous pouvez le voir, l'état de receivexlog indique ok. C'est l'un des problèmes auxquels j'ai été confronté.
#5 Vérifiez si le barman est prêt à effectuer des sauvegardes
[[email protected] ~]$ barman check pgdb
Server pgdb:
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 4 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
#6 Vérifiez l'état du streaming à l'aide de barman
[[email protected] pgdb]$ barman replication-status pgdb
Status of streaming clients for server 'pgdb':
Current LSN on master: 0/250008A8
Number of streaming clients: 1
1. #1 Sync WAL streamer
Application name: barman_receive_wal
Sync stage : 3/3 Remote write
Communication : TCP/IP
IP Address : 192.168.1.10 / Port: 52602 / Host: -
User name : barman
Current state : streaming (sync)
Replication slot: barman
WAL sender PID : 26592
Started at : 2018-08-16 16:03:21.422430+10:00
Sent LSN : 0/250008A8 (diff: 0 B)
Write LSN : 0/250008A8 (diff: 0 B)
Flush LSN : 0/250008A8 (diff: 0 B)
Le statut ci-dessus signifie que le barman est prêt à effectuer une sauvegarde en continu. Effectuez la sauvegarde comme indiqué ci-dessous -
[[email protected] arch_logs]$ barman backup pgdb
Starting backup using postgres method for server pgdb in /dbbackup/barman_backups/pgdb/base/20180816T160710
Backup start at LSN: 0/1F000528 (00000001000000000000001F, 00000528)
Starting backup copy via pg_basebackup for 20180816T160710
Copy done (time: 1 second)
Finalising the backup.
Backup size: 21.9 MiB
Backup end at LSN: 0/21000000 (000000010000000000000020, 00000000)
Backup completed (start time: 2018-08-16 16:07:10.401526, elapsed time: 1 second)
Processing xlog segments from file archival for pgdb
00000001000000000000001F
000000010000000000000020
000000010000000000000020.00000028.backup
000000010000000000000021
Processing xlog segments from streaming for pgdb
00000001000000000000001F
000000010000000000000020
Sauvegardes centralisées et cataloguées
Est très bénéfique pour les environnements exécutant plusieurs bases de données sur plusieurs serveurs dans un environnement en réseau. C'est l'une des particularités exceptionnelles de Barman. J'ai travaillé dans des environnements en temps réel où je devais gérer, administrer des centaines de bases de données et j'ai toujours ressenti le besoin de sauvegardes de bases de données centralisées et c'est pourquoi Oracle RMAN est devenu populaire pour la stratégie de sauvegarde de bases de données Oracle et maintenant Barman remplit cela espace pour PostgreSQL. Avec Barman, les ingénieurs DBA et DevOps peuvent travailler à la création d'un serveur de sauvegarde centralisé dans lequel les sauvegardes de base de données pour toutes les bases de données sont maintenues, validées.
Signification des sauvegardes cataloguées, barman maintient un référentiel centralisé dans lequel les statuts de toutes les sauvegardes sont conservés. Vous pouvez vérifier les sauvegardes disponibles pour une base de données particulière comme indiqué ci-dessous -
[[email protected] ~]$ barman list-backup pgdb
pgdb 20180816T160924 - Thu Aug 16 16:09:25 2018 - Size: 22.0 MiB - WAL Size: 135.7 KiB
pgdb 20180816T160710 - Thu Aug 16 16:07:11 2018 - Size: 21.9 MiB - WAL Size: 105.8 KiB
pgdb 20180816T153913 - Thu Aug 16 15:39:15 2018 - Size: 21.9 MiB - WAL Size: 54.2 KiB
pgdb 20180816T153846 - Thu Aug 16 15:38:48 2018 - Size: 21.9 MiB - WAL Size: 53.0 KiB
Politique de conservation des sauvegardes
Politiques de conservation peut être défini pour les sauvegardes de bases de données. Les sauvegardes peuvent être rendues obsolètes après une certaine période et les sauvegardes obsolètes peuvent être supprimées de temps à autre.
Il existe des options dans le fichier de configuration pour s'assurer que les sauvegardes sont conservées et rendues obsolètes lorsque la période de rétention dépasse -
Le premier paramètre à configurer est minimum_redundancy . Configurez toujours minimum_redundancy sur>0 pour vous assurer que les sauvegardes ne sont pas supprimées accidentellement.
Exemple :minimum_redundancy =1
- retention_policy déterminera la durée de conservation des sauvegardes de base pour garantir le respect des SLA de reprise après sinistre.
- wal_retention_policy déterminera pendant combien de temps les sauvegardes wal doivent être conservées. Cela permet de s'assurer que le RPO attendu est atteint.
Les politiques de rétention et de redondance existantes pour un serveur de base de données peuvent être vérifiées à l'aide de la commande barman check comme suit
[[email protected] ~]$ barman check pgdb
Server pgdb:
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 4 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
Sauvegardes et restaurations parallèles peut être effectué en utilisant plusieurs processeurs, ce qui accélère vraiment les sauvegardes et les restaurations. Cette fonctionnalité est avantageuse pour les très grandes bases de données pouvant atteindre des téraoctets.
Pour exécuter des sauvegardes en parallèle, ajoutez l'option suivante dans le fichier de configuration du serveur de base de données (qui est le fichier /etc/barman.d/pgdb.conf)-
parallel_jobs = 1
Je peux conclure en disant que barman est un outil de niveau entreprise qui peut potentiellement aider les administrateurs de base de données à concevoir une stratégie de reprise après sinistre efficace.
Ressources associées ClusterControl pour PostgreSQLEn savoir plus Utiliser pg_dump et pg_dumpall pour sauvegarder PostgreSQLLire le blog Top Outils de sauvegarde pour PostgreSQLLire le blog Devenir un administrateur de base de données PostgreSQL - Sauvegardes PostgreSQL logiques et physiquesLire le blog