DevOps / onPremis Themen

Backup erstellen und Datenbank aus Backup wieder herstellen

Hintergrund

Mit Hilfe des pg_basebackup erzeugen wir ein vollständiges, konsistentes Abbild des Postgres Clusters inkl. der DBMS Konfigurationsdateien. Die Vorteile und Nachteile dieser Methode gegenüber der Verwendung von pg_dump sind

Vorteile

  • Komplettes Cluster-Backup: Es sichert das gesamte Datenbank-Cluster, einschließlich aller darin enthaltenen Datenbanken.
  • Konsistenz: Gewährleistet ein konsistentes Abbild des gesamten Datenbank-Clusters.
  • Geschwindigkeit: Typischerweise schneller für große Datenbanken, da es auf Dateisystemebene arbeitet.

Nachteile

  • Größe: Die Backups können groß sein, da sie alle Datenbankdateien einschließlich leerem Speicherplatz enthalten.
  • Flexibilität: Weniger flexibel bei der Wiederherstellung einzelner Datenbanken oder Tabellen.

Durchführen des Backups

Anmelden am container

sudo docker exec -it <project>-postgres-1 bash

Falls noch nicht geschehen, ist die Freigabe des bind mounts /tmp/db_basebackup für den user postgres sicherzustellen.

root@7b720696a442:/# chown -R postgres /tmp/db_basebackup/

Anmelden als postgres user und Durchführen des Backup

root@7b720696a442:/# su postgres
postgres@7b720696a442:/$ pg_basebackup -h localhost -p 5422 -U postgres -D /tmp/db_basebackup/<project>-<yyyyMMdd-HHmm> -Fp -Xs -P --checkpoint=fast

wir nutzen die folgenden Optionen

Wir nutzen die folgenden Optionen:

  • -Fp: Format des Backups. Optionen sind „p“ für plain und „t“ für tar. Plain kopiert die Dateien im gleichen Layout wie das Datenverzeichnis und die Tablespaces des Host-Servers.
  • -Xs: Methode zum Sammeln der WAL-Dateien. Das „X“ steht für die Methode, und das „s“ steht für Streaming. Andere Optionen sind: „n“ für keine, d.h. keine WAL-Dateien sammeln und „f“ für fetch, was die - WAL-Dateien nach Abschluss des Backups sammelt.
  • -P: Zeigt den Fortschritt an.
  • -D: Das Zielverzeichnis, in das das Programm seine Ausgabe schreibt. Diese Option ist obligatorisch.

Wiedereinspielen eines Backups

Zum Wiedereinspielen des Backups müssen wir den Container mit dem DBMS herunterfahren

Das folgende Kommando führen wir im übergeordneten Verzeichnis von werner-docker aus

docker compose -p <project> down

Anschliessend verbinden wir uns mit dem durch das DBMS genutzten Volume mit Hilfe des postgres-recovery containers Das anschliessende Kommando führen wir im werner-docker Verzeichnis aus, da es das dort liegende yaml File voraussetzt

docker compose -p <project> --profile recovery up postgres-recovery -d
sudo docker exec -it <project>-postgres-recovery-1 bash

Nun löschen wir mit dem postgres user die vorhandenen Daten des DBMS, nachdem wir uns vergewissert haben, dass das Backup für uns verfügbar ist

root@134da3f36a53:/# su postgres
postgres@134da3f36a53:/$ cd /var/lib/postgresql/data/pgdata/
postgres@134da3f36a53:~/data/pgdata$ ls /tmp/db_basebackup/<project>--<yyyyMMdd-HHmm>/
PG_VERSION    backup_label.old  base    pg_commit_ts  pg_hba.conf    pg_logical    pg_notify    pg_serial     pg_stat      pg_subtrans  pg_twophase  pg_xact               postgresql.conf
backup_label  backup_manifest   global  pg_dynshmem   pg_ident.conf  pg_multixact  pg_replslot  pg_snapshots  pg_stat_tmp  pg_tblspc    pg_wal       postgresql.auto.conf
postgres@134da3f36a53:~/data/pgdata$ rm -rf *
postgres@134da3f36a53:~/data/pgdata$ cp -rf /tmp/db_basebackup/<project>-<yyyyMMdd-HHmm>/* .

Wir stoppen den recovery container

docker compose -p unibas-test down

anschliessend erfolgt der Start der Anwendung im normalen Modus durch die Ausführung des scripts im übergeordneten Verzeichnis

./start.sh <project> .env.<project> run

oder den manuellen Start mittels

docker compose --env-file ../.env.<project> -p <project> --profile additional_services up -d
Previous
Recovery der Datenbank bei Konfigurationsfehlern