Databaseback-ups spelen een cruciale rol bij het ontwerpen van een effectieve strategie voor noodherstel voor productiedatabases. Databasebeheerders en architecten moeten voortdurend werken aan het ontwerpen van een optimale en effectieve back-upstrategie voor realtime missiekritieke databases en er verder voor zorgen dat aan de SLA's voor noodherstel wordt voldaan. Volgens mijn ervaring is dit niet eenvoudig en kan het dagen tot weken duren om een onberispelijke back-upstrategie te bereiken. Het is gewoon geen goed script schrijven om databases te back-uppen en ervoor te zorgen dat het werkt. Er zijn verschillende factoren waarmee u rekening moet houden, laten we ze eens bekijken:
- Databasegrootte: Databasegrootte speelt een belangrijke rol bij het ontwerpen van back-upstrategieën. In feite is dit een van de kernfactoren die
- . definieert
- Tijd nodig voor de back-up
- De belasting van de infrastructuurcomponenten zoals schijf, netwerk, CPU enz.
- Benodigde hoeveelheid back-upopslag en de bijbehorende kosten
- Als de databases in de cloud worden gehost, zijn de kosten voor back-upopslag afhankelijk van de benodigde hoeveelheid opslagruimte
- De grootte van de database heeft ook invloed op de RTO
- Infrastructuur: De back-upstrategie is sterk afhankelijk van de infrastructuur van de databases. De back-upprocedure zou anders zijn voor databases die worden gehost op een fysieke server in een on-premises datacenter dan voor databases die in de cloud worden gehost.
- Back-uplocatie: Waar gaan de back-ups naartoe? Over het algemeen worden de back-ups op een externe locatie geplaatst, bijvoorbeeld op tape of cloud-specifieke opslag zoals AWS S3.
- Back-uptool: Identificeer een optimaal hulpmiddel om online databaseback-ups uit te voeren die er mogelijk voor kunnen zorgen dat er een consistente back-up is gemaakt.
Een goede databaseback-upstrategie moet ervoor zorgen dat aan RTO (Recovery Time Objective) en RPO (Recovery Point Objective) wordt voldaan, wat op zijn beurt helpt om de Disaster Recovery-doelstelling te bereiken. Back-ups op bestandssysteemniveau kunnen op verschillende manieren worden uitgevoerd op PostgreSQL-databases. In deze blog zal mijn focus liggen op een tool genaamd Barman die in de volksmond wordt gebruikt om PostgreSQL-databaseback-ups uit te voeren.
Barman (back-up- en herstelmanager) is een op Python gebaseerde open-sourcetool ontwikkeld door ontwikkelaars van 2nd Quadrant. Deze tool is ontwikkeld om een databaseback-upstrategie op ondernemingsniveau te realiseren voor missiekritieke PostgreSQL-productiedatabases. De kenmerken en kenmerken lijken op die van Oracle's RMAN. Naar mijn mening is barman een van de beste opties voor PostgreSQL-databases en kan het verschillende voordelen bieden vanuit het operationele perspectief voor DBA's en infrastructuuringenieurs.
Laten we eens kijken naar enkele mogelijkheden van Barman:
Ik zal beginnen met het configuratieoverzicht en dan een lijst maken van wat voor soort back-ups kunnen worden uitgevoerd
Technisch gezien is barman-cli een op python gebaseerd hulpmiddel en heeft het twee verschillende configuratiebestanden om mee om te gaan. Eén bestand dat de feitelijke configuratie is voor de database waarvan een back-up moet worden gemaakt, bevindt zich in "/etc/barman.d"-namen als
Voorbeeld inhoud van /etc/barman.conf bestand wordt hieronder getoond
[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 compressedInstallatie van Barman
Laten we eens kijken naar de installatieprocedure van barman -
Installeren vanaf de bron
Download de barman van https://www.pgbarman.org/
Untar / unzip het installatieprogramma en voer de volgende opdracht uit als rootgebruiker -
[[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-infoInstalleren vanuit de repo
Installatie kan ook als volgt via yum worden gedaan
[[email protected]~]$ yum install barmanLaten we eens kijken naar de verschillende soorten back-ups die barman ondersteunt
Fysieke hot-back-ups
Barman ondersteunt Physical Hot Backups, wat betekent:online back-up van fysieke gegevensbestanden en transactielogbestanden van de database met behulp van rsync-methodologie die ook in gecomprimeerde vorm kan zijn.
Laten we eens kijken naar de stappen en opdrachten om RSYNC-back-up uit te voeren met barman
#1 PostgreSQL-databaseconfiguratiebestand voor barman
[pgdb]
description="Main PostgreSQL server"
conninfo=host=pgserver user=postgres dbname=postgres
ssh_command=ssh [email protected]
archiver=on
backup_method = rsync
“pgdb” is de identifier van de Postgres Database voor barman en de naam van het configuratiebestand moet
De parameter backup_method definieert het type backup dat moet worden genomen. In dit geval is backup_method rsync.
Opmerking:om de barman-back-upopdracht te laten slagen, moet ssh-authenticatie zonder wachtwoord worden geconfigureerd tussen barman- en postgres-servers.
#2 postgresql.conf bestandsparameters
wal_level=replica
archive_mode=on
archive_command=’rsync to <ARCHIVE LOCATION>’Barman's back-upopdracht
#3 Controleer of barman klaar is om back-ups uit te voeren
[[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: OKDe bovenstaande uitvoer zegt dat alles "OK" is om door te gaan met de back-up, wat betekent dat u een back-up kunt maken.
In de onderstaande output staat bijvoorbeeld dat er geen back-up kan worden gemaakt omdat volgens barman SSH niet werkt -
[[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 Databaseback-up uitvoeren
[[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.backupOm te begrijpen of het back-upcommando van de barman zelfs succesvol zal zijn, helpt het onderstaande commando -
Incrementele back-ups
Een andere geweldige mogelijkheid van Barman is de mogelijkheid om incrementele back-ups te maken. Dit betekent dat alleen de gewijzigde blokken sinds de laatste volledige databaseback-up kunnen worden geback-upt. Voor databases die minder gegevenswijzigingen ondergaan, kan het incrementeel back-uppen ervan het gebruik van hulpbronnen verminderen.
Het is sterk afhankelijk van rsync en hard-links. Hieronder staan de voordelen van incrementele back-ups –
- Verkort de dagelijkse back-uptijd aanzienlijk
- De hoeveelheid gegevens waarvan een back-up wordt gemaakt, neemt af omdat er alleen een back-up wordt gemaakt van de gewijzigde gegevensblokken, wat op zijn beurt het gebruik van infrastructuurbronnen zoals netwerkbandbreedte, schijfruimte, I/O enz. vermindert.
- Als u op zoek bent naar een zeer goede RTO, is dit de functie waarnaar u op zoek bent
Opdrachten voor incrementele back-up zijn vrijwel hetzelfde. Alle volgende back-ups na de eerste back-up gemaakt met optie backup_method=rsync zullen incrementele back-ups zijn en barman haalt de WAL's op met behulp van het hulpprogramma pg_recievexlog.
Remote databaseback-ups en herstel
Deze mogelijkheid van Barman is naar mijn mening zeer gunstig voor DBA's. Het eerste waar DBA's naar op zoek zijn, is om tijdens de back-ups de productiedatabaseserverbronnen niet zo veel mogelijk te belasten en ze op afstand te doen zou de beste optie zijn. Barman maakt gebruik van pg_basebackup, wat het een stuk eenvoudiger maakt om het script te schrijven en te automatiseren.
Over het algemeen zijn de traditioneel beschikbare opties voor automatische back-ups -
- pg_basebackup
- tar-kopie
De bovenstaande twee opties brengen veel ontwikkeling en testen met zich mee om ervoor te zorgen dat er een effectieve back-upstrategie is om aan de eisen van SLA's te voldoen en kan uitdagingen opleveren voor grote databases met meerdere tablespaces.
Met Barman is het vrij eenvoudig. Een ander uitzonderlijk vermogen van barman is continue WAL-streaming. Laten we daar wat meer in detail naar kijken.
Download de whitepaper vandaag PostgreSQL-beheer en -automatisering met ClusterControlLees wat u moet weten om PostgreSQL te implementeren, bewaken, beheren en schalenDownload de whitepaperStreaming Back-up met continue WAL-streaming
Dit maakt barman opvallend in vergelijking met andere tools op de markt. Live WAL-bestanden kunnen continu worden gestreamd naar een externe back-uplocatie met Barman. Dit is DE FUNCTIE die DBA's graag zouden willen weten. Ik was opgewonden om dit te weten. Het is extreem moeilijk of bijna onmogelijk om dit te bereiken met handmatig gebouwde scripts of met een combinatie van tools zoals pg_basebackup en pg_receivewal. Met continue WAL-streaming kan een betere RPO worden bereikt. Als de back-upstrategie zorgvuldig is ontworpen, zou het niet overdreven zijn om te zeggen dat een RPO van bijna 0 kan worden bereikt.
Laten we eens kijken naar de stappen, opdrachten om een streaming barman-back-up uit te voeren
#1 postgresql.conf parameterwijzigingen
Volgende configuraties die moeten worden gedaan in de 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 Maak een replicatieslot met barman
De replicatiesleuf is belangrijk voor het streamen van back-ups. In het geval dat het continu streamen van WAL's om welke reden dan ook mislukt, kunnen alle niet-gestreamde WAL's worden bewaard in de postgres-database zonder te worden verwijderd.
[[email protected] ~]$ barman receive-wal --create-slot pgdb
Creating physical replication slot 'barman' on server 'pgdb'
Replication slot 'barman' created#3 Configureer het databaseserverconfiguratiebestand voor barman
Database-ID voor barman is "pgdb". Er moet een configuratiebestand met de naam pgdb.conf worden gemaakt op de locatie /etc/barman.d/ met de volgende inhoud
[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 is de parameter die moet worden geconfigureerd voor barman om streaming-back-ups uit te voeren
backup_method moet worden geconfigureerd op "postgres" wanneer streaming-back-up moet worden gemaakt
streaming_archiver moet worden geconfigureerd om "aan" te zijn
slot_name=barman Deze parameter moet worden geconfigureerd wanneer u barman nodig hebt om replicatieslots te gebruiken. In dit geval is de naam van de replicatiesleuf barman
Nadat de configuratie is voltooid, voert u een barmancontrole uit om ervoor te zorgen dat de streaming-back-ups succesvol worden uitgevoerd.
#4 Controleer of de ontvangst-wal van de barman goed werkt
In het algemeen werkt de eerste barman-ontvangst-wal niet onmiddellijk na configuratiewijzigingen, kan er een fout optreden en kan de barman check-opdracht het volgende laten zien -
[[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: OKWanneer u barman ontvangst-wal uitvoert, kan het blijven hangen. Om de ontvangst-wal voor de eerste keer correct te laten werken, moet het onderstaande commando worden uitgevoerd.
[[email protected] arch_logs]$ barman cron
Starting WAL archiving for server pgdb
Starting streaming archiver for server pgdbDoe nu nog een keer een barmancontrole, het zou nu goed moeten zijn.
[[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: OKAls je kunt zien, wordt de status van Receivexlog ok weergegeven. Dit is een van de problemen waarmee ik werd geconfronteerd.
#5 Controleer of de barman klaar is om back-ups te maken
[[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 Controleer de streamingstatus met 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)De bovenstaande status betekent dat de barman klaar is om een streamingback-up uit te voeren. Voer de back-up uit zoals hieronder weergegeven -
[[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
000000010000000000000020Gecentraliseerde en gecatalogiseerde back-ups
Is zeer gunstig voor omgevingen met meerdere databases op meerdere servers in een netwerkomgeving. Dit is een van de uitzonderlijke kenmerken van Barman. Ik heb in een realtime omgeving gewerkt waar ik honderden databases moest beheren, beheren en ik altijd de behoefte had aan gecentraliseerde databaseback-ups en daarom werd Oracle RMAN populair voor de Oracle-databaseback-upstrategie en nu vult Barman die ruimte voor PostgreSQL. Met Barman, DBA's en DevOps kunnen technici werken aan het bouwen van een gecentraliseerde back-upserver waar databaseback-ups voor alle databases worden onderhouden en gevalideerd.
Gecatalogiseerde back-ups, wat betekent dat barman een gecentraliseerde repository onderhoudt waarin de statussen van alle back-ups worden bijgehouden. U kunt de beschikbare back-ups voor een bepaalde database controleren, zoals hieronder weergegeven -
[[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 KiBBeleid voor het bewaren van back-ups
Bewaarbeleid kan worden gedefinieerd voor databaseback-ups. Back-ups kunnen na een bepaalde periode verouderd raken en verouderde back-ups kunnen van tijd tot tijd worden verwijderd.
Er zijn opties in het configuratiebestand om ervoor te zorgen dat back-ups worden bewaard en overbodig worden gemaakt wanneer de bewaarperiode langer is dan -
De eerste parameter die moet worden geconfigureerd is minimum_redundancy . Configureer minimum_redundantie altijd op> 0 om ervoor te zorgen dat back-ups niet per ongeluk worden verwijderd.
Voorbeeld:minimum_redundancy =1
- retention_policy parameter bepaalt hoe lang de basisback-ups moeten worden bewaard om ervoor te zorgen dat aan de SLA's voor noodherstel wordt voldaan.
- wal_retention_policy parameter bepaalt hoe lang de wal-back-ups moeten worden bewaard. Dit zorgt ervoor dat aan de verwachte RPO wordt voldaan.
Bestaand bewaar- en redundantiebeleid voor een databaseserver kan als volgt worden gecontroleerd met de opdracht barman check
[[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: OKParallelle back-ups en herstel kan worden uitgevoerd door meerdere CPU's te gebruiken, waardoor back-ups en herstel sneller worden voltooid. Deze functie is handig voor zeer grote databases tot TeraBytes.
Om back-ups parallel uit te voeren, voegt u de volgende optie toe aan het configuratiebestand van de databaseserver (dit is het bestand /etc/barman.d/pgdb.conf)-
parallel_jobs = 1Ik kan besluiten met te zeggen dat barman een tool van ondernemingskwaliteit is die DBA's mogelijk kan helpen bij het ontwerpen van een effectieve strategie voor noodherstel.
Gerelateerde bronnen ClusterControl voor PostgreSQLMeer informatie Pg_dump en pg_dumpall gebruiken om PostgreSQL te back-uppen