Postgres via Batch sichern
Wir haben eine OpenSuse 9.3 VM, auf der ein Postgres v8.3.1 läuft.
Die Postgres soll nun täglich und automatisch, statt wie bisher manuell und gelegentlich gesichert werden.
Dabei tritt mit meinem Script das bekannte Problem auf, dass man gezwungen wird das Passwort zum User einzugeben.
Ich habe hier im Forum bereits Lösungsansätze gefunden, auch schon in diversen Foren, leider hat mir bisher kein Tipp geholfen.
Diese Variante hier sorgt nun immerhin schon dafür, dass ich das Passwort nur noch einmal statt 5x eingeben muss. In der einlesenden Datei steht das Passwort fünf mal drin.
Trotzdem muss ich es einmal eingeben, komme was wolle.
Auch die Variante mit dem Passwort in der /$HOME/.pgpass funkioniert nicht. Witzigerweise meckert pg_dumpall, wenn ich vorher die Attribute nicht auf 0600 gesetzt habe. Danach jedoch verlangt es nach wie vor ein Passwort.
Der dritte Lösungsansatz, den ich finden konnte mit der Option -W "passwort", der angeblich in der Version 8.x funktionieren soll scheitert bei mir mit der Ausgabe eines Fehlers.
"Die Option -w (ja, klein 'w') gibt es nicht" [sinngemäß].
Hat jemand einen Tipp für mich? - Oder anders gefragt, wie habt ihr das Problem gelöst / umgangen?
Die Postgres soll nun täglich und automatisch, statt wie bisher manuell und gelegentlich gesichert werden.
Dabei tritt mit meinem Script das bekannte Problem auf, dass man gezwungen wird das Passwort zum User einzugeben.
Ich habe hier im Forum bereits Lösungsansätze gefunden, auch schon in diversen Foren, leider hat mir bisher kein Tipp geholfen.
Diese Variante hier sorgt nun immerhin schon dafür, dass ich das Passwort nur noch einmal statt 5x eingeben muss. In der einlesenden Datei steht das Passwort fünf mal drin.
#!/bin/bash
pg_dumpall -h localhost -U "username" -l datenbank | gzip > /pfad/PostgreDB-$(date +%d-%m-%Y).gz < /pfad/bckwiki.pwd
Auch die Variante mit dem Passwort in der /$HOME/.pgpass funkioniert nicht. Witzigerweise meckert pg_dumpall, wenn ich vorher die Attribute nicht auf 0600 gesetzt habe. Danach jedoch verlangt es nach wie vor ein Passwort.
Der dritte Lösungsansatz, den ich finden konnte mit der Option -W "passwort", der angeblich in der Version 8.x funktionieren soll scheitert bei mir mit der Ausgabe eines Fehlers.
"Die Option -w (ja, klein 'w') gibt es nicht" [sinngemäß].
Hat jemand einen Tipp für mich? - Oder anders gefragt, wie habt ihr das Problem gelöst / umgangen?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 122504
Url: https://administrator.de/forum/postgres-via-batch-sichern-122504.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
6 Kommentare
Neuester Kommentar
Moin Gilneas,
da müssen wir uns mal vorsichtig rantasten, weil die von Dir zusammengegoogelten Tipps unmöglich alle wahr sein können.
Mit der PostGreSQL-Referenz konform ist das von Dir beobachtete Phänomen, dass das .pgpass-File ignoriert wird, wenn Du nicht explizit world und groups ausgesperrt hast (also chmod 0600 ~/.pgpass ).
So sagt es auch das Manual auf PostgreSQL.org.
Was allerdings niemand aus meinem Bekanntenkreis behauptet haben kann, ist
Ich denke, der Fehler muss entweder im ~/.pgpass-File liegen oder aber an nicht gesetzten PGHOST/PGPORT/PGUSER-Environmentvariablen.
Kannst Du bitte mal die (anonymisierten) 5 Zeilen Deiner .pgpass-Datei posten?
Grüße
Biber
da müssen wir uns mal vorsichtig rantasten, weil die von Dir zusammengegoogelten Tipps unmöglich alle wahr sein können.
Mit der PostGreSQL-Referenz konform ist das von Dir beobachtete Phänomen, dass das .pgpass-File ignoriert wird, wenn Du nicht explizit world und groups ausgesperrt hast (also chmod 0600 ~/.pgpass ).
So sagt es auch das Manual auf PostgreSQL.org.
Was allerdings niemand aus meinem Bekanntenkreis behauptet haben kann, ist
- dass die Option [-W], die erzwingt, dass nach einem Passwort gefragt wird, nun plötzlich einen optionalen Parameter "passwort" kennen soll. Glaub ich nienich.
- und ebenfalls nicht einordnen kann ich den [-l] [minus Klein-L]-Parameter, den ich noch nie gesehen habe. Gibt es den?
Ich denke, der Fehler muss entweder im ~/.pgpass-File liegen oder aber an nicht gesetzten PGHOST/PGPORT/PGUSER-Environmentvariablen.
Kannst Du bitte mal die (anonymisierten) 5 Zeilen Deiner .pgpass-Datei posten?
Grüße
Biber
Moin Gilneas,
Hint: das war eine rhetorische Frage.
Ich bat doch vor wenigen Minuten darum, dass Du mal den anonymisierten Inhalt der ~./pgpass-Datei forumsöffentlich machst.
Und hatte mir etwas erhofft wie
... oder irgendetwas anderes im Format
Hattest Du diese Bitte gelesen?
Hint: das war auch eine rhetorische Frage.
Grüße
Biber
Meine ~/.pgpass-File enthält das Passwort in Klartext, mehr nicht.
Öhm.... hast Du mal meinen Link oben angetestet?Hint: das war eine rhetorische Frage.
Ich bat doch vor wenigen Minuten darum, dass Du mal den anonymisierten Inhalt der ~./pgpass-Datei forumsöffentlich machst.
Und hatte mir etwas erhofft wie
Zampano1:1530:DBMain:dbMUser:ForgetIt
Zampano1:*:*:defUser:How2ReadTFM
hostname:port:database:username:password
Hattest Du diese Bitte gelesen?
Hint: das war auch eine rhetorische Frage.
Grüße
Biber
Moin Gilneas,
nur noch ein Hinweis hierzu:
Die .pgpass ist aber durchaus für die Aufnahme beliebig vieler Zeilen/Autorisierungen geeignet.
Und AFAIK auch für Wildcards ("*") in den ersten 4 der 5 Items (also alles außer dem Password)
Aber selbst wenn das beim USERNAME nicht ginge, dann wäre doch eine Datei dieser Form möglich:
pg_dumpall sucht sich schon die Zeile(n) raus, die mit den übergebenen Parametern übereinstimmen.
Zweite Anmerkung zum Unterschied pg_dump und pg_dumpall.
Ja, pg_dumpall ruft seinerseits immer das pg_dump auf für jede einzelne DB.
Nein, es ist aber nicht das gleiche, ob Du nun jede vorhandene DB einzeln mit pg_dump abklapperst oder ein pg_dumpall auf alles machst.
Denn pg_dumpall sichert zusätzlich ja noch (die Supervisor-Rechte vorausgesetzt) auch die <i<globalen</i>, DB-übergreifenden DB-Objekte wie Privilegien, Benutzer, Packages etc.
Deshalb sollte ein pg_dumpall auch mit möglichst hohen Rechten (->Supervisor der DB) abgefeuert werden.
Wenn es "nur" um eine reine Sicherung der Tabelleninhalte geht-> ja hey... das kann auch sicherungsberechtiger Nicht-Supervisor.
Hat aber alles nicht unbedingt etwas mit dem Lnux-User root zu tun - es geht nur um die Datenbank-Rechte/um das, was die Datenbank kennt.
Grüße
Biber
nur noch ein Hinweis hierzu:
Die anderen DBs müssen mit einem anderen User angesprochen werden.
Der hat zwar das gleiche PW, aber hier scheint die pgpass mit einem Platzhalter ' * ' für den User nicht zu greifen
Der hat zwar das gleiche PW, aber hier scheint die pgpass mit einem Platzhalter ' * ' für den User nicht zu greifen
Die .pgpass ist aber durchaus für die Aufnahme beliebig vieler Zeilen/Autorisierungen geeignet.
Und AFAIK auch für Wildcards ("*") in den ersten 4 der 5 Items (also alles außer dem Password)
Aber selbst wenn das beim USERNAME nicht ginge, dann wäre doch eine Datei dieser Form möglich:
localhost:*:DBName1:usernameA:passwort
localhost:*:DBName1:usernameA:passwort
localhost:*:DBName1:usernameB:passwort
localhost:*:DBName2:usernameC:passwort
localhost:*:DBName3:usernameD:passwort
...
Zweite Anmerkung zum Unterschied pg_dump und pg_dumpall.
Ja, pg_dumpall ruft seinerseits immer das pg_dump auf für jede einzelne DB.
Nein, es ist aber nicht das gleiche, ob Du nun jede vorhandene DB einzeln mit pg_dump abklapperst oder ein pg_dumpall auf alles machst.
Denn pg_dumpall sichert zusätzlich ja noch (die Supervisor-Rechte vorausgesetzt) auch die <i<globalen</i>, DB-übergreifenden DB-Objekte wie Privilegien, Benutzer, Packages etc.
Deshalb sollte ein pg_dumpall auch mit möglichst hohen Rechten (->Supervisor der DB) abgefeuert werden.
Wenn es "nur" um eine reine Sicherung der Tabelleninhalte geht-> ja hey... das kann auch sicherungsberechtiger Nicht-Supervisor.
Hat aber alles nicht unbedingt etwas mit dem Lnux-User root zu tun - es geht nur um die Datenbank-Rechte/um das, was die Datenbank kennt.
Grüße
Biber