Backup per Programm erstellen mit PG unter Windows

Servus,

hab mir das Buch PostgreSQL 10 Praxishandbuch gekauft und versucht, das Backup-Prinzip in meiner Waren-Wirtschaft umzusetzen. Ziel ist es, ein automatisiertes Backup des kompletten PG-Servers umzusetzen, da ich bisher nur die einzelnen Tables mittels des copy - Befehls sichere.

Also ein

select pg_start_backup("Sicherung")

Das WAL-Zeugs hab ich konfiguriert, der Befehl wird erfolgreich ausgeführt.

dann heisst es

Sichern Sie das Verzeichnis $PGDATA mit Betriebssystemmitteln

Da beginnt mein Problem. Aus meiner Windows Client-Anwendung heraus hab ich dazu ja gar keinen Zugriff. Also wie soll ich das komplette Data-Verzeichnis inkl. Unterverzeichnisse aus meiner Anwendung heraus sichern (z. B. zippen)?

Wie macht Ihr das? Ich möchte dem Anwender nicht zumuten, dass er sich manuell auf seinem Windows PG-Server anmeldet und irgendwelche Scripte oder ähnliches startet.

Danke!

Du könntest von Deinem Windows Programm aus mit ShellExecute() das pg_dump.exe aufrufen. Wobei ich den Aufruf einer .cmd Datei zumutbar finde. Ich verwende folgendes Skript:

@echo off

set PGBIN="bin"
set PGHOST=BSPG00
set PGPORT=5432
set PGUSER=postgres
set PGPASSWORD=?????

for /F %%D IN (_databases.txt) do %PGBIN%\pg_dump.exe --format custom --blobs --verbose --file "C:\PostgreSQLBackup\%%D.pgsql" "%%D"

und in der Datei _databases.txt sind einfach die DB Namen aufgelistet wo das Backup gemacht werden soll.

Christian

Also, Backup ist keine Aufgabe eines Clients.

pg_basebackup ist ein Tool, um ein physisches Backup zu erstellen, inklusive der wal’s. Damit bist Du dann in der Lage, den kompletten DB-Cluster wieder herzustellen und bei Bedarf auch ein Point-In-Time-Recovery durchzuführen. Das ist ein physisches Backup pg_dump sichert eine einzelne Datenbank als SQL-dump, das ist ein logisches Backup. Btw., dieses enthält NICHT globale Objekte wie User, sondern nur den Inhalt der spezifizierten Datenbank.

Wenn Du es richtig machen willst, dann mache physische Backups. Um das zu vereinfachen (retention policy, wal-handling etc.) kannst Du Barman
https://www.pgbarman.org/index.html verwenden, aber das sollte besser auf einem Linux laufen.

Wenn Du mit Dumps hantieren willst, dann nutze Dinge, die das OS bereitstellt. Bei Linux Cron z.B., um regelmäßig einen Dump zu erstellen.

Servus Christian,

danke. Aber i. d. R. hat der Client keinen Zugriff auf den PostgreSQL-Server auf dem Windows-Server. PG_Dump.exe müsste ja auf dem Windows Server direkt gestartet werden, mit ShellExecute komme ich da nicht hin.

Stelle mir die Vorgehensweise so vor: Client startet Backup mittels select pg_start_backup(“Sicherung”). Dann kann ja das Data-Verzeichnis mit Windows-Boardmitteln gesichert werden, also z. B. ein xcopy, Zip, robocopy oder ähnliches. Danach dann ein select pg_stop_backup() und das wars.

Ansonsten sind diese Funktionen über die low-level-api irgendwie sinnfrei? Da fehlt noch was in PG? Optimal wäre, wenn das ähnlich wie mit dem archive_command - Parameter funktionieren würde…

Servus akretschmer,

danke. Ja, hast vermutlich ja Recht, aber wozu sind dann die low-level-api-Funktionen pg_start_backup und pg_stop_backup gedacht?

Eine tägliche Serversicherung läuft bei unseren Kunden sowieso, ich möchte damit nur zusätzlich aus Applikationssicht einen Stand wegsichern, der dann schnell wieder hergestellt werden kann - ohne den Umweg über ein Restore über die Serversicherung (wozu dann der jew. Administrator notwendig ist).

pg_start_backup / pg_stop_backup hat man z.B. in 9.0 genutzt, um einen Standby für Streaming Replication aufzubauen, damals gab es noch kein pg_basebackup, was diese Funktionen aufruft.

Um einen Dump zu erstellen, brauchst Du das aber nicht, den Dump kannst Du mittels pg_dump jederzeit machen, ohne pg_start_backup etc. aufzurufen.

Und ja: Du kannst pg_dump auch remote ausführen. Wenn Du Leuten, die nicht wisen, was sie tun, pg_start_backup und ein physisches wegkopieren des ganzen Datenordners gibst, fangen die irgend wann mal an, das wieder zurückspielen zu wollen. Glaube mir, das wird passieren. Und dann werden Dinge passieren, die Du nicht willst.

Nein, lt. dem Buch wird das so empfohlen. Ich hab das auch bei mir gestestet und keine Probleme festgestellt.

Jein (auf die 2. Frage), ich arbeite mich erst ein. Da ich aber aus meinen Applikationen heraus bisher noch keine Transaktionen benötigt habe, ist das für mich derzeit wohl auch noch nicht relevant.

In der Zeit, wo Du das Datenverzeichniss wegkopierst, können sich ja Dateien ändern. Stelle Dir eine 10TB große DB vor, das wegkopieren dauert. Wenn Du diese Kopie dann irgendwo wieder einspielst, ist das inkonsistent. Er wird erst wieder ein konsistenter Status erreicht, wenn PostgreSQL alle WAL’s, die zwischen pg_start_backup() und pg_stop_backup() geschrieben wurden, wieder ausgeführt hat - crash recovery.

Dazu mußt Du nicht einmal Transaktionen expiziet nutzen. PostgreSQL führt automatisch alles in Transaktionen durch. Dazu kommen weitere Dinge wie MVCC, Indexpflege, VACUUM, …

Das ist also sehr wohl relevant, wenn Du auf diesem Wege ein funktionierendes Backup anbieten willst :wink:

Danke. Ich lass es einfach.