Verwenden von Barman zum Sichern von PostgreSQL – Ein Überblick

Datenbank-Backups spielen eine entscheidende Rolle bei der Entwicklung einer effektiven Disaster-Recovery-Strategie für Produktionsdatenbanken. Datenbankadministratoren und -architekten müssen kontinuierlich daran arbeiten, eine optimale und effektive Backup-Strategie für unternehmenskritische Echtzeitdatenbanken zu entwickeln und weiterhin sicherzustellen, dass Disaster Recovery-SLAs eingehalten werden. Meiner Erfahrung nach ist dies nicht einfach und kann Tage bis Wochen dauern, um eine einwandfreie Backup-Strategie zu erreichen. Es geht einfach nicht darum, ein gutes Skript zu schreiben, um Datenbanken zu sichern und sicherzustellen, dass es funktioniert. Es gibt mehrere Faktoren zu berücksichtigen, werfen wir einen Blick auf sie:

• Datenbankgröße: Die Datenbankgröße spielt beim Entwerfen von Backup-Strategien eine wichtige Rolle. Tatsächlich ist dies einer der Kernfaktoren, die
  definieren
  • Vom Backup benötigte Zeit
  • Die Belastung der Infrastrukturkomponenten wie Festplatte, Netzwerk, CPU usw.
  • Erforderlicher Sicherungsspeicher und die damit verbundenen Kosten
  • Wenn die Datenbanken in der Cloud gehostet werden, hängen die Kosten für den Backup-Speicher von der erforderlichen Speichermenge ab
  • Außerdem wirkt sich die Datenbankgröße auf die RTO aus
• Infrastruktur: Die Sicherungsstrategie hängt stark von der Infrastruktur der Datenbanken ab. Das Sicherungsverfahren wäre für Datenbanken, die auf einem physischen Server in einem lokalen Rechenzentrum gehostet werden, anders als für Datenbanken, die in der Cloud gehostet werden.
• Backup-Speicherort: Wohin gehen die Backups? Im Allgemeinen werden die Sicherungen an einem entfernten Ort abgelegt, beispielsweise auf Band oder einem Cloud-spezifischen Speicher wie AWS S3.
• Backup-Tool: Identifizieren Sie ein optimales Tool zum Durchführen einer Online-Datenbanksicherung, das möglicherweise sicherstellt, dass eine konsistente Sicherung durchgeführt wurde.

Eine gute Datenbank-Backup-Strategie muss sicherstellen, dass RTO (Recovery Time Objective) und RPO (Recovery Point Objective) eingehalten werden, was wiederum dazu beiträgt, das Disaster Recovery-Ziel zu erreichen. Sicherungen auf Dateisystemebene können auf PostgreSQL-Datenbanken auf verschiedene Arten durchgeführt werden. In diesem Blog werde ich mich auf ein Tool namens Barman konzentrieren, das allgemein verwendet wird, um PostgreSQL-Datenbanksicherungen durchzuführen.

Barman (Backup and Recovery Manager) ist ein Python-basiertes Open-Source-Tool, das von Entwicklern im 2nd Quadrant entwickelt wurde. Dieses Tool wurde entwickelt, um eine Datenbank-Backup-Strategie der Enterprise-Klasse für geschäftskritische PostgreSQL-Produktionsdatenbanken zu erreichen. Seine Funktionen und Merkmale ähneln denen von Oracles RMAN. Meiner Meinung nach ist Barman eine der besten Optionen für PostgreSQL-Datenbanken und kann DBAs und Infrastrukturingenieuren aus der Betriebsperspektive mehrere Vorteile bieten.

Sehen wir uns einige Fähigkeiten von Barman an:

Ich beginne mit der Konfigurationsübersicht und liste dann auf, welche Art von Backups durchgeführt werden können

Technisch gesehen ist barman-cli ein Python-basiertes Tool und muss mit zwei verschiedenen Konfigurationsdateien umgehen. Eine Datei, die die eigentliche Konfiguration für die zu sichernde Datenbank darstellt, befindet sich in „/etc/barman.d“ und heißt .conf, und die andere Datei enthält die barkeeperbezogenen Parameter (wie z barman-Backup-Speicherort, barman-Server, Protokolldateien usw.), die konfiguriert sind, befindet sich in „/etc“ (/etc/barman.conf). Die Barmann-Konfigurationsdateien haben eine MySQL-Typ-Parameterkonfiguration.

Beispielinhalt der Datei /etc/barman.conf ist unten gezeigt

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

Werfen wir einen Blick auf die Installationsprozedur von barman -

Installieren von der Quelle

Laden Sie den Barmann von https://www.pgbarman.org/

Entpacken / entpacken Sie das Installationsprogramm und führen Sie den folgenden Befehl als Root-Benutzer aus -

[[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 aus dem Repo

Die Installation kann auch wie folgt über yum erfolgen

[[email protected]~]$ yum install barman

Werfen wir einen Blick auf die verschiedenen Arten von Backups, die Barkeeper unterstützen

Physische Hot-Backups

Barman unterstützt physische Hot-Backups, d. h. Online-Backups von physischen Datendateien und Transaktionsprotokolldateien der Datenbank unter Verwendung der rsync-Methodik, die auch in komprimierter Form vorliegen können.

Werfen wir einen Blick auf die Schritte und Befehle zum Durchführen einer RSYNC-Sicherung mit barman

#1 PostgreSQL-Datenbankkonfigurationsdatei für Barkeeper

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

„pgdb“ ist die Kennung der Postgres-Datenbank für barman und der Name der Konfigurationsdatei sollte .conf lauten, die sich in /etc/barman.d/ befindet. Wenn der Befehl barman backup ausgeführt wird, sucht barman nach dem Abschnitt [pgdb] in der Datei pgdb.conf.

Der Parameter backup_method definiert die Art der durchzuführenden Sicherung. In diesem Fall ist backup_method rsync.

Hinweis:Damit der Barman-Backup-Befehl erfolgreich ist, muss die passwortlose SSH-Authentifizierung zwischen Barman- und Postgres-Servern konfiguriert werden.

#2 postgresql.conf-Dateiparameter

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

Backup-Befehl des Barkeepers

#3 Überprüfen Sie, ob der Barkeeper bereit ist, Backups durchzuführen

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

Die obige Ausgabe sagt, dass alles „OK“ ist, um mit der Sicherung fortzufahren, was bedeutet, dass Sie eine Sicherung erstellen können.

Die folgende Ausgabe besagt beispielsweise, dass keine Sicherung durchgeführt werden kann, da laut Barmann SSH nicht funktioniert -

[[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 Datenbanksicherung durchführen

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

Um zu verstehen, ob der Barman-Backup-Befehl überhaupt erfolgreich sein wird, hilft der folgende Befehl -

Inkrementelle Backups

Eine weitere großartige Funktion von Barman ist die Möglichkeit, inkrementelle Backups zu erstellen. Das bedeutet, dass nur die geänderten Blöcke seit der letzten vollständigen Datenbanksicherung gesichert werden können. Bei Datenbanken, die weniger Datenänderungen unterliegen, kann eine inkrementelle Sicherung die Ressourcennutzung reduzieren.

Es hängt stark von rsync und Hardlinks ab. Unten sind die Vorteile von inkrementellen Sicherungen aufgeführt –

• Reduziert die tägliche Sicherungszeit erheblich
• Das zu sichernde Datenvolumen reduziert sich, da nur die geänderten Datenblöcke gesichert werden, was wiederum die Nutzung von Infrastrukturressourcen wie Netzwerkbandbreite, Speicherplatz, E/A usw. reduziert.
• Wenn Sie eine sehr gute RTO erreichen möchten, ist dies die Funktion, nach der Sie suchen würden

Die Befehle für die inkrementelle Sicherung sind ziemlich gleich. Alle nachfolgenden Sicherungen nach der ersten Sicherung, die mit der Option backup_method=rsync erstellt wurde werden inkrementelle Sicherungen sein und der Barmann zieht die WALs mit dem Dienstprogramm pg_recievexlog.

Remote-Datenbanksicherungen und -wiederherstellung

Diese Fähigkeit von Barman ist meiner Meinung nach sehr vorteilhaft für DBAs. Das Erste, worauf DBAs achten würden, ist, die Ressourcen des Produktionsdatenbankservers während der Sicherungen so weit wie möglich zu vermeiden, und dies per Fernzugriff durchzuführen, wäre die beste Option. Barman nutzt pg_basebackup, was die Skripterstellung und Automatisierung erheblich vereinfacht.

Im Allgemeinen sind traditionell verfügbare Optionen für automatische Sicherungen -

1. pg_basebackup
2. tar-Kopie

Die beiden oben genannten Optionen erfordern viel Entwicklungs- und Testaufwand, um sicherzustellen, dass eine effektive Backup-Strategie vorhanden ist, um die Anforderungen von SLAs zu erfüllen, und können große Datenbanken mit mehreren Tablespaces vor Herausforderungen stellen.

Mit Barman ist es ziemlich einfach. Eine weitere außergewöhnliche Fähigkeit des Barkeepers ist das kontinuierliche WAL-Streaming. Sehen wir uns das etwas genauer an.

Streaming-Backup mit kontinuierlichem WAL-Streaming

Dadurch hebt sich Barman von anderen Werkzeugen auf dem Markt ab. Live-WAL-Dateien können mit Barman kontinuierlich an einen Remote-Backup-Speicherort gestreamt werden. Dies ist DIE FUNKTION, über die sich DBAs freuen würden. Ich war aufgeregt, davon zu erfahren. Es ist extrem schwierig oder fast unmöglich, dies mit manuell erstellten Skripten oder mit einer Kombination von Tools wie pg_basebackup und pg_receivewal zu erreichen. Mit kontinuierlichem WAL-Streaming kann ein besseres RPO erreicht werden. Wenn die Sicherungsstrategie sorgfältig entworfen wird, wäre es nicht übertrieben zu sagen, dass ein RPO von fast 0 erreicht werden kann.

Sehen wir uns die Schritte und Befehle an, um eine Streaming-Barkeeper-Sicherung durchzuführen

#1 postgresql.conf Parameteränderungen

Folgende Konfigurationen müssen in der 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 Replikationsslot mit Barmann erstellen

Der Replikationsslot ist wichtig für Streaming-Backups. Falls das kontinuierliche Streaming von WALs aus irgendeinem Grund fehlschlägt, können alle nicht gestreamten WALs in der Postgres-Datenbank beibehalten werden, ohne entfernt zu werden.

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

#3 Konfigurieren Sie die Konfigurationsdatei des Datenbankservers für den Barmann

Die Datenbankkennung für den Barmann ist „pgdb“. Eine Konfigurationsdatei namens pgdb.conf muss im Verzeichnis /etc/barman.d/ mit folgendem Inhalt erstellt werden

[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 ist der Parameter, der für den Barkeeper konfiguriert werden muss, um Streaming-Sicherungen durchzuführen
backup_method muss auf „postgres“ konfiguriert werden, wenn eine Streaming-Sicherung erstellt werden soll
streaming_archiver muss auf „on“ konfiguriert werden
slot_name=barman Dieser Parameter muss konfiguriert werden, wenn der Barmann Replikationsslots verwenden soll. In diesem Fall lautet der Name des Replikations-Slots Barmann

Sobald die Konfiguration abgeschlossen ist, führen Sie einen Barmann-Check durch, um sicherzustellen, dass Streaming-Backups erfolgreich ausgeführt werden.

#4 Überprüfen Sie, ob die Rezeption des Barmanns in Ordnung ist

Im Allgemeinen funktioniert der erste Barkeeper-Receive-Wal nicht sofort nach Konfigurationsänderungen, möglicherweise tritt ein Fehler auf, und der Barman-Check-Befehl zeigt möglicherweise das folgende -

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

Wenn Sie Barman Receive-Wal ausführen, hängt es möglicherweise. Damit das Receive-Wal zum ersten Mal richtig funktioniert, muss der folgende Befehl ausgeführt werden.

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

Machen Sie jetzt noch einmal einen Barmann-Check, es sollte jetzt gut sein.

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

Wenn Sie sehen können, zeigt der Receivexlog-Status ok an. Dies ist eines der Probleme, mit denen ich konfrontiert war.

#5 Überprüfen Sie, ob der Barkeeper bereit ist, Backups durchzuführen

[[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 Überprüfen Sie den Streaming-Status mit dem Barkeeper

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

Der obige Status bedeutet, dass der Barkeeper bereit ist, eine Streaming-Sicherung durchzuführen. Führen Sie die Sicherung wie unten gezeigt durch -

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

Zentralisierte und katalogisierte Backups

Ist sehr vorteilhaft für Umgebungen, in denen mehrere Datenbanken auf mehreren Servern in einer Netzwerkumgebung ausgeführt werden. Dies ist eines der außergewöhnlichen Merkmale von Barman. Ich habe in Echtzeitumgebungen gearbeitet, in denen ich Hunderte von Datenbanken verwalten und administrieren musste, und ich hatte immer das Bedürfnis nach zentralisierten Datenbanksicherungen. Aus diesem Grund wurde Oracle RMAN für die Oracle-Datenbanksicherungsstrategie populär, und jetzt füllt Barman diese aus Platz für PostgreSQL. Mit Barman können DBAs und DevOps-Ingenieure auf den Aufbau eines zentralisierten Backup-Servers hinarbeiten, in dem Datenbank-Backups für alle Datenbanken verwaltet und validiert werden.

Katalogisierte Sicherungen bedeutet, dass der Barmann ein zentrales Repository verwaltet, in dem der Status aller Sicherungen verwaltet wird. Sie können die verfügbaren Sicherungen für bestimmte Datenbanken wie unten gezeigt überprüfen -

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

Aufbewahrungsrichtlinie für Backups

Aufbewahrungsrichtlinien können für Datenbanksicherungen definiert werden. Backups können nach einem bestimmten Zeitraum veraltet sein und veraltete Backups können von Zeit zu Zeit gelöscht werden.

Es gibt Optionen in der Konfigurationsdatei, um sicherzustellen, dass Sicherungen aufbewahrt und obsolet gemacht werden, wenn die Aufbewahrungsfrist -

Der erste zu konfigurierende Parameter ist minimum_redundancy . Konfigurieren Sie minimum_redundancy immer auf>0, um sicherzustellen, dass Sicherungen nicht versehentlich gelöscht werden.

Beispiel:minimum_redundancy =1

• retention_policy Der Parameter bestimmt, wie lange die Basissicherungen aufbewahrt werden müssen, um sicherzustellen, dass die Notfallwiederherstellungs-SLAs eingehalten werden.
• wal_retention_policy Der Parameter bestimmt, wie lange die Wal-Sicherungen aufbewahrt werden müssen. Dadurch wird sichergestellt, dass das erwartete RPO eingehalten wird.

Vorhandene Aufbewahrungs- und Redundanzrichtlinien für einen Datenbankserver können mit dem Befehl barman check wie folgt überprüft werden

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

Parallele Sicherungen und Wiederherstellungen kann durch die Verwendung mehrerer CPUs durchgeführt werden, wodurch Sicherungen und Wiederherstellungen wirklich schneller abgeschlossen werden. Diese Funktion ist für sehr große Datenbanken mit einer Größe von bis zu TeraBytes von Vorteil.

Um Sicherungen parallel auszuführen, fügen Sie die folgende Option in der Konfigurationsdatei des Datenbankservers (die Datei /etc/barman.d/pgdb.conf) hinzu-

parallel_jobs = 1

Abschließend kann ich sagen, dass barman ein unternehmenstaugliches Tool ist, das Datenbankadministratoren möglicherweise dabei helfen kann, eine effektive Notfallwiederherstellungsstrategie zu entwickeln.