PostgreSQL
 sql >> Datenbank >  >> RDS >> PostgreSQL

Top-Backup-Tools für PostgreSQL

PostgreSQL hat von Anfang an den Ruf, felsenfest zu sein, und hat im Laufe der Jahre eine Reihe beeindruckender Funktionen angesammelt. Allerdings kann die Gewissheit, dass Ihre Daten auf der Festplatte ACID-konform sind – wenn sie nicht durch eine gleichwertige, gut durchdachte Backup-Strategie ergänzt wird – leicht zerstört werden.

Sicherungstypen

Bevor wir uns mit den verfügbaren Tools befassen, sehen wir uns die verfügbaren PostgreSQL-Sicherungstypen und ihre Eigenschaften an:

SQL-Dumps (oder logisch)

  • Blockiert weder Leser noch Schreiber.
  • Ausgerichtet auf kleine Datensätze aufgrund der negativen Auswirkungen auf die Systemlast und der langen Zeit, die sowohl für Sicherungs- als auch für Wiederherstellungsvorgänge erforderlich ist. Die Leistung kann mit dem Flag –no-sync erhöht werden, aber lesen Sie die Manpage für die Risiken, die mit dem Deaktivieren des Wartens auf Schreibvorgänge verbunden sind.
  • Eine ANALYSE nach der Wiederherstellung ist erforderlich, um die Statistiken zu optimieren.
  • Globale Objekte wie Rollen und Tablespaces können nur mit dem Dienstprogramm pg_dumpall gesichert werden. Beachten Sie, dass Tablespace-Verzeichnisse manuell erstellt werden müssen, bevor die Wiederherstellung gestartet wird.
  • Unterstützt Parallelität auf Kosten einer erhöhten Systemlast. Lesen Sie man pg_dump für seine Einschränkungen und speziellen Anforderungen, z. synchronisierte Schnappschüsse.
  • Dumps können in neuere Versionen von PostgreSQL oder sogar in eine andere Maschinenarchitektur geladen werden, es ist jedoch nicht garantiert, dass sie zwischen den Hauptversionen abwärtskompatibel sind, sodass möglicherweise eine manuelle Bearbeitung der Dump-Datei erforderlich ist.

Dateisystem (oder physikalisch)

  • Erfordert das Herunterfahren der Datenbank.
  • Schneller als logische Backups.
  • Enthält Clusterdaten.
  • Kann nur auf derselben Hauptversion von PostgreSQL wiederhergestellt werden.

Kontinuierliche Archivierung (oder Point-In-Time-Recovery oder PITR)

  • Geeignet für sehr große Datenbanken, bei denen logische oder physische Sicherungen zu lange dauern würden.
  • Einige Verzeichnisse innerhalb des Datenverzeichnisses können ausgeschlossen werden, um den Vorgang zu beschleunigen.

Schnappschüsse

  • Benötigt Betriebssystem-Unterstützung — zum Beispiel funktioniert LVM ziemlich gut, was auch durch NetBackup for PostgreSQL Agent bestätigt wird.
  • Geeignet für Anwendungen, bei denen sowohl das Datenverzeichnis als auch die Datenbank synchron sein müssen, z. LAMP-Anwendungen, sofern die beiden Snapshots synchronisiert sind.
  • Nicht empfohlen, wenn die Datenbankdateien auf mehreren Dateisystemen gespeichert sind (muss alle Dateisysteme gleichzeitig aufnehmen).

Wolke

Alle Cloud-Anbieter implementieren Backups in ihr PostgreSQL-Angebot. Logische Backups können wie gewohnt durchgeführt werden, während physische Backups und PITR über die Cloud-Service-Angebote verfügbar sind, da der Zugriff auf den Datenspeicher nicht verfügbar ist (siehe zum Beispiel Amazon Aurora für PostgreSQL). Daher muss das Sichern von PostgreSQL in der Cloud ein Thema für einen anderen Blog sein.

Agentenbasis

  • Erfordert einen Agenten, der auf Zielen installiert ist.
  • Kann Sicherungen auf Blockebene durchführen, z. COMMVAULT (Installation wird nur unter Windows unterstützt).

Funktionen

Während PostgreSQL standardmäßig die Tools bereitstellt, die zum Durchführen von logischen, physischen und PITR-Backups erforderlich sind, verlassen sich spezialisierte Backup-Anwendungen auf die nativen PostgreSQL- und Betriebssystem-Tools, um die Notwendigkeit der Implementierung einer Backup-Strategie zu erfüllen, die die folgenden Punkte anspricht:

  • Automatisierung
  • Häufigkeit
  • Aufbewahrungsfrist
  • Integrität
  • Benutzerfreundlichkeit

Darüber hinaus versuchen PostgreSQL-Backup-Tools, Funktionen bereitzustellen, die generischen Backup-Tools gemeinsam sind, wie zum Beispiel:

  • inkrementelle Backups zum Sparen von Speicherplatz
  • Backup-Kataloge
  • Möglichkeit, Sicherungen vor Ort oder in der Cloud zu speichern
  • Warnung und Benachrichtigung
  • umfassende Berichterstattung
  • Zugriffskontrolle
  • Verschlüsselung
  • grafische Benutzeroberfläche und Dashboards
  • Backups von Remote-Hosts
  • adaptiver Durchsatz zur Minimierung der Belastung der Targets
  • Mehrere Hosts parallel handhaben
  • Backup-Orchestrierung z.B. Jobverkettung
  • REST-APIs

Lab-Setup

Für diese Übung habe ich einen Command-and-Control-Host eingerichtet, auf dem ich die Backup-Tools installiere und der auch zwei PostgreSQL-Instanzen – 9.6 und 10 – ausführt, die aus PGDG-Repositories installiert wurden:

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

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

Ich habe auch zwei entfernte PostgreSQL-Instanzen eingerichtet, auf denen die gleichen Versionen 9.6 bzw. 10 ausgeführt werden:

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

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


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

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

Verwenden Sie als Nächstes pgbench, um einen Datensatz zu erstellen:

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

Werkzeuge

Eine Liste gängiger Backup-Tools finden Sie im Abschnitt „Backup“ des PostgreSQL-Wikis. Ich habe die Liste mit Produkten ergänzt, auf die ich im Laufe der Jahre und bei einer kürzlichen Internetsuche gestoßen bin.

Amanda

Amanda ist agentenbasiert, Open Source und unterstützt PostgreSQL standardmäßig über die amggsql-API. Zum jetzigen Zeitpunkt unterstützt die Version 3.5.1 keine Tablespaces (siehe man amggsql).

Zmanda bietet eine Unternehmensversion an, die ebenfalls Open Source ist, jedoch nicht direkt als Testversion zum Download zur Verfügung steht.

Amanda benötigt einen dedizierten Backup-Host, da die Server- und Client-Pakete sich gegenseitig ausschließen:

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

Befolgen Sie die Anleitung zur grundlegenden Konfiguration, um den Server und den Client einzurichten, und konfigurieren Sie dann die PostgreSQL-API.

Hier ist ein Git-Diff aus meinem Labor:

  • Server:

    • Erhöhen Sie den Backup-Speicherplatz des Servers:

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

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

      • Definieren Sie das PostgreSQL-Ziel (und deaktivieren Sie die Beispielsicherung):

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

  • Kunde:

    • Konfiguration:

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

      • Authentifizierungsdatei:

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

    • Autorisieren Sie den Server:

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

    • PostgreSQL-Authentifizierung:

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

    • PostgreSQL-Konfiguration:

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

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

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

Führen Sie nach Abschluss der obigen Konfiguration die Sicherung aus:

[[email protected] ~]$ amdump omiday

Und überprüfen Sie:

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

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


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

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


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


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


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

(brought to you by Amanda version 3.5.1)

Die Wiederherstellung aus einer Sicherung umfasst weitere manuelle Schritte, wie im Abschnitt „Wiederherstellung“ erläutert.

Laut Amanda Enterprise FAQ würde die folgende Verbesserung für unser PostgreSQL-Beispiel gelten:

  • Verwaltungskonsole zur Automatisierung von Sicherungen, Aufbewahrungsrichtlinien und Zeitplänen
  • Sicherung im Amazon S3-Cloud-Speicher

Barmann

Barman ist eine Notfallwiederherstellungslösung für PostgreSQL, die von 2ndQuadrant verwaltet wird. Es wurde entwickelt, um Sicherungen für mehrere Datenbanken zu verwalten, und kann mithilfe der PITR-Funktion von PostgreSQL einen früheren Zeitpunkt wiederherstellen.

Die Funktionen des Barkeepers auf einen Blick:

  • verarbeitet mehrere Ziele
  • Unterstützung für verschiedene PostgreSQL-Versionen
  • kein Datenverlust
  • Streaming und/oder Standardarchivierung von WALs
  • lokale oder entfernte Wiederherstellung
  • vereinfachte Point-in-Time-Wiederherstellung

Wie im Barman-Handbuch erwähnt, ist die Unterstützung für inkrementelle Sicherungen, parallele Jobs, Datendeduplizierung und Netzwerkkomprimierung nur verfügbar, wenn die Option rsync verwendet wird. Außerdem wird das Streamen von WALs von einem Standby mithilfe des archive_command derzeit nicht unterstützt.

Nachdem wir die Anweisungen im Handbuch zum Einrichten der Umgebung befolgt haben, können wir Folgendes überprüfen:

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

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

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

Alles ist in Ordnung, also können wir testen, indem wir die beiden Hosts sichern:

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

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

Listen Sie den Backup-Katalog auf:

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

Anzeigen des Inhalts für ein bestimmtes Backup:

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

Wenn Barman für synchrones WAL-Streaming konfiguriert wurde, können wir den Replikationsstatus überprüfen:

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

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

Weitere Verbesserungen können mit den bereitgestellten Hook-Skripten hinzugefügt werden.

Schließlich kommt Barman für Befehlszeilenliebhaber mit vollständiger TAB-Vervollständigung.

EDB-Sicherungs- und Wiederherstellungstool (BART)

EDB BART ist eine proprietäre Closed-Source-Anwendung, die von EnterpriseDB bereitgestellt wird. Es kombiniert das native PostgreSQL-Backup auf Dateisystemebene und PITR zu einem benutzerfreundlichen Tool, das die folgenden Funktionen bietet:

  • Aufbewahrungsrichtlinien
  • inkrementelle Sicherungen
  • vollständige, heiße, physische Sicherungen mehrerer Postgres Plus Advanced Server- und PostgreSQL-Datenbankserver
  • Sicherungs- und Wiederherstellungsverwaltung der Datenbankserver auf lokalen oder entfernten Hosts
  • zentraler Katalog für Sicherungsdaten
  • Sicherungsdaten in komprimiertem Format speichern
  • Prüfsummenüberprüfung

Während die Testversion für die neueste Version v2.1 nur über eine Yum-Repo-Anfrage erhältlich ist, bieten der Artikel Datensicherung leicht gemacht und der Produktdokumentationsleitfaden einige Informationen für diejenigen, die mehr erfahren möchten.

Laden Sie noch heute das Whitepaper PostgreSQL-Verwaltung und -Automatisierung mit ClusterControl herunterErfahren Sie, was Sie wissen müssen, um PostgreSQL bereitzustellen, zu überwachen, zu verwalten und zu skalierenLaden Sie das Whitepaper herunter

pgBackRest

pgBackRest implementiert eine vollständige Systemsicherung, die nicht auf die gängigen Tools tar und rsync angewiesen ist. Es wird derzeit von CrunchyData unter einer MIT-Lizenz gehostet und zur Verfügung gestellt. Einzelheiten zu seinen Ursprüngen finden Sie unter Anerkennung.

Es bietet alle Funktionen, die man von einem PostgreSQL-zentrierten Tool erwarten würde:

  • hoher Sicherungs-/Wiederherstellungsdurchsatz
  • vollständige, inkrementelle und differenzielle Sicherungen
  • Aufbewahrungsrichtlinien
  • Sicherung und Wiederherstellung der Integritätsprüfung durch Dateiprüfsummen und Integration mit PostgreSQL-Seitenprüfsummen.
  • Fähigkeit, Backups fortzusetzen
  • Streaming-Komprimierung und Prüfsummen
  • Amazon S3 Cloud-Speicherunterstützung
  • Verschlüsselung

..und vieles mehr. Einzelheiten finden Sie auf der Projektseite.

Die Installation erfordert ein 64-Bit-Linux/Unix-System und wird im Benutzerhandbuch beschrieben. Der Leitfaden führt den Leser auch in die Hauptkonzepte ein, was sehr nützlich für diejenigen ist, die neu in der PostgreSQL- oder Speichertechnologie sind.

Obwohl das Handbuch Befehlsbeispiele für Debian/Ubuntu verwendet, ist pgBackRest im PGDG-yum-Repository verfügbar, und das Installationsprogramm zieht alle Abhängigkeiten ein:

Installation:

pgbackrest       x86_64  2.01-1.rhel7     pgdg10  36k

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

Lassen Sie uns zwei Cluster einrichten, pg96 und pg10, die jeweils einen Knoten haben:

  • Kontrollknoten („Repository“ in der Anleitung):

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

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

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

  • Cluster #1:

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

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

  • Cluster #2:

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

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

Führen Sie als Nächstes Sicherungen aus und zeigen Sie den Sicherungskatalog an:

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

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

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

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

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

pgBackRest unterstützt die Parallelisierung von Sicherung und Wiederherstellung – gemäß dem Beispiel im Handbuch sichern wir mit einer CPU und aktualisieren dann die Konfiguration, um 2 CPUs zu verwenden:

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

[pg96]
pg1-host=db1

Das Ergebnis:

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

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

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

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

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

Mit 2 CPUs lief das Backup fast 20 % schneller, was einen großen Unterschied machen kann, wenn es mit einem großen Datensatz ausgeführt wird.

Schlussfolgerung

PostgreSQL-zentrierte Backup-Tools bieten erwartungsgemäß mehr Optionen als Allzweck-Tools. Die meisten PostgreSQL-Backup-Tools bieten die gleiche Kernfunktionalität, aber ihre Implementierung führt zu Einschränkungen, die nur entdeckt werden können, wenn Sie die Dokumentation sorgfältig befolgen, um das Produkt zu testen.

Darüber hinaus bietet ClusterControl eine Reihe von Sicherungs- und Wiederherstellungsfunktionen, die Sie als Teil Ihres Datenbankmanagement-Setups verwenden können.