sql >> Database teknologi >  >> RDS >> PostgreSQL

Brug af Barman til at sikkerhedskopiere PostgreSQL - en oversigt

Databasesikkerhedskopiering spiller en afgørende rolle i udformningen af ​​en effektiv katastrofegendannelsesstrategi for produktionsdatabaser. Databaseadministratorer og arkitekter skal løbende arbejde hen imod at designe en optimal og effektiv backup-strategi for missionskritiske databaser i realtid og yderligere sikre, at Disaster Recovery SLA'er er opfyldt. Som min erfaring er, er dette ikke let og kan tage fra dage til uger at opnå en upåklagelig backup-strategi. Det er bare ikke at skrive et godt script til at sikkerhedskopiere databaser og sørge for, at det virker. Der er flere faktorer at overveje, lad os tage et kig på dem:

  • Databasestørrelse: Databasestørrelse spiller en vigtig rolle, når man designer backupstrategier. Faktisk er dette en af ​​kernefaktorerne, der definerer
    • Tid, som sikkerhedskopien tager
    • Belastningen på infrastrukturkomponenterne som disk, netværk, CPU osv.
    • Mængden af ​​krævet backuplager og de involverede omkostninger
    • Hvis databaserne hostes på skyen, afhænger omkostningerne til backuplagring af mængden af ​​krævet lagerplads
    • Derudover påvirker databasestørrelsen RTO'en
  • Infrastruktur: Backup-strategi er stærkt afhængig af databasernes infrastruktur. Sikkerhedskopieringsproceduren ville være anderledes for databaser hostet på en fysisk server i et lokalt datacenter sammenlignet med dem der hostes på skyen.
  • Sikkerhedskopieringsplacering: Hvor skal sikkerhedskopierne hen? Generelt vil sikkerhedskopierne blive placeret et fjerntliggende sted, for eksempel på bånd- eller skyspecifikt lager som AWS S3.
  • Sikkerhedskopieringsværktøj: Identificer et optimalt værktøj til at udføre online database backup, som potentielt sikrer, at der er taget ensartet backup.

En god database backup-strategi skal sikre, at RTO (Recovery Time Objective) og RPO (Recovery Point Objective) er opfyldt, hvilket igen hjælper med at nå Disaster Recovery-målet. Sikkerhedskopier på filsystemniveau kan udføres på PostgreSQL-databaser på flere måder. I denne blog vil mit fokus være på et værktøj kaldet Barman, som populært bruges til at udføre PostgreSQL Database Backups.

Barman (backup and recovery manager) er et Python-baseret open source-værktøj udviklet af udviklere på 2nd Quadrant. Dette værktøj er udviklet til at opnå en strategi for sikkerhedskopiering af databaser i virksomhedsklasse til missionskritiske PostgreSQL-produktionsdatabaser. Dens funktioner og egenskaber ligner Oracles RMAN. Efter min mening er barman en af ​​de bedste muligheder for PostgreSQL-databaser og kan levere adskillige fordele fra driftsperspektivet til DBA'er og infrastrukturingeniører.

Lad os se på nogle funktioner i Barman:

Jeg vil starte med konfigurationsoversigt og derefter liste over, hvilke slags sikkerhedskopier der kan udføres

Teknisk set er barman-cli et python-baseret værktøj og har to forskellige konfigurationsfiler at håndtere. En fil, som er den faktiske konfiguration for databasen, der skal sikkerhedskopieres, ligger i "/etc/barman.d" navne som .conf og den anden fil, som har de barmand-relaterede parametre (som f.eks. barman backup placering, barman server, logfiler osv.) konfigureret ligger i “/etc” (/etc/barman.conf). Barman-konfigurationsfilerne har MySQL-parameterkonfiguration.

Eksempel på indholdet af filen /etc/barman.conf er vist nedenfor

[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 af Barman

Lad os tage et kig på installationsproceduren for barman -

Installerer fra kilden

Download bartenderen fra https://www.pgbarman.org/

Untar / unzip installationsprogrammet og udfør følgende kommando som root-bruger -

[[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

Installerer fra arkivet

Installation kan også udføres via yum som følger

[[email protected]~]$ yum install barman

Lad os tage et kig på forskellige typer sikkerhedskopier, som barman understøtter

Physical Hot Backups

Barman understøtter Physical Hot Backups, hvilket betyder online backup af fysiske datafiler og transaktionslogfiler i databasen ved hjælp af rsync-metoden, som også kan være i komprimeret form.

Lad os tage et kig på trinene og kommandoerne til at udføre RSYNC backup ved hjælp af barman

#1 PostgreSQL-databasekonfigurationsfil til barmand

[pgdb]
description="Main PostgreSQL server"
conninfo=host=pgserver user=postgres dbname=postgres
ssh_command=ssh [email protected]
archiver=on
backup_method = rsync

“pgdb” er identifikatoren for Postgres-databasen for barman, og konfigurationsfilnavnet skal være .conf placeret i /etc/barman.d/. Når barman backup-kommandoen udføres, leder barman efter sektionen [pgdb] i filen pgdb.conf.

Parameteren backup_method definerer typen af ​​backup, der skal tages. I dette tilfælde er backup_method rsync.

Bemærk:For at barman backup-kommandoen skal lykkes, skal ssh-godkendelse uden adgangskode konfigureres mellem barman- og postgres-servere.

#2 postgresql.conf filparametre

wal_level=replica
archive_mode=on
archive_command=’rsync to <ARCHIVE LOCATION>’

Barmans backup-kommando

#3 Tjek om barman er klar til at udføre sikkerhedskopier

[[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

Ovenstående output siger, at alt er "OK" for at fortsætte med sikkerhedskopieringen, hvilket betyder, at du er god til at tage en sikkerhedskopi.

Nedenstående output siger for eksempel, at backup ikke kan tages, fordi SSH ifølge barmand ikke virker -

[[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 Udfør databasesikkerhedskopiering

[[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

For at forstå, om barman backup-kommandoen overhovedet vil være vellykket, hjælper nedenstående kommando -

Inkrementelle sikkerhedskopier

En anden stor egenskab ved Barman er evnen til at tage trinvise sikkerhedskopier. Det betyder, at kun de ændrede blokke siden den sidste fuldstændige database backup kan sikkerhedskopieres. For databaser, der gennemgår færre dataændringer, kan trinvis sikkerhedskopiering af dem reducere ressourceforbruget.

Det afhænger meget af rsync og hard-links. Nedenfor er fordelene ved inkrementelle sikkerhedskopier –

  • Reducerer den daglige backup-tid markant
  • Mængden af ​​data, der sikkerhedskopieres, reduceres, da kun de ændrede datablokke vil blive sikkerhedskopieret, hvilket igen reducerer brugen af ​​infrastrukturressourcer som netværksbåndbredde, diskplads, I/O osv.
  • Hvis du er ude efter at have opnået en meget god RTO, er dette den funktion, du leder efter

Kommandoer til trinvis sikkerhedskopiering er stort set det samme. Eventuelle efterfølgende sikkerhedskopier efter den første sikkerhedskopiering taget med muligheden backup_method=rsync vil være inkrementelle sikkerhedskopier og barmand trækker WAL'erne ved hjælp af pg_recievexlog-værktøjet.

Fjerndatabasesikkerhedskopiering og -gendannelse

Denne evne hos Barman er efter min mening yderst gavnlig for DBA'er. Den første ting, DBA'er ville kigge efter, er at undgå at stresse produktionsdatabaseserverressourcer så meget som muligt under sikkerhedskopieringerne, og at gøre dem eksternt ville være den bedste mulighed. Barman udnytter pg_basebackup, hvilket gør det meget nemmere at scripte og automatisere det.

Generelt vil traditionelt tilgængelige muligheder for automatisk sikkerhedskopiering være -

  1. pg_basebackup
  2. tar kopi

Ovenstående to muligheder involverer en masse udvikling og test for at sikre, at en effektiv backup-strategi er på plads for at imødekomme kravene fra SLA'er og kan udgøre udfordringer for store databaser med flere tablespaces.

Med Barman er det ret simpelt. En anden enestående evne for barmand er kontinuerlig WAL-streaming. Lad os se lidt mere detaljeret på det.

Download Whitepaper Today PostgreSQL Management &Automation med ClusterControlFå flere oplysninger om, hvad du skal vide for at implementere, overvåge, administrere og skalere PostgreSQLDownload Whitepaper

Streaming backup med kontinuerlig WAL-streaming

Dette gør barman enestående i sammenligning med andre værktøjer på markedet. Live WAL-filer kan streames kontinuerligt til en ekstern backup-placering ved hjælp af Barman. Dette er FUNKTIONEN, som DBA'er ville være glade for at kende. Jeg var spændt på at vide om dette. Det er ekstremt svært eller næsten umuligt at opnå dette med manuelt byggede scripts eller med en kombination af værktøjer som pg_basebackup og pg_receivewal. Med kontinuerlig WAL-streaming kan en bedre RPO opnås. Hvis backup-strategien er designet omhyggeligt, ville det ikke være en overdrivelse at sige, at en næsten 0 RPO kan opnås.

Lad os se på trinene, kommandoer til at udføre en streaming barmand backup

#1 postgresql.conf parameterændringer

Følgende konfigurationer skal udføres i 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 Opret replikeringsplads ved hjælp af barman

Replikationsslot er vigtigt for streaming af sikkerhedskopier. I tilfælde af at kontinuerlig streaming af WAL'er mislykkes af en eller anden grund, kan alle de ikke-streamede WAL'er bevares i postgres-databasen uden at blive fjernet.

[[email protected] ~]$ barman receive-wal --create-slot pgdb
Creating physical replication slot 'barman' on server 'pgdb'
Replication slot 'barman' created

#3 Konfigurer databaseserverens konfigurationsfil for barman

Database-id for barmand er "pgdb". En konfigurationsfil kaldet pgdb.conf skal oprettes i /etc/barman.d/ placering med følgende indhold

[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 er parameteren, der skal konfigureres for, at barman udfører streaming backup
backup_method skal konfigureres til "postgres", når streaming backup skal tages
streaming_archiver skal konfigureres til "on"
slot_name=barman Denne parameter skal konfigureres, når du skal bruge barman til at bruge replikeringsslots. I dette tilfælde er replikeringspladsnavnet barman

Når konfigurationen er færdig, skal du foretage et bartendertjek for at sikre, at streaming-sikkerhedskopierne kører vellykket.

#4 Tjek om barman receive-wal kører ok

Generelt for den første barmand fungerer receive-wal ikke umiddelbart efter konfigurationsændringer, kan fejle ud, og barman check-kommandoen kan vise følgende -

[[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

Når du kører barman receive-wal, hænger den måske. For at få modtage-wal til at fungere korrekt for første gang, skal nedenstående kommando udføres.

[[email protected]  arch_logs]$ barman cron
Starting WAL archiving for server pgdb
Starting streaming archiver for server pgdb

Foretag et bartendertjek igen, det skulle være godt nu.

[[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

Hvis du kan se, viser receivexlog status ok. Dette er et af de problemer, jeg stod over for.

#5 Tjek, om barmanden er klar til at udføre sikkerhedskopier

[[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 Tjek streamingstatus ved hjælp af 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)

Ovenstående status betyder, at barmand er klar til at udføre streaming backup. Udfør sikkerhedskopieringen som vist nedenfor -

[[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

Centraliserede og katalogiserede sikkerhedskopier

Er yderst fordelagtig for miljøer, der kører flere databaser på flere servere i et netværksmiljø. Dette er en af ​​de ekstraordinære egenskaber ved Barman. Jeg har arbejdet i et realtidsmiljø, hvor jeg skulle administrere, administrere 100-vis af databaser, og jeg har altid følt behovet for centraliserede databasebackups, og det er grunden til, at Oracle RMAN blev populær til Oracle-databasesikkerhedskopieringsstrategien, og nu udfylder Barman det. plads til PostgreSQL. Med Barman kan DBA,s og DevOps ingeniører arbejde hen imod at opbygge en centraliseret backup-server, hvori Database-backups for alle databaserne vedligeholdes, valideres.

Katalogerede sikkerhedskopier betyder, at barman vedligeholder et centraliseret lager, hvor statusser for alle sikkerhedskopier opretholdes. Du kan kontrollere de tilgængelige sikkerhedskopier for en bestemt database som vist nedenfor -

[[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

Politik for sikkerhedskopiering

Opbevaringspolitikker kan defineres til database backup. Sikkerhedskopier kan gøres forældede efter en vis periode, og forældede sikkerhedskopier kan slettes fra tid til anden.

Der er muligheder i konfigurationsfilen for at sikre, at sikkerhedskopier bevares og gøres forældede, når opbevaringsperioden overskrider -

Den første parameter, der skal konfigureres, er minimum_redundans . Konfigurer altid minimum_redundancy til>0 for at sikre, at sikkerhedskopier ikke slettes ved et uheld.

Eksempel:minimum_redundans =1

  • retention_policy parameter bestemmer, hvor længe basissikkerhedskopierne skal opbevares i for at sikre, at SLA'er for gendannelse efter katastrofe overholdes.
  • wal_retention_policy parameter vil bestemme, hvor længe wal-sikkerhedskopierne skal opbevares i. Dette sikrer, at forventet RPO overholdes.

Eksisterende opbevarings- og redundanspolitikker for en databaseserver kan kontrolleres ved at bruge barman check-kommandoen som følger

[[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

Parallelle sikkerhedskopier og gendannelser kan udføres ved at bruge flere CPU'er, hvilket virkelig gør sikkerhedskopiering og gendannelse fuldført hurtigere. Denne funktion er fordelagtig for meget store databaser med størrelser op til TeraBytes.

For at udføre sikkerhedskopier parallelt skal du tilføje følgende mulighed i databaseserverens konfigurationsfil (som er /etc/barman.d/pgdb.conf fil)-

parallel_jobs = 1

Jeg kan konkludere med at sige, at barman er et værktøj af virksomhedskvalitet, som potentielt kan hjælpe DBA'er med at designe en effektiv katastrofegenopretningsstrategi.

Relaterede ressourcer ClusterControl for PostgreSQLæs mere Brug af pg_dump og pg_dumpall til at sikkerhedskopiere PostgreSQLRæs bloggen
  1. Er det muligt at henvise til en kolonne som flere fremmednøgler?

  2. Gennemtving en begrænsning med fremmednøgle til kolonner i samme tabel

  3. Bruger jeg JDBC Connection Pooling?

  4. Hvordan arbejder man med PGpoint for Geolocation ved hjælp af PostgreSQL?